來助 Mozilla 一臂之力

翻譯不完整。請協助 翻譯此英文文件

歡迎您,我們很高興見到您!
本頁應能作為引導您為 Mozilla 貢獻的第一步。

需要幫助嗎?

Mozilla 社群自豪於她是一個對新參與者開放、易接觸與友善的社群,如果您有任何困難,或是尋求答案,請將那些問題帶來在 irc.mozilla.org 的 #introduction chat room 讓我們可以協助您開始。

我們知道,在您開始貢獻前,設置前置作業以及找一個與您能力相符的 bug 會是一個挑戰。我們總是在尋找能夠改善這些程序的方法,好讓 Mozilla 更為開放、易接觸以及更容易參與。如果您在使用這些文件出了問題,或是遇到了瓶頸,請直接利用電子郵件聯絡 Mike Hoye (mhoye@mozilla.com) 好讓我們能解決您的問題以及往後的新參與者。

我需要甚麼技能呢?

Mozilla 是個龐大的專案,我們很高興能夠接納擁有各種不同能力的貢獻者。

  • 如果您會 C++,您可以幫忙貢獻有關 Firefox,Firefox OS,與其他 Mozilla 產品的核心部份。
  • 如果您會 JavaScirpt 或是 HTML/CSS, 您可以幫忙參與 Firefox 的前端,或是 FIrefox OS 的應用層,Gaia。
  • 如果你會 Java,你可以替 Firefox Mobile 和 MozStumbler 做出貢獻。
  • 如果你會 PHP,你可以幫忙 Transvision、 Marketplace.PHP、以及 Bugzilla 的MediaWiki 擴充套件。
  • 如果你會 Python,你可以替我們的網路服務做出貢獻,像是 Firefox Sync 或是 Persona。
  • 如果你會 Make、 shell、 Perl、或是 Python,你可以替我們的建制系統做出貢獻。
  • 如果你會 C,你可以協助 NSS、 Opus、以及 Daala。
  • 如果你會 Rust,你可以幫忙 rustc, or to Servo, a web browser engine designed for parallelism and safety.
  • If you know Go, you can contribute to Heka, a tool for data processing.
  • And there are also many ways to contribute to the Mozilla mission without programming. If you'd like to get involved in design, support, translation, testing, or other types of of contributions, see the Volunteer Opportunities page.

Perhaps you do not know programming yet but you want to start learning? That's great too, the Webmaker program is for you, and there are more resources available on the Mozilla Developer Network!

第一步 - 建置 Firefox, Firefox OS, Thunderbird,或是其他應用程式

If you wish to contribute to Firefox, Thunderbird, or Firefox OS, follow our set of simple instructions to build Firefox, or to build Thunderbird, or to build Firefox OS. This is straightforward, but may take some time, so you may want to move on to the next steps while it builds. More build instructions can be found here.

For other products, you may not need to build anything.

第二步 - 找點事情來做

修正那些討人厭的小問題

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:

找到一個我們認為適合初學者的 Bug

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.
  • 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.

第三步 - 修復 Bug

We leave this in your capable hands. We have some resources to help you here too:

第四步 - 將你的程式碼呈報上來

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!
  • Run hg blame and 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.

步驟四之二 - 好好的盯著它

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 that you can ask for help on IRC in the #introduction or #developers channels or contact Mike Hoye directly.

第五步 - 對於你的呈報有所回應

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.

第七步 - 重複地做

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 r+ed.

更多資訊

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:

文件標籤與貢獻者

 此頁面的貢獻者: wildsky, grapherd, lekaha
 最近更新: wildsky,