Często zadawane pytania: Współtworzenie kodu

Jak mogę zacząć współtworzyć kod Django?

Dzięki, że pytasz! Napisaliśmy cały dokument poświęcony temu pytaniu. Jest zatytułowany Współtworzenie Django.

Złożyłem zgłoszenie dotyczące naprawy błędu kilka tygodni temu. Dlaczego ignorujecie moją łatkę?

Bez obaw: Nie ignorujemy Cię!

To ważne, żeby rozumieć różnicę pomiędzy „zgłoszenie jest ignorowane” a „zgłoszenie nie zostało jeszcze rozpatrzone”. System zgłoszeń Django zawiera setki otwartych zgłoszeń z różnymi poziomami skutków na funkcjonalność dla użytkownika końcowego. Programiści Django muszą je przejrzeć i nadać im priorytet.

Ponad wszystko: ludzie, którzy pracują nad Django to wolontariusze. W efekcie ilość czasu, który posiadamy do pracy nad frameworkiem jest ograniczony i będzie różnił się z tygodnia na tydzień w zależności od naszego wolnego czasu. Jeśli jesteśmy zajęci, nie jesteśmy w stanie poświęcać wystarczająco dużo czasu na Django, nawet jeśli byśmy chcieli.

Najlepszym sposobem, aby uniknąć zawieszania się zgłoszeń w drodze do ich wykonania, jest uczynić banalnie prostym, nawet dla kogoś, kto może nie być zaznajomiony z tym obszarem kodu, zrozumienie problemu i weryfikację rozwiązania:

• Czy są wyraźne instrukcje jak odtworzyć błąd? Jeśli dotyka on zależności (na przykład Pillow), modułu contrib, albo specyficznej bazy danych, czy instrukcje są wystarczająco wyraźne, nawet dla osoby niezaznajomionej z tematem?
• Jeśli zgłoszenie zawiera wiele załączonych łatek, czy jasne jest co która robi, która może być pominięta a która ma znaczenie?
• Czy do łatki dołączony jest test jednostkowy? Jeśli nie, czy jest jasny powód dlaczego? Test wyraża krótko na czym polega problem i pokazuje, że łatka faktycznie go naprawia.

Jeśli twoja łatka nie ma szans na dołączenie do Django, nie ignorujemy jej – po prostu zamykamy zgłoszenie. Dlatego jeśli twoje zgłoszenie jest nadal otwarte, nie oznacza to, że cię ignorujemy. Oznacza po prostu, że nie mieliśmy jeszcze czasu się mu przyjrzeć.

Kiedy i jak mogę przypomnieć głównemu zespołowi o łatce, która mnie interesuje?

Miła, wysłana w odpowiedniej chwili wiadomość na listę mailingową jest jednym ze sposobów na zwrócenie na siebie uwagi. Aby rozpoznać odpowiedni czas, musisz mieć oko na harmonogram. Jeśli wyślesz swoją wiadomość tuż przed deadlinem wydania, prawdopodobnie nie zdobędziesz tego rodzaju uwagi, którego potrzebujesz.

Delikatne przypomnienia na IRC mogą również zadziałać – ponownie, strategicznie skoordynowane czasowo, jeśli możliwe. Bardzo dobry czas to na przykład okres bug sprintu.

Innym sposobem na uzyskanie przyczepności jest umieszczenie razem kilku powiązanych zgłoszeń. Kiedy ktoś siada do przyjrzenia się błędowi w obszarze kodu, którego nie dotykał przez chwilę, może zająć mu kilka minut przypomnienie sobie wszystkich drobnych szczegółów, jak działa ten obszar. Jeśli zbierzesz kilka mniejszych poprawek błędów w grupę o podobnym temacie, możesz stworzyć atrakcyjny cel, jako że koszt wgryzienia się w obszar kodu może zostać rozłożony na wiele zgłoszeń.

Prosimy wystrzegać się pisania do kogokolwiek osobistych e-maili lub powtarzania zgłoszeń w kółko tego samego. Taki sposób zachowania nie przysporzy ci żadnej dodatkowej uwagi – na pewno nie takiej uwagi, której potrzebujesz, aby twoje zgłoszenie zostało rozwiązane.

Ale przecież przypominałem Ci kilka razy a Ty nadal ignorujesz moją łatkę!

Poważnie - nie ignorujemy cię. Jeśli Twoja łatka nie ma szans na dołączenie do Django, zamkniemy zgłoszenie. Dla wszystkich innych zgłoszeń musimy ustalić priorytety naszych działań, co oznacza, że niektóre zgłoszenia zostaną rozpatrzone przed innymi.

Jednym z kryteriów, które jest używane to priorytetyzowania poprawek błędów, jest liczba osób, na którą może mieć wpływ dany błąd. Błędy, które potencjalnie mogą wpłynąć na pracę wielu ludzi, zazwyczaj dostają priorytet nad tymi, które są przypadkami brzegowymi.

Innym powodem, dla którego błędy mogą być przez chwilę ignorowane, może być sytuacja, w której błąd jest symptomem większego problemu. Mimo że możemy poświęcić czas pisaniu, testowaniu i aplikowaniu wielu małych łat, czasem dobrym rozwiązaniem jest przebudować funkcjonalność. Jeśli została zaproponowana albo jest w toku przebudowa lub refaktoring konkretnego komponentu, może się okazać, że zgłoszenia dotyczące tego komponentu nie przyciągną tak wiele uwagi. Znów, to kwestia priorytetyzowania ograniczonych zasobów. Koncentrując się na przebudowie, możemy naprawić wszystkie małe błędy za jednym razem i być może uniknąć pojawienia się innych małych błędów w przyszłości.

Cokolwiek jest przyczyną, prosimy pamiętaj, że podczas gdy ty możesz napotykać szczególny błąd regularnie, nie znaczy to koniecznie, że każdy użytkownik Django się z nim zetknie. Różni użytkownicy używają Django na różne sposoby, obciążając różne części kodu w różnych warunkach. Kiedy szacujemy priorytety, w ogólności staramy się brać pod uwagę potrzeby całej społeczności, nie tylko dotkliwość błędu dla jednego wybranego użytkownika. To nie znaczy, że myślimy, iż twój problem jest nieważny – myślimy tylko, że w dostępnym ograniczonym czasie, zawsze przychylimy się do uczynienia szczęśliwymi 10 osób, ponad uczynienie szczęśliwą tylko jednej.