Råd till nya bidragsgivare¶
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.
Kom igång och kör!
Om du är nybörjare på att bidra till Django ger handledningen Skriva ditt första bidrag till Django dig en introduktion till verktygen och arbetsflödet.
Den 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.
Om du letar efter en referens om detaljerna för att göra kodbidrag, se Bidra med kod dokumentation.
Första stegen¶
Börja med dessa steg för att upptäcka Djangos utvecklingsprocess.
Triage-biljetter¶
Om en ”icke-granskad ticket” rapporterar en bugg, försök att reproducera den. Om du kan återskapa den och den verkar giltig, gör en notering om att du har bekräftat buggen och acceptera ärendet. Se till att ärendet arkiveras under rätt komponentområde. Överväg att skriva en patch som lägger till ett test för buggens beteende, även om du inte åtgärdar själva buggen. Se mer på hur-kan-jag-hjälpa-till-med-triaging
Granskning av accepterade ärenden¶
Detta 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!
Håll gamla korrigeringar uppdaterade¶
Ofta kommer kodbasen att ändras mellan det att en patch skickas in och det att den granskas. Se till att den fortfarande tillämpas korrekt och fungerar som förväntat. Att uppdatera en patch är både användbart och viktigt! Se mer på Inlämning av bidrag.
Skriva lite dokumentation¶
Djangos dokumentation är bra, men den kan alltid förbättras. Hittade du ett skrivfel? Tycker du att något borde förtydligas? Gå vidare och föreslå en dokumentationspatch! Se även guiden om skriva-dokumentation.
Observera
Sidan reports innehåller länkar till många användbara Trac-frågor, inklusive flera som är användbara för att triagera ärenden och granska korrigeringar enligt förslaget ovan.
Skriv under licensavtalet för bidragsgivare¶
Den kod som du skriver tillhör dig eller din arbetsgivare. Om ditt bidrag är mer än en eller två rader kod måste du underteckna CLA. Se ”FAQ om licensavtal för bidragsgivare” för en mer ingående förklaring.
Riktlinjer¶
Som 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.
Välj ett ämnesområde¶
Det 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.
Analysera biljetternas sammanhang och historia¶
Trac ä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 en biljett inte har det stöd som krävs för att komma in i Django.
Börja i liten skala¶
Det är lättare att få feedback på en liten fråga än på en stor. Se ”lätta val”.
Bekräfta stöd innan du påbörjar en stor uppgift¶
Det 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.
Var djärv! Lämna feedback!¶
Ibland kan det vara skrämmande att ge sin åsikt till världen och säga ”den här biljetten ä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!
Var försiktig när du markerar saker som ”Redo för incheckning”¶
Om du verkligen inte är säker på om en biljett är klar, 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.
Vänta på feedback och svara på den feedback du får¶
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.
Var rigorös¶
Nä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.
Ha tålamod¶
Det ä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.
Det ä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.
Kom ihåg att Django har en åtta månaders utgivningscykel, så det finns gott om tid för din patch att granskas.
Slutligen kan en vältajmad påminnelse hjälpa till. Se :ref:``bidra med kod FAQ <new-contributors-faq>` för idéer här.
