Sådan tiltrækker du nye bidragydere til dit open source-projekt

Det er svært at tiltrække bidragydere til dit FOSS-projekt - især bidragydere, der er nye med open source.

Projektholdere diskuterer ofte at gøre deres open source-projekter mere begyndervenlige, så de kan tiltrække nye bidragydere og få dem til at føle sig velkomne. Men denne dialog bliver ofte fanget i ekkokammeret for vedligeholdere selv. I stedet er det nødvendigt at involvere den anden part: de nye bidragydere selv.

I løbet af min korte tid som en open source-bidragyder har jeg gennemgået en masse projekter og også bidraget til et par af dem. I dette indlæg prøver jeg at liste op, hvad der appellerede til mig som en ny bidragyder, og hvad der ikke gjorde det. Og jeg vil bruge et par projekter som casestudier.

Tip nr. 1: Mærk nybegynderudgaver korrekt

Dette er bestemt den vigtigste betragtning for mig som en potentiel bidragyder.

Etiketter gør det lettere at finde problemer, der kan fungere som et strandhoved for et første bidrag. Hvis dit projekt ikke har disse, hæver det markant søjlen for at bidrage til det.

Det er meget vanskeligt for nogen, der ikke er bekendt med din codebase, at måle vanskeligheden ved et problem. Så en generisk etiket som efterspurgt hjælp er ikke nyttig nok på egen hånd. Prøv at bruge mere specifikke etiketter, såsom god første bug, let, lavt hængende frugt osv. For at kommunikere, at et problem er let nok til et indledende bidrag.

Tip nr. 2: Opret korrekt bidragende retningslinjer

En velskrevet Contributing.md kan beskrive den arbejdsgang, som dine projekters vedligeholdere forventede bidragydere vil følge. Dette er let at dokumentere og sparer begge sider en betydelig mængde tid.

Specificer, om bidragyderen skal arbejde på en separat filial for hvert nummer, eller om at sprænge deres forpligtelser og rebase deres ændringer, inden du indsender en PR. Prøv at linke til en passende tutorials for hver af disse processer, hvis bidragyderen endnu ikke er bekendt med dem.

Tip nr. 3: Dokument dit projekt design, arkitektur og katalogstruktur

At have et dokument, der giver et overblik på højt niveau af design og arkitektur for dit projekt, kan spare begge parter meget tid.

I stedet for at forklare den samme ting igen og igen for enhver ny bidragyder, skal du notere de spørgsmål, der ofte er, og opret en FAQ lige der på din README.md.

Den brateste barriere for de fleste nye bidragydere er at navigere i tætte codebaser. Hjælp nykommere med at finde vej ved at tilbyde en beskrivelse af din mappestruktur.

En masse nye bidragydere er juniorudviklere, der måske endnu ikke kender en masse fælles arkitektur og designpatroner. Opret dokumenter, der fremhæver disse beslutninger og begrundelsen bag dem.

Tip nr. 4: Sæt på plads en klar adfærdskodeks

Opret en ordentlig adfærdskodeks, der eksplicit angiver regler inden for dit FOSS-samfund. En masse nye bidragydere, inklusive mig, er bange for at blive behandlet dårligt eller set ned på, mens de prøver at bidrage.

Din adfærdskodeks, der tydeliggør, hvordan du rapporterer overtrædelser, kan hjælpe folk med at føle sig trygge. Dette indebærer også, at man kaldes dårlig opførsel på hvert trin, uanset hvilken person der er involveret, og træffer passende handlinger.

Tip # 5: Opret skabeloner til pull-anmodninger og problemer

En ordentlig problemskabelon kan hjælpe folk med bedre at beskrive det miljø, der kræves for at gengive en fejl. Bidragyderne kan derefter begynde at arbejde på problemet straks uden at skulle samle information fra forskellige steder. Dette sparer tid for begge parter.

Et lignende argument kan fremsættes for skabelon med pull-anmodning. Lav klart klart, hvad der forventes, når en bidragyder indsender en PR, herunder formatet for deres engagementsmeddelelse, testplan, de foretagne ændringer. Dette hjælper også med kodegennemgang og sparer alle endnu mere tid.

Tip nr. 6: Prioriter svar på trækanmodninger

At være vedligeholder af et populært FOSS-projekt er en utrolig mængde arbejde. De fleste får ikke betalt for at bidrage til FOSS - både vedligeholdere og bidragydere. De fleste vedligeholdere har ikke tid nok til at gennemgå alle PR'er med den samme mængde kontrol.

Prioriter PR'er, så bidragydere på forhånd kan forstå, om de kan forvente at modtage feedback til en lav prioritet / let fejlrettelse.

Tip nr. 7: Velkommen til alle former for bidrag

Vores felt har en grim tendens til at se ned på ikke-kode oversættelser. Lad ikke dit projekt falde bytte for denne mentalitet.

Opmuntrer til alle former for bidrag, det være sig dokumentation, kode, fastsættelse af skrivefejl, test - hvad som helst.

Tip nr. 8: Beløn ​​nye bidragydere

Hvis du har budgettet, kan du belønne nye bidragydere ved at sende dem swag, f.eks. Klistermærker eller skjorter.

Hvis dit budget ikke tillader det, kan en simpel råb eller omtale i en blogpost eller på sociale medier også gå langt. Det får dem til at indse, at deres bidrag - uanset store som små - ikke overses, og at de værdsættes.

Dette skaber en følelse af tilhørighed, der kan inspirere dem til at bidrage mere.

Kent C. Dodds lavede en fin open source-specifikation for dette: Alle bidragydere.

En god start kan være at opretholde en liste over bidragydere på dit projektwebsted og / eller depot.

Til sidst skader det aldrig at huske, at alle engang var en juniorudvikler. På et tidspunkt havde de brug for hjælp til at komme på det niveau, de er på i dag.

Denne enkle kendsgerning kan gå langt med at etablere en sund kultur for mentorskab i din open source organisation. At behandle alle med respekt - uanset deres baggrund - er afgørende for at køre et vellykket open source-projekt.

Jeg tweetede ovenstående for et stykke tid tilbage, da jeg lige var kommet i gang med at bidrage til FOSS. Men siden da er meget ændret. Jeg har endelig konkluderet:

Open source handler langt mere om mennesker, end det nogensinde vil handle om kode.

P. S. Jeg prøver at oprette en liste over begyndervenlige FOSS-projekter. Hvis dit open source-projekt har noget materiale, der er relevant for nye bidragydere, skal du overveje at åbne et problem på dette arkiv.

Et råb til Dan Abramov, Kent C. Dodds og Quincy Larson for at have hjulpet mig med dette stykke ved at give deres perspektiver som vedligeholdere.

Hvis du har flere tip at tilføje til dette indlæg, er du velkommen til at kontakte mig eller svare nedenfor.

Og hvis du fandt det nyttigt, skal du trykke på eller klikke på “︎❤” for at hjælpe med at promovere dette stykke til andre.