Innan du rapporterar en bugg på ticket tracker bör du tänka på följande punkter:
\nKontrollera att någon inte redan har lämnat in felrapporten genom att söka eller köra anpassade frågor i ärendehanteraren.
Använd inte ärendesystemet för att ställa supportfrågor. Använd Django Forum eller Django Discord server för det.
Återöppna inte frågor som har markerats som ”wontfix” utan att hitta enighet om att göra det på Django Forum.
Don’t reopen issues that have been marked ”needsnewfeatureprocess” without\nshepherding an issue through the new feature ideas GitHub project.
Använd inte ärendehanteraren för långa diskussioner, eftersom de sannolikt kommer att gå förlorade. Om ett viss ärende är kontroversiell, flytta diskussionen till Django Forum.
Välskrivna felrapporter är obeskrivligt användbara. Det finns dock en viss mängd kostnader involverade i att arbeta med alla felhanteringssystem, så din hjälp med att hålla vår ärendehanterare så användbar som möjligt uppskattas. I synnerhet:
\n**Läs också FAQ för att se om ditt problem kan vara en välkänd fråga.
**Fråga på Django Forum eller Django Discord server först om du inte är säker på om det du ser är en bugg.
Skriv fullständiga, reproducerbara och specifika felrapporter. Du måste inkludera en tydlig, kortfattad beskrivning av problemet och en uppsättning instruktioner för att replikera det. Lägg till så mycket felsökningsinformation som möjligt: kodavsnitt, testfall, backtraces för undantag, skärmdumpar osv. Ett trevligt litet testfall är det bästa sättet att rapportera en bugg, eftersom det ger oss ett användbart sätt att snabbt bekräfta buggen.
**Posta inte på Django Forum bara för att meddela att du har lämnat in en felrapport. Alla ärenden skickas till en annan lista, django-updates, som spåras av utvecklare och intresserade medlemmar i gemenskapen; vi ser dem när de lämnas in.
To understand the lifecycle of your ticket once you have created it, refer to\nArbetsflöde för triagering.
\nOm din bugg påverkar något visuellt av naturen finns det några ytterligare riktlinjer att följa:
\nInkludera skärmdumpar i ditt ärende som är den visuella motsvarigheten till ett minimalt testfall. Visa upp problemet, inte de galna anpassningar du har gjort i din webbläsare.
Om det är svårt att visa upp problemet med en stillbild kan du överväga att ta en kort screencast. Om din programvara tillåter det, ta bara den relevanta delen av skärmen.
Om du erbjuder en patch som ändrar utseendet eller beteendet hos Djangos UI, måste du måste bifoga före och efter skärmdumpar / skärmsändningar. Ärenden som saknar dessa är svåra för triagers att bedöma snabbt.
Skärmdumpar befriar dig inte från andra goda rapporteringsmetoder. Se till att inkludera webbadresser, kodavsnitt och steg-för-steg-instruktioner om hur du reproducerar det beteende som syns i skärmdumparna.
Se till att sätta UI/UX-flaggan på ärendet så att intresserade parter kan hitta ditt ärende.
Om problemet rör tillgänglighet, länka till relevant tillgänglighetsstandard om tillämpligt.
Vi försöker alltid göra Django bättre, och dina funktionsförfrågningar är en viktig del av det. Här är några tips om hur du gör en begäran på effektivaste sätt:
\nUtvärdera om funktionsidén kräver ändringar i Djangos kärna. Om din idé kan utvecklas som en oberoende applikation eller modul - till exempel om du vill stödja en annan databasmotor - kommer vi förmodligen att föreslå att du utvecklar den självständigt. Om ditt projekt sedan samlar tillräckligt med stöd från gemenskapen kan vi överväga att inkludera det i Django.
Föreslå funktionen i GitHub-projektet new feature ideas (inte i ärendehanteraren) genom att skapa ett nytt objekt i kolumnen Idea. Det är här som gemenskapen och Steering Council utvärderar nya idéer för Djangos ekosystem. Detta steg är särskilt viktigt för stora eller komplexa förslag. Vi föredrar att diskutera alla betydande förändringar av Djangos kärna innan någon utveckling påbörjas. I vissa fall kan en funktion vara bättre lämpad som ett tredjepartspaket, där den kan utvecklas oberoende av Djangos utgivningscykel.
Beskriv klart och koncist vad det är som saknas och hur du skulle vilja att det implementerades. Inkludera exempelkod (icke-funktionell är OK) om möjligt.
Förklara varför du skulle vilja ha funktionen. Att förklara ett minimalt användningsfall hjälper andra att förstå var det passar in och om det redan finns andra sätt att uppnå samma sak.
Se även: Dokumentera nya funktioner.
\nRapporter om prestandaförluster eller förslag på prestandaoptimeringar bör innehålla riktmärken och kommandon som ärendehanteraren kan reproducera.
\nSe django-asv riktmärken för mer information om Djangos befintliga benchmarks.
\nNär det är möjligt strävar vi efter grov konsensus. Emoji-reaktioner används på frågor inom GitHub-projektet new feature ideas för att spåra återkoppling från gemenskapen. Följande betydelser tilldelas varje reaktion:
\n👍: Jag stöder den här funktionen och skulle använda den
👎: Jag motsätter mig den här funktionen eller tror att den skulle orsaka problem för mig eller Django
😕: Jag har ingen stark åsikt om den här funktionen
🎉: Den här funktionen verkar som ett enkelt och fördelaktigt tillägg
Steering Council kommer regelbundet att granska idéerna i projektet och flytta de idéer som har stöd i gemenskapen genom följande steg:
\nIdé
Godkänd - Förfining av idéer - Skapande av team
Påbörjad
Arbetslösning - Granskning - Feedback
Behöver underhållare (endast Django)
Klar
Ibland kan diskussioner om funktionsidéer eller Djangos riktning äga rum på Django Forum. Dessa diskussioner kan innehålla informella röster, som följer den röstningsstil som uppfanns av Apache och används på Python själv, där rösterna ges som +1, +0, -0 eller -1. Grovt översatt betyder dessa röster:
\n+1: ”Jag älskar idén och jag är starkt engagerad i den.”
+0: ”Låter okej för mig.”
-0: ”Jag är inte så förtjust, men jag tänker inte stå i vägen.”
-1: ”Jag håller inte alls med och skulle bli mycket olycklig om idén blev verklighet.”
Även om dessa omröstningar är informella kommer de att tas på stort allvar. Om det efter en lämplig omröstningsperiod uppstår ett uppenbart samförstånd kommer vi att följa omröstningarna.
\nTesting pre-releases is a great way to contribute to Django. Early testers\nhelp catch bugs before the final release, ensuring a smoother upgrade\nexperience for everyone.
\nBefore testing a pre-release, it is important that your project is running\nsmoothly on the latest stable release of Django. That way, any regressions can\nbe attributed to the pre-release. See the Så här uppgraderar du Django till en nyare version guide\nfor instructions on getting up to date.
\nTo ensure your project is ready, you should also:
\nRead the release notes: Review the Versionsinformation for the\nupcoming version to learn about upgrade paths for deprecated features or\nabout minor backward-incompatible changes.
Resolve deprecation warnings: Run your tests with deprecation warnings\nenabled to become aware of required follow-up actions:
\n$ python -Wa manage.py test\nYou can install the latest pre-release using pip:
$ python -m pip install --pre Django\nOnce installed, run your project’s test suite. Rather than just checking\nif tests pass, try the following:
\nCheck dependency support: Determine whether major dependencies support\nthe new version by checking Django version classifiers on PyPI.\nSince those projects also value early bug reports, don’t let a lack\nof support prevent you from testing.
Monitor performance: You can run your tests with the test\n--durations flag to identify potential performance regressions.
Automate tests in CI: Consider running your Continuous Integration (CI)\npipeline with the pre-release version.
Test manually: While automated tests are great, manually testing your\napplication’s main workflows is an important part of verifying compatibility\nwith a new release.
If you discover a bug, please report it via the Django issue tracker so it can be fixed before the final\nrelease. When creating the ticket, be sure to set the Django version field to\nthe exact pre-release version you are testing.
\nIf you suspect a regression, it’s helpful to report the specific commit that\ncaused it. See Bisektion av en regression for instructions.
\nYou can also discuss any issues or share feedback in the Pre-releases category\non the Django Forum.
\n