This article is in progress of being translated.
Ta strona zaprezentuje Ci pierwsze kroki wnoszenia własnego wkładu do Mozilli. Cześć! Witamy Cię z przyjemnością! :)
Potrzebujesz pomocy?
Społeczność Mozilli zawsze wita nowoprzybyłych do naszego centrum. Jeśli masz jakieś trudności z czymkolwiek, możesz spytać na pokoju #introduction na irc.mozilla.org. Jeśli wciąż masz problemy, proszę skontaktuj się z Kyle Huey przez e-mail khuey@mozilla.com.
Jakich umiejętności potrzebuję?
Mozilla to olbrzymi projekt i jesteśmy szczęśliwi mogąc przywitać ludzi z bardzo różnymi umiejętnościami.
- Jeśli znasz C++, możesz przyczynić się do poprawiania rdzenia Firefox, Firefox OS i innych produktów Mozilli.
- Jeśli znasz JavaScript lub HTML/CSS, możesz tworzyć front-end (warstwę wierzchnią) Firefox, lub Gaia - aplikacji "warstwowej" Firefox OS.
- Jeśli znasz Java, możesz tworzyć Firefox Mobile.
- Jeśli znasz Python, możesz tworzyć nasze serwisy internetowe, włączając w to Firefox Sync czy Persona.
- Jeśli znasz Make, Shell, Perl, czy Python, możesz tworzyć nasz system "built system".
- Jeśli znasz C, możesz tworzyć wiele bibliotek: niskopoziomowych i innych firm. My używamy tych bibliotek jako część kodu Mozilli.
- Jest także wiele innych opcji, by wspierać misję Mozilli bez programowania. Jeśli chcesz poprawić wygląd, obsługę klienta, tłumaczenie, testowanie, czy wesprzeć nas w inny sposób, zajrzyj na stronę z naszymi ofertami.
Może jeszcze nie potrafisz programować, ale chcesz się nauczyć? Wspaniale! Nasz program nauki tworzenia stron jest dla Ciebie! Jest też więcej źródeł dostępnych w sieci developerów Mozilli! (Mozilla Developer Network)
Krok 1 - Twórz Firefox, Firefox OS, Thunderbird lub inne aplikacje
Jeśli chciałbyś tworzyć Firefox. Thunderbird lub Firefox OS, skorzystaj z naszego zestawu prostych instrukcji tworzenia Firefox, tworzenia Thunderbird lub tworzenia Firefox OS. To bardzo proste, lecz może zająć sporo czasu, więc prawdopodobnie zechcesz przejść do następnych kroków w trakcie tworzenia. WIęcej instrukcji znajdziesz tutaj.
W przypadku innych produktów, może nie być potrzeby tworzenia czegokolwiek.
Krok 2 - Znajdź coś, nad czym możesz pracować
Szukaj dziury w całym
Jeśli jest coś, co chciałbys zmienić w Firefox, Thunderbird, czy innej ulubionej aplikacji Mozilli, to może być odpowiednie miejsce, by zacząć. Jest na to kilka sposobów:
- Znajdź w bugzilli odpowiednie słowa kluczowe.
- Korzystając z listy komponentów, dowiedz się, w którym komponencie bugzilli usytuawony jest element do poprawy. Przeszukaj go w celu znalezienia błędów.
- Zapytaj na kanale #introduction lub #developers na irc.mozilla.org.
Znajdź błąd, który określiliśmy jako dobry dla początkujących
Developerzy Mozilli traktują część błędów jako proste poprawki które pozwolą nowym kontrybutorom na zapoznanie się z naszymi procesami:
- 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. We maintain two lists, one for projects based on the existing codebase and one for implementing new applications.
Krok 3 - Napraw błąd
Zostawiamy to w twoich rękach. Oto kilka zasobów które mogą Ci w tym pomóc:
- Poproś o pomoc w komentarzu do błędu lub na kanałach irc #introduction lub #developers
- Zapoznaj się z https://developer.mozilla.org/En/Developer_Guide
Krok 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 can find out easily.
- Run
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
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 5 - 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 6 - 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 7 - 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 the tryserver 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.
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:
