Zgłaszanie błędów i próśb o funkcjonalności

Ważne

Prosimy o zgłaszanie problemów z bezpieczeństwem tylko do security@djangoproject.com. Jest to prywatna lista otwarta tylko dla deweloperów Django o długim stażu i wysokim zaufaniu a jej archiwa nie są publiczne. Po dalsze szczegóły, prosimy zobaczyć nasze polityki bezpieczeństwa.

W pozostałych przypadkach, zanim powiadomisz o błędzie lub poprosisz o nową funkcjonalność w systemie zgłoszeń, rozważ następujące punkty:

  • Sprawdź, czy ktoś nie złożył już zgłoszenia buga lub przyszłej funkcjonalności szukając lub uruchamiając custom queries w systemie zgłoszeń.

  • Don’t use the ticket system to ask support questions. Use the Django Forum or the Django Discord server for that.

  • Don’t reopen issues that have been marked „wontfix” without finding consensus to do so on the Django Forum.

  • Don’t use the ticket tracker for lengthy discussions, because they’re likely to get lost. If a particular ticket is controversial, please move the discussion to the Django Forum.

Powiadamianie o błędach

Dobrze napisane raporty błędów są niesamowicie pomocne. Jednakże w pracy z jakimkolwiek systemem zgłaszania błędów zawsze jest pewien koszt, więc doceniona zostanie twoja pomoc w utrzymaniu systemu tak użytecznym jak to możliwe. W szczególności:

  • Przeczytaj FAQ, aby zobaczyć czy twoje zgłoszenie nie jest dobrze znanym pytaniem.

  • Do ask on Django Forum or the Django Discord server first if you’re not sure if what you’re seeing is a bug.

  • Pisz kompletne, odtwarzalne, konkretne zgłoszenia błędów. Musisz zawrzeć czytelny, zwarty opis problemu i zestaw instrukcji, jak go odtworzyć. Dodaj tak dużo informacji debugowania jak możesz: skrawki kodu, testy, ślad powrotny wyjątku, zrzut ekranu i tym podobne. Ładny mały test jest najlepszym sposobem na zgłoszenie błędu, jako że szybko i w pomocny sposób pozwala potwierdzić błąd.

  • Don’t post to Django Forum only to announce that you have filed a bug report. All the tickets are mailed to another list, django-updates, which is tracked by developers and interested community members; we see them as they are filed.

Aby zrozumieć cykl życia zgłoszenia po jego stworzeniu, przejdź do Triaging tickets.

Zgłaszanie błędów i funkcjonalności interfejsu użytkownika

Jeśli błąd lub prośba o funkcjonalność dotyka czegokolwiek z natury wizualnego, jest kilka dodatkowych wytycznych:

  • Include screenshots in your ticket which are the visual equivalent of a minimal test case. Show off the issue, not the crazy customizations you’ve made to your browser.

  • If the issue is difficult to show off using a still image, consider capturing a brief screencast. If your software permits it, capture only the relevant area of the screen.

  • If you’re offering a patch that changes the look or behavior of Django’s UI, you must attach before and after screenshots/screencasts. Tickets lacking these are difficult for triagers to assess quickly.

  • Screenshots don’t absolve you of other good reporting practices. Make sure to include URLs, code snippets, and step-by-step instructions on how to reproduce the behavior visible in the screenshots.

  • Make sure to set the UI/UX flag on the ticket so interested parties can find your ticket.

Prośby o nowe funkcjonalności

Zawsze próbujemy ulepszać Django, a wasze prośby o funkcjonalności są kluczową tego częścią. Tutaj jest kilka porad jak najefektywniej zgłaszać prośbę:

  • Upewnij się, że funkcjonalność rzeczywiście wymaga zmian w rdzeniu Django. Jeśli Twój pomysł może zostać stworzony jako niezależna aplikacja bądź moduł – na przykład, jeśli chcesz wspierać kolejny silnik bazy danych – prawdopodobnie zaproponujemy, żebyś stworzył to niezależnie. Potem, jeśli otrzymasz odpowiednie wsparcie społeczności, możemy rozważyć włączenie go do Django.

  • First request the feature on the Django Forum, not in the ticket tracker. It’ll get read more closely and reach a larger audience. This is even more important for large-scale feature requests. We like to discuss any big changes to Django’s core before actually working on them.

  • Describe clearly and concisely what the missing feature is and how you’d like to see it implemented. Include example code (non-functional is OK) if possible.

  • Explain why you’d like the feature. Explaining a minimal use case will help others understand where it fits in, and if there are already other ways of achieving the same thing.

If there’s a consensus agreement on the feature, then it’s appropriate to create a ticket. Include a link to the discussion in the ticket description.

See also: Documenting new features.

Requesting performance optimizations

Reports of a performance regression, or suggested performance optimizations, should provide benchmarks and commands for the ticket triager to reproduce.

See the django-asv benchmarks for more details of Django’s existing benchmarks.

How we make decisions

Whenever possible, we strive for a rough consensus. To that end, we’ll often have informal votes on the Django Forum about a feature. In these votes we follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

  • +1: „I love the idea and I’m strongly committed to it.”

  • +0: „Sounds OK to me.”

  • -0: „I’m not thrilled, but I won’t stand in the way.”

  • -1: „I strongly disagree and would be very unhappy to see the idea turn into reality.”

Although these votes are informal, they’ll be taken very seriously. After a suitable voting period, if an obvious consensus arises we’ll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion toward a consensus fizzles out without a concrete decision, the decision may be deferred to the steering council.

Internally, the steering council will use the same voting mechanism. A proposition will be considered carried if:

  • There are at least three „+1” votes from members of the steering council.

  • There is no „-1” vote from any member of the steering council.

Votes should be submitted within a week.

Since this process allows any steering council member to veto a proposal, a „-1” vote should be accompanied by an explanation of what it would take to convert that „-1” into at least a „+0”.

Votes on technical matters should be announced and held in public on the Django Forum.