Contributing to the Mozilla codebase

przez 4 współtwórców

To tłumaczenie jest niekompletne. Pomóż przetłumaczyć ten artykuł z języka angielskiego.

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 - 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ź 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:

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:

Autorzy i etykiety dokumentu

Contributors to this page: enedil, sz.folta, jarekps, Wizjonero
Ostatnia aktualizacja: enedil,