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.

I submitted a bug fix several weeks ago. Why are you ignoring my contribution?

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?
  • If there are several branches linked to the ticket, is it clear what each one does, which ones can be ignored and which matter?
  • Does the change include a unit test? If not, is there a very clear explanation why not? A test expresses succinctly what the problem is, and shows that the branch actually fixes it.

If your contribution is not suitable for inclusion in Django, we won’t ignore it – we’ll close the ticket. So if your ticket is still open, it doesn’t mean we’re ignoring you; it just means we haven’t had time to look at it yet.

When and how might I remind the team of a change I care about?

A polite, well-timed message in the forum/branch is one way to get attention. To determine the right time, you need to keep an eye on the schedule. If you post your message right before a release deadline, you’re not likely to get the sort of attention you require.

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.

But I’ve reminded you several times and you keep ignoring my contribution!

Seriously - we’re not ignoring you. If your contribution is not suitable for inclusion in Django, we will close the ticket. For all the other tickets, we need to prioritize our efforts, which means that some tickets will be addressed before others.

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.

Another reason that a bug might be ignored for a while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little changes, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.

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, zamiast priorytetyzować wpływ na 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.

Jestem pewien(-wna), że moje zgłoszenie jest w 100% perfekcyjne. Czy mogę sam(a) oznaczyć je jako „Ready For Checkin”?

Przepraszam, ale nie. Zawsze lepiej spojrzeć na zgłoszenie jeszcze jedną parę oczu. Jeśli masz problemy z uzyskaniem drugiej pary oczu, zapoznaj się z pytaniami powyżej.

Back to Top