Ny bidragsgivare och inte säker på vad du ska göra? Vill du hjälpa till men vet bara inte hur du ska komma igång? Det här är avsnittet för dig.
\n\nDen här sidan innehåller mer allmänna råd om hur du kan bidra till Django och hur du ska gå tillväga för att göra det.
\nOm du letar efter en referens om detaljerna för att göra kodbidrag, se Bidra med kod dokumentation.
\nBörja med dessa steg för att upptäcka Djangos utvecklingsprocess.
\nIf an unreviewed ticket reports a bug, try and reproduce it. If you can\nreproduce it and it seems valid, make a note that you confirmed the bug and\naccept the ticket. Make sure the ticket is filed under the correct component\narea. Consider writing a patch that adds a test for the bug’s behavior, even if\nyou don’t fix the bug itself. See more at How can I help with development?.
\nDetta kommer att hjälpa dig att bygga upp en förtrogenhet med kodbasen och processerna. Markera lämpliga flaggor om en patch behöver dokument eller tester. Titta igenom de ändringar som en patch gör och håll utkik efter syntax som är inkompatibel med äldre men fortfarande stödda versioner av Python. Kör testerna och se till att de godkänns. Där det är möjligt och relevant, prova dem på en annan databas än SQLite. Lämna kommentarer och feedback!
\nOftentimes the codebase will change between a patch being submitted and the\ntime it gets reviewed. Make sure it still applies cleanly and functions as\nexpected. Updating a patch is both useful and important! See more on\nChecklista för bidrag.
\nDjango’s documentation is great but it can always be improved. Did you find a\ntypo? Do you think that something should be clarified? Go ahead and suggest a\ndocumentation patch! See also the guide on\nSkriva dokumentation.
\n\nThe code that you write belongs to you or your employer. If your contribution\nis more than one or two lines of code, you have the option to sign the CLA.\nSee the Contributor License Agreement FAQ for a more thorough explanation.
\nSom nykomling i ett stort projekt är det lätt att uppleva frustration. Här är några råd för att göra ditt arbete med Django mer användbart och givande.
\nDet ska vara något som du bryr dig om, som du är bekant med eller som du vill lära dig mer om. Du behöver inte redan vara expert på det område som du vill arbeta med; du blir expert genom dina löpande bidrag till koden.
\nTrac är inte en absolut sanning, utan sammanhanget är lika viktigt som orden. När du läser Trac måste du ta hänsyn till vem som säger saker och när de sades. Stöd för en idé för två år sedan behöver inte betyda att idén fortfarande har stöd. Du måste också vara uppmärksam på vem som inte har talat - till exempel, om en erfaren bidragsgivare inte nyligen har varit inblandad i en diskussion, kanske ett ärende inte har det stöd som krävs för att komma in i Django.
\nDet är lättare att få feedback på en liten fråga än på en stor. Se ”lätta val”.
\nDet innebär att du måste få någon annan att bekräfta att en bugg är verklig innan du åtgärdar problemet, och att du måste se till att det finns konsensus om en föreslagen funktion innan du implementerar den.
\nIbland kan det vara skrämmande att ge sin åsikt till världen och säga ”det här ärendet är korrekt” eller ”den här patchen behöver bearbetas”, men det är det enda sättet för projektet att gå framåt. Bidragen från den breda Django-gemenskapen har i slutändan en mycket större inverkan än någon enskild persons. Vi kan inte göra det utan dig!
\nOm du verkligen inte är säker på om ett ärende är klart, markera den inte som sådan. Lämna en kommentar istället, så att andra får veta hur du tänker. Om du är mestadels säker, men inte helt säker, kan du också försöka fråga på kanalen #contributing-getting-started i Django Discord server för att se om någon annan kan bekräfta dina misstankar.
Fokusera på ett eller två ärenden, ta hand om dem från början till slut och upprepa. Att ta sig an en massa ärenden och låta några falla mellan stolarna gör mer skada än nytta.
\nNär vi säger ”PEP 8, och måste ha dokument och tester”, så menar vi det. Om en patch inte har dokument och tester, måste det finnas en bra anledning till det. Argument som ”Jag kunde inte hitta några befintliga tester av den här funktionen” väger inte särskilt tungt. Även om det kan vara sant, betyder det att du har det extra viktiga jobbet att skriva de allra första testerna för den funktionen, inte att du slipper skriva tester helt och hållet.
\nDet är inte alltid lätt att få en snabb genomgång av din ticket eller din patch. Det här är inte personligt. Det finns många ärenden och pull requests att gå igenom.
\nDet är viktigt att hålla din patch uppdaterad. Granska ärendet på Trac för att se till att flaggorna Behövs tester, Behövs dokumentation och Patch behöver förbättras är avmarkerade när du har åtgärdat alla granskningskommentarer.
\nKom ihåg att Django har en åtta månaders utgivningscykel, så det finns gott om tid för din patch att granskas.
\nSlutligen kan en vältajmad påminnelse hjälpa till. Se bidra med kod FAQ för idéer här.
\n