Contributing to the Mozilla codebase

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 [email protected].

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 - warstwę aplikacji 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 budowania.
Jeśli znasz C, możesz tworzyć NSS, Opus i Daalę.
Jeśli znasz Rust, możesz tworzyć rustc lub Servo, silnik przeglądarki internetowej, zaprojektowany dla równoległości i bezpieczeństwa.
Jeśli znasz Go, możesz tworzyć Hekę
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 - Wykonaj build Firefoxa, Firefox OS, Thunderbirda lub innej aplikacji

Jeśli chciałbyś tworzyć Firefox, Thunderbird lub Firefox OS, skorzystaj z naszego zestawu prostych instrukcji buildowania Firefoxa, buildowania Thunderbirda lub buildowania Firefox OS. To bardzo proste lecz może zająć sporo czasu, więc prawdopodobnie zechcesz przejść do następnych kroków w trakcie buildowania. Więcej instrukcji buildowania znajdziesz tutaj.

W przypadku innych produktów, może nie być potrzeby buildowania 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:

Błędy nadzorowane (mentored bugs, lub alternatywnie - less usable interface) mają przypisanego mentora, który chętnie pomoże ci przejść przez całą ścieżkę obsługi błędu. Zwykle w samym opisie błędu powinno być zawarte dość informacji aby zacząć. Kiedy będziesz potrzebował dodatkowej pomocy skontaktuj się z mentorem poprzez IRC, stronę danego błędu lub email. Kiedy skończysz obsługę błędu mentor chętnie pomoże w umieszczeniu twojego kodu w drzewie.
"Dobre" pierwsze błędy ("good" first bugs) to kategoria obecnie raczej przestarzała, kiedyś uważaliśmy ją za bardzo dobre zadanie dla nowoprzybyłych aby zaznajomić się z Mozillą. Obecnie jesteśmy w trakcie migracji tej kategorii błędów do kategorii błędów nadzorowanych, jednak w miarę świeże błędy z kategorii "dobre" pierwsze błędy są nadal dobrym pomysłem na start jeśli kategoria błędów nadzorowanych jest pusta.
Projekty dla studentów to trochę większe projekty, które mogą być użyteczne dla studentów wyższych uczelni w celach zaliczeniowych. Oczywiście, jeśli nie jesteś studentem, nadal śmiało możesz zająć się poprawianiem tych błędów. Istnieją dwie listy - jedna z projektami opartymi na istniejącym kodzie oraz druga z projektami zaimplementowania nowych aplikacji.

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 - Oddaj swój kod do inspekcji (review)

Kiedy już naprawisz błąd, załącz patcha do błędu i poproś o inspekcję (review). Robi się to poprzez kliknięcie linku Details na twoim załączniku, a następnie ustawienie flagi review na ? i wpisanie bugzilla ID inspektora w polu tekstowym, które się pojawi (należy podać albo adres email inspektora albo otrzymany od niego :UniqueName). Podanie bugzilla ID jest bardzo ważne, inaczej prośba zostanie przeoczona. Pozostaje pytanie, jak znaleźć włąsciwą osobę do przeprowadzenia review?

Jeśli twój błąd to błąd nadzorowany, poproś swojego mentora - on będzie wiedział lub łatwo się dowie.
Uruchom polecenie hg blame i poszukaj osób, które grzebały już wcześniej w funkcjach, które zmieniłeś - będą dobrymi kandydatami.
Opis błędu może zawierać informację, kto jest najlepszą osobą do poproszenia o review.
Czy istnieją błędy poruszające podobny problem? Jeśli tak to osoba je sprawdzająca może być dobrym kandydatem.
Posiadamy również listę modułów która zawiera listę peerów oraz ownerów dla poszczególnych modułów, niektórzy z nich będą dobrymi kandydatami do inspekcji. W ostateczności ustaw ownera modułu jako osobę przeprowadzającą review i poproś go w komentarzu o wybranie kogoś innego jeśli nie mają czasu.

Krok 4b - Nadzoruj review

Jeśli poprosiłeś o review a inspektor nie odzywa się przez kilka dni, nie wahaj się mu przypomnieć. Wystarczy dodać komentarz do błędu z opisem 'review ping?', i następny jeśli nie odpowie po kolejnych kilku dniach. Jeśli nadal nie odpowie poproś o pomoc na kanałach irc #introduction lub #developers.

Krok 5 - Odpowiedz na review

Bardzo często inspektor poprosi o modyfikacje do twojej poprawki - czasem drobne, czasem spore. W każdym przypadku nanieś wszystkie modyfikacje, o które inspektor poprosi. Jeśli nie jesteś pewny jak - zapytaj się go! Załącz ponownie zaktualizowaną wersję patcha do błędu i ponownie poproś o review tą samą osobę. Jeśli dadzą ci r+ oznacza to, że twoja poprawka została zaakceptowana i powinna znaleźć się w drzewie!

Krok 6 - Umieść kod poprawki w drzewie

Ponieważ nie masz jeszcze możliwości umieszczania (push) kodu w drzewie, powinienieś poprosić kogoś o pomoc. Jeśli posiadasz mentora to poproś go o to. Jeśli nie to poproś osobę przeprowadzającą review. Jeśli jest ona jednak zajęta to zaznacz, że potrzebny jest commit poprzez dodanie słowa kluczowego checkin-needed. W przeciągu kilku dni powinien pojawić się ktoś kto umieści kod w repozytorium i zaznaczy błąd jako naprawiony.

Krok 7 - Powtarzaj

Gratulacje! Właśnie naprawiłeś swój pierwszy błąd! Teraz możesz wrócić do kroku 3 i wziąć się za kolejny. Po naprawieniu pierwszego błędu powinieneś również poprosić o "level 1 access" do repozytorium co daje ci możliwość umieszczania kodu na tryserverze i otrzymywania automatycznego feedbacku o twoich zmianach na wielu platformach. Po naprawieniu większej ilości błędów powinieneś poprosić o "level 3 access", wtedy będziesz mógł już własnoręcznie umieszczać swój kod po tym jak w review otrzymał status r+.

Więcej informacji

Jesteśmy w trakcie usprawniania treści tej strony dla nowoprzybyłych. Wkrótce przeniesiemy tutaj informacje z poniższych stron, a na razie podajemy ich listę w celu zapoznania się z nimi samemu w obecnej postaci: