この文書は翻訳中です。他国語のままの部分などがあるのはその為です。
是非お気軽に MDN に登録して翻訳に参加し、私たちの手助けをして下さい！
このページは Mozilla に貢献するための最初のステップを案内しています。ようこそ、私たちはあなたに会えてうれしいです:)
ヘルプは必要ですか?
Mozillaコミュニティーは、いつも、新しい参加者を歓迎しています。 あなたが参加している時、なにか困難な問題があるときは、 #introduction chat room on irc.mozilla.org で質問をすることが出来ます。 それでも問題がある場合は Kyle Huey at [email protected]にご連絡下さい。
どんなスキルが必要?
Mozillaは大きなプロジェクトです。そして、異なるスキルを持ったコントリビュータ達を喜んで歓迎します。
もし、あなたがC++を知っているならFirefox、FirefoxOS、Mozillaの他の製品の中心となる部分に貢献できます。
もし、あなたがJavascriptやHTML/CSSを知っているならFirefoxのフロントエンド、Gaia、Firefoxのアプリケーション層の部分に貢献できます。
もし、あなたがJavaを知っているならFirefox Mobileに貢献できます。
もし、あなたがPythonを知っているならFirefox SyncやPersonaを含む私たちのウェブサービスに貢献できます。
もし、あなたがMake、shell、Perl、Pythonを知っているならビルドシステムに貢献することができます。
もし、あなたがC言語を知っているなら多くのMozillaの一部で使用している低レイヤまたはサードパーティのライブラリに貢献できます。
プログラミングの知識が無くてもMozillaに貢献する方法はいくつもあります。デザイン、サポート、翻訳、テスト、または他の貢献の仕方に関わりたいなら、 Volunteer Opportunities pageを見て下さい。
もしかして、まだプログラミングについてよく知らないけど、これから学びたいと考えていますか？それは、とても素晴らしいことです。 the Webmaker programで学習すると良いでしょう。そして、Mozilla Developer Networkには他にも利用できる more resourcesがあります。
Step 1 - Firefox, Thunderbird または、別のアプリケーションのビルドについて
Firefox のビルドの簡単な説明や Thunderbird のビルドに従ってください。それは、簡単ですが、若干時間が掛かるかもしれません。 なので、ビルド中にあなたは次のステップに移れるかもしれません
もっと多くのビルドの説明は ここにあります
Step 2 - Mozillaの作品に貢献する方法を理解するには
Mozilla Firefox: 開発プロセスを参照してください。 Thunderbird も同様のプロセスを運営してます。
Step 3 - 取り組む何かを見つけてください
不満を明確にしてください。
Firefoxや、 Thunderbirdやお気に入りのMozilla アプリケーションで、行いたいことが明確であるなら これらを、始めるのに良いいくつかの方法があります。：
- 関連するキーワードをbugzillabugzillaで探してください,
- あなたの不満が記載されているbugzilla component を見つけてください。 関連のバグは、bugzillaで、そのコンポーネントを参照します。
- rc.mozilla.orgの#introduction か #developers で尋ねてください。
バグを発見することを、新人には良いことであると認識している
初心者が、Mozillaのプロセスを理解しやすい簡単なバグに、Mozilla開発者はラベルを付けています。：
- Mentored bugs (or the alternative, less usable interface) have a mentor who commits to helping you every step of the way. 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.
- "Good" first bugs may be a little stale, but at some point in their lives we considered that they would be a good first step for newcomers to Mozilla. We are in the process of migrating these bugs to mentored bugs, but more recent "good first bugs" may be good starting points if there are no appropriate mentored bugs.
- 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.
Step 4 - Fix the bug
We leave this in your capable hands. We have some resources to help you here too:
- Check out https://developer.mozilla.org/En/Developer_Guide,
- Ask for help in a comment on the bug, or in #introduction or #developers.
If the bug you're fixing is likely to require an update to developer documentation once it's fixed, be sure to add the dev-doc-needed keyword to the bug (or ask someone to do it, if you don't have editbugs privileges on Bugzilla). This puts the bug on the radar of our documentation team to ensure that once the bug is resolved, the documentation will be updated appropriately. If you don't mark the bug, your work might go unnoticed by the docs team! You can mark the bug with this keyword at any time; you don't need to wait until it's actually fixed.
Of course, our documentation is a wiki; you can really help by updating the documentation yourself. Even if you're not comfortable with your writing skills, keep in mind that our helpful, happy documentation gnomes will follow along behind you and clean up for you.
Step 5 - 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 of 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 can find out easily.
- Run
hg blameand look at the people who have touched the function's 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 5b - Follow it up
If you've asked for review, but the reviewer hasn't said anything for a few days, don't be afraid to ping them. Just add a comment to the bug saying 'review ping?', and another a few days later if they still haven't responded. If they don't respond after that, ask for help in #introduction or #developers.
Step 6 - Respond to the review
Often, a reviewer will ask for changes, perhaps minor, perhaps major. In either case, fix what the 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 7 - Actually get the code into the tree
Since you don't yet have the ability to push the code into the tree, you should ask somebody for help. If you have a mentor, ask them. If not, ask the reviewer. If the reviewer is too busy, mark that a commit is needed by adding the checkin-needed keyword. A friendly person should be along within a few days and push the code to the repository, and they will mark the bug as fixed.
Step 8 - Repeat
Congratulations, you've fixed your first bug. Now go back to step 3 and repeat. Now that you've got your first bug in, you should request level 1 access to the repository so that you can push to tryserver and get automated feedback about your changes on multiple platforms. After fixing a nontrivial number of bugs, you should request level 2/3 access (depending on the repository you're using) so that you can push your own code after it has been r+ed.
More information
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: