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.
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.
För att förstå livscykeln för ditt ärende när du har skapat det, se Bedömning av ärenden.
\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.
\n