Rapportering av buggar och önskemål om funktioner

Viktigt

Rapportera säkerhetsproblem endast till [e-mail]. Detta är en privat lista som endast är öppen för Django-utvecklare med lång erfarenhet och högt förtroende, och dess arkiv är inte offentliga. För ytterligare detaljer, se vår säkerhetspolicy.

Rapportering av buggar

Innan du rapporterar en bugg på ticket tracker bör du tänka på följande punkter:

• Kontrollera 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 biljettsystemet 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 biljettspåraren för långa diskussioner, eftersom de sannolikt kommer att gå förlorade. Om en viss biljett är kontroversiell, flytta diskussionen till Django Forum.

Välskrivna buggrapporter är obeskrivligt användbara. Det finns dock en viss mängd kostnader involverade i att arbeta med alla buggspårningssystem, så din hjälp med att hålla vår biljettspårare så användbar som möjligt uppskattas. I synnerhet:

• **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 samhället; 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 Triagering av biljetter.

Rapportering av buggar i användargränssnittet

Om din bugg påverkar något visuellt av naturen finns det några ytterligare riktlinjer att följa:

• Inkludera 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ärmdumpar. Biljetter 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å biljetten så att intresserade parter kan hitta din biljett.

• Om problemet rör tillgänglighet, länka till relevant :ref:tillgänglighetsstandard <accessibility-standards> om tillämpligt.

Begär funktioner

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:

• Utvä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 biljettspåraren) genom att skapa ett nytt objekt i kolumnen Idea. Det är här som samhället och :ref:``Steering Council <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.

Begäran om prestandaoptimeringar

Rapporter om prestandaförluster eller förslag på prestandaoptimeringar bör innehålla riktmärken och kommandon som ärendehanteraren kan reproducera.

Se django-asv riktmärken för mer information om Djangos befintliga benchmarks.

Hur vi fattar beslut

När det är möjligt strävar vi efter grov konsensus. Emoji-reaktioner används på frågor inom GitHub-projektet nya funktionsidéer för att spåra återkoppling från samhället. Följande betydelser tilldelas varje reaktion:

• 👍: 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 samhället genom följande steg:

• Idé

• 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:

• +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.