Rapportering av buggar och önskemål om funktioner

Viktigt

Please report security issues only to [e-mail]. This is a private list only open to long-time, highly trusted Django developers, and its archives are not public. For further details, please see our security policies.

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 ä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 shepherding 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:

• **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 Arbetsflöde för triagering.

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ä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.

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 ä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.

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 new feature ideas för att spåra återkoppling från gemenskapen. 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 gemenskapen 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.

How to test pre-release versions of Django

Testing pre-releases is a great way to contribute to Django. Early testers help catch bugs before the final release, ensuring a smoother upgrade experience for everyone.

Förutsättningar

Before testing a pre-release, it is important that your project is running smoothly on the latest stable release of Django. That way, any regressions can be attributed to the pre-release. See the Så här uppgraderar du Django till en nyare version guide for instructions on getting up to date.

To ensure your project is ready, you should also:

• Read the release notes: Review the Versionsinformation for the upcoming version to learn about upgrade paths for deprecated features or about minor backward-incompatible changes.

• Resolve deprecation warnings: Run your tests with deprecation warnings enabled to become aware of required follow-up actions:

  $ python -Wa manage.py test
  

Testing your project

You can install the latest pre-release using pip:

$ python -m pip install --pre Django

Once installed, run your project’s test suite. Rather than just checking if tests pass, try the following:

• Check dependency support: Determine whether major dependencies support the new version by checking Django version classifiers on PyPI. Since those projects also value early bug reports, don’t let a lack of support prevent you from testing.

• Monitor performance: You can run your tests with the test --durations flag to identify potential performance regressions.

• Automate tests in CI: Consider running your Continuous Integration (CI) pipeline with the pre-release version.

• Test manually: While automated tests are great, manually testing your application’s main workflows is an important part of verifying compatibility with a new release.

Reporting issues

If you discover a bug, please report it via the Django issue tracker so it can be fixed before the final release. When creating the ticket, be sure to set the Django version field to the exact pre-release version you are testing.

If you suspect a regression, it’s helpful to report the specific commit that caused it. See Bisektion av en regression for instructions.

You can also discuss any issues or share feedback in the Pre-releases category on the Django Forum.