Terjemahan ini belum lengkap. Mohon bantu menerjemahkan artikel ini dari Bahasa Inggris.
Halaman ini dapat memandu anda melalui langkah - langkah awal berkontribusi di mozilla, Selamat datang, senang melihat anda! :)
Komunitas Mozilla membanggakan diri sebagai komunitas terbuka, mudah diakses dan ramah bagi peserta baru. Jika anda memiliki kesulitan bergabung atau mencari jawaban dari pertanyaan anda, silakan tanyakan di #introduction chat room on irc.mozilla.org sehingga kami dapat membantu anda memulai.
Kami mengetahui - bahkan sebelum anda dapat memulai berkontribusi - mulai mendapatkan bentuk kerja di firefox dan mencari bug yang cocok dengan skill anda bisa menjadi tantangan. Kami selalu mencari cara untuk meningkatkan proses tersebut dan membuat mozila lebih terbuka, mudah diakses dan mudah untuk berpartisipasi. Jika anda memiliki permasalahan mengikuti dokumentasi ini atau hambatan yang anda tidak bisa atasi, silakan hubungi secara langsung Mike Hoye di firstname.lastname@example.org agar kami dapat memecahkan masalah anda dan setiap kontributor baru setelah anda.
Kemampuan apa yang saya butuhkan?
Mozilla merupakan projek besar dan kami senang menerima kontributor dengan setiap kemampuan yang berbeda.
- Jika anda mengetahui C++ misalnya, anda dapat berkontribusi di layer utama dari Firefox dan produk Mozilla lainnya.
- Jika anda mengetahui Java, anda dapat berkontribusi di Firefox Mobile - Firefox on Android - dan MozStumbler.
- Jika anda mengetahui Python, anda bisa berkontribusi pada web services kamu, termasuk Firefox Sync atau Akun Firefox.
- Jika anda mengetahui Make, shell, Perl, or Python, anda dapat berkontribusi pada build system kami dan release engineering serta automation.
- Jika anda mengetahui C, anda dapat berkontribusi di NSS, Opus, dan Daala.
- Jika anda mengetahui Rust, anda dapat berkontribusi di rustc, Servo, sebuah mesin web browser didesain untuk parallelism dan safety, atau Quantum, sebuah proyek untuk membawa potongan - potongan besar dari Servo ke Gecko.
- Jika anda mengetahui Go, anda bisa berkontribusi di Heka, sebuah alat untuk pemrosesan data.
- Dan masih bayak lagi untuk berkontribusi di misi mozila tanpa pemrograman. Jika anda ingin bergabung pada design, support, translation, testing, atau jenis kontribusi lainnya, Lihat Halaman Volunteer Opportunities.
Tentu anda tidak mengetahui pemrograman namun anda ingin mulai belajar? Itu sangat bagus: Banyak sekali sumber daya yang tersedia di Mozilla Developer Network!
Langkah 1 - Membangun Firefox untuk Desktop atau Android.
Jika anda ingin berkontribusi di Firefox, simple instructions to build desktop Firefox are here, and for mobile contributors, you can get started here to build Firefox for Android. Getting set up may take some time - there are some big downloads involved - so you may want to move on to the next steps while it builds. More build instructions can be found here.
Mozilla's other products—including the community-supported Thunderbird builds—can be found with a quick search, and often you won't need to build anything to make a contribution.
Step 2 - Find something to work on
Fix your pet peeve
If there's something you'd like to fix about Firefox, Thunderbird, or your other favorite Mozilla application, this can be a good place to start. There are a number of ways to do this:
- Search bugzilla for relevant keywords.
- Figure out the bugzilla component in which your pet peeve is implemented, using the components list. Browse that component on bugzilla for related bugs.
- Ask in #introduction or #developers on irc.mozilla.org.
Find a bug we've identified as a good fit for new contributors.
With more than a million bugs filed in Bugzilla it can be hard to know where to start, so we've created these bug categories to make getting involved a little easier:
- Good First Bugs are the best way to take your first steps into the Mozilla ecosystem. They're all about small changes - sometimes as little as a few lines - but they're a great way to learn about setting up your development environment, navigating Bugzilla and making contributions to the Mozilla codebase.
- Mentored bugs are more challenging, but have a mentor who commits to helping you through the process. Generally, there should be enough information in the bug to get started. Whenever you need help, contact the mentor over IRC, in the bug itself, or by email. When you've completed the bug, they will help you get your code into the tree.
- Follow @StartMozilla on Twitter, where we link up Good First Bugs for new contributors across Mozilla every day.
- Visit firefox-dev.tools, where we list Firefox Developer Tools bugs for new contributors
- Student Projects are larger projects, such as might be suitable for a university student for credit. Of course, if you are not a student, you should still feel free to fix one of these bugs. We maintain two lists, one for projects based on the existing codebase and one for implementing new applications.
Step 3 - Fix the bug
We leave this in your capable hands. We have some resources to help you here too:
- Ask for help in a comment on the bug, or in #introduction or #developers
- Check out https://developer.mozilla.org/En/Developer_Guide
- Our reviewer checklist is very useful if you have got a patch close to completion and want to make sure it will be reviewed favourably.
Step 4 - Get your code reviewed
Once you fix the bug, attach a patch to the bug and ask for review. Do this by clicking the Details link on your attachment, then setting the review flag to ? and entering the reviewer's bugzilla ID in the text field that appears (either their email address or the :UniqueName they provide). It is very important to attach a bugzilla ID, or the request will be missed. So how do you figure out the right person to ask for a review?
- If you have a mentored bug, ask your mentor; they will know, or they can find out easily. It might even be them!
hg blameand look at the people who have touched the functions you've worked on - they will be a good candidate.
- The bug itself may contain a clear indication of the best person to ask for a review.
- Are there related bugs on similar topics? In that case, the reviewer in those bugs might be a good choice.
- We have an out of date list of modules which lists peers and owners for the module, some of whom will be a good reviewer. In the worst case, set the module owner as the reviewer, and ask them in the comment to pick someone better if they don't have time.
Step 4b - Follow it up
Once you've asked for a review, a reviewer will generally get back to you within a day or two either to review the patch or, if they're backlogged, when they'll be able to review it. If you haven't heard back within that time don't be afraid to reach out to them; add a comment to the bug saying 'review ping?', check the "Need more information from:" box in the bug and add the reviewer's name. If they don't respond within a day or two then you can ask for help on IRC in the #introduction or #developers channels or contact Mike Hoye directly.
Step 5 - Respond to the review
For most new contributors - and often for long time Mozillians! - the first review of your patch will be an r-. This doesn't mean you've done bad work, but it does mean that there is still some work to do before the code can be merged into the tree. Your patch may need some changes - perhaps minor, perhaps major - and your reviewer will give you some guidance about what needs to be done next.
This is an important process, so don't be discouraged! With a long-lived codebase and hundreds of millions users, the care and attention that goes into helping contributors merge solid patches is the cornerstone of the Mozilla project. Make the changes your reviewer asks for; if you're unsure how, be sure to ask! Attach the new patch to the bug again, and ask for review again from the same reviewer. If they give you an r+ that means that your bug is accepted into the tree!
Step 6 - Actually get the code into the tree
Once your patch has received an r+, it is ready to go. But before it can be merged into the tree, your patch will need to complete a successful run through our "try server" to make sure it doesn't cause any unexpected regressions; your mentor or the person who reviewed your patch will be able to help with that, if you don't have try server access already.
Once you've got a green try server run, mark that your patch is ready to commit by adding the checkin-needed keyword to the "keywords" field at the top of the bug. A friendly Mozillian with commit access will be along shortly to push your patch to the repository, and they will update the bug as required. If your patch has passed all of Mozilla's automated testing, soon it will be merged into the main branch and become a part of our nightly builds.
Step 7 - Repeat
Thank you. You've fixed your first bug, and the Open Web is stronger for it. But don't stop now.
Go back to step 3; there is a lot more to do. Your mentor can suggest a new bug for you to work on, or you can find one yourself that interests you. And now that you've got your first bug fixed, you should request level 1 access to the repository so that you can push to the try server and get automated feedback about your changes on multiple platforms. After fixing a nontrivial number of bugs, you should request level 3 access so that you can push your own code after it has been read.
We're in the process of improving information on this page for newcomers to the project. We'll be integrating some information from these pages soon, but until then you may find them interesting in their current form: