Hvordan jeg gik fra at være bidragyder til en Open Source-projektleder

Jeg var en ensidig softwareudvikler. Da jeg var på college deltog jeg på KDE-konferencen. Det var mit første møde med open source-verdenen. På konferencen syntes jeg, at præsentanterne og de mennesker, der løfter hænderne, var meget smarte. Jeg vidste, at der var gratis software tilgængelig, skabt af samfundet for samfundet. Men de udviklere, der bygger det, var fremmed for mig.

Jeg troede virkelig seje, intelligente mennesker udviklede denne software. Jeg troede, du skulle være rigtig smart og privilegeret for at komme med dem.

Jeg prøvede at deltage i Google Summer of Code (GSOC) to gange på college, men var ikke succesrig. Derefter brugte jeg efter uddannelsen under mit job masser af open source-projekter. Jeg brugte dem endda ved freelancing. Jeg var stærkt afhængig af samfundsudviklede værktøjer og teknologi. Jeg var virkelig fascineret af folks historier om, hvordan de begyndte at bidrage til open source, og hvordan de fik deres fantastiske fjernjob!

Nu efter at have udskudt yderligere to måneder og ikke været i stand til at lande et fjernt job, besluttede jeg at gøre det en gang for alle og bidrage med mig selv.

Jeg begyndte at uploade min kode til GitHub - når jeg skrev nogen ny kode. Jeg oprettede et open source NPM-modul sammen med nogle andre demoprojekter og uploadede dem. Men dette var ikke kernen i open source. Jeg bidrog faktisk ikke til andre repos eller arbejdede med andre udviklere for at oprette software. Jeg arbejdede stadig isoleret.

Hacktoberfest!

Så kom det: Jeg snuble over Hacktoberfest. De (DigitalOcean, GitHub og Twilio) gav væk en gratis t-shirt, hvis du indsendte 5 Pull-anmodninger til et open source-projekt på GitHub i oktober. Selv hvis din PR ikke blev slået sammen, tællede den stadig med til din fremgang. Og denne gang havde de et væld af t-shirts, så det var let at få en. Dette var det sidste skub, jeg havde brug for - tilsyneladende giver en gratis t-shirt dig et fantastisk løft !.

Så således begyndte jeg min rejse i OPEN SOURCE WORLD.

Sporing af problemerne

Jeg søgte efter open source-projekter, der skulle tackle på GitHub. Jeg ville have nogle lette opgaver for hurtigt at blive fortrolige med PR-processen. Så jeg kiggede efter problemer, som ikke krævede, at jeg hoppede ind i hele kildekoden.

Der var mange udviklere, der startede projekter for Hacktoberfest og nye. Det var let at indsende PR i disse repos, så jeg sendte tre PR'er. Jeg sendte mine to andre PR'er til andre menneskers personlige projekter. Der var mange andre repos, hvor du bare skulle tilføje dit navn til filen og indsende PR. Men jeg besluttede, at dette ikke var produktivt og ikke var ånden i open source.

Så kom jeg over denne fantastiske udvikler. Hun havde oprettet en statisk blog i Vue.js og havde mange anførte problemer. Da jeg så alle problemerne, fandt jeg ud af, at hun dybest set lavede en personlig blog og fik folk til at bidrage ved at rejse spørgsmål og mærke dem med passende tags. Jeg var som .

Så indså jeg, at ideen var fantastisk, og jeg var som,

hahaha

Jeg var imponeret over hendes talent! Hun var ved at opbygge sin statiske blog, og det gavne også andre udviklere. Førstegangere lærte at arbejde i open source og få en gratis t-shirt. Hun fik sin blog gennem en gruppeindsats!

At opdage hendes blog er det, der motiverede mig til at oprette guiden til god mad.

Fremvejen af ​​guiden til god mad

Jeg havde allerede besluttet, hvad jeg skulle gøre, når jeg var færdig med at indsende mine PR'er. Så efter to dages arbejde og indsendelse af PR'er var det tid til en ny begyndelse. Jeg blev inspireret af alle andre udviklere, der havde oprettet en repo til støtte for Hacktoberfest. De skabte alle et indbydende miljø for at tilskynde nytilkomne til at indsende produktive PR'er. Jeg ønskede også at give mit bidrag til denne bevægelse og besluttede at oprette min egen projektrepo.

Jeg vil også gerne blive en iværksætter, og jeg har en liste, der indeholder flere ideer. Men jeg ville ikke lægge for meget tid på at beslutte, hvilket projekt jeg skulle starte. Jeg kiggede igennem alle ideerne og valgte den, jeg troede var let at forstå og let at implementere.

Jeg valgte at bygge guiden til god mad. Min søster og jeg plejede at Google om, hvilke fødevarer jeg skulle spise for at helbrede en bestemt sygdom. Jeg tænkte, hvad hvis der allerede er et sted, hvor du bare kan gå og søge efter dine symptomer eller sygdomme, og det fortæller dig om de mad, du skal spise? Det skal være tilgængeligt på alle sprog, så flere kan bruge det let.

Så jeg oprettede en grundlæggende brugergrænseflade, der formidlede motivation og brug af hjemmesiden. Jeg ville hurtigt uploade det, så jeg besluttede at kun have alle data i en statisk fil. Jeg ville vælge en teknologi, der var let at lære og meget udbredt på. Dette vil give nye udviklere mulighed for at lære eller eksisterende udviklere at øve. Så jeg endte med at bruge React.

Oven på det besluttede jeg at bruge NextJs til at udnytte mange af dens funktioner. Det er også let at bruge, hvis du allerede kender React. Jeg uploadede hele projektet på GitHub, og rejsen begyndte. Men dette var ikke nok til at tiltrække udviklerne.

Vedligeholders stigning

Efter at have foretaget den oprindelige kode producerede jeg derefter korrekt dokumentation. Jeg oprettede problemer med de relevante etiketter. Jeg oprettede spørgsmålet, ligesom vi skaber opgaver i en smidig sprint. Desuden delte jeg opgaverne i underopgaver og anførte dem med detaljerede oplysninger.

Da jeg ledte efter problemer at bidrage til, kiggede jeg efter problemer med et detaljeret problem og instruktioner til løsningen. Så jeg prøvede at inkludere de oplysninger, jeg oprindeligt kiggede efter i emnerne.

Dette fungerede som en charme, og det var præcis, hvad der var nødvendigt for at få de første timer-bidragydere ombord. De fleste populære projekter er nyttige at bidrage til. Manglen på information i emner fungerer som en demotivering for dem. På grund af dette fungerer de fleste af dem ikke på faktiske problemer efter at have udarbejdet koden.

Eksempel problem

eksempel problem

En ting mere, som jeg gjorde, var at udgive mastergrenen med Netlify. Netlify har en fantastisk integrationsapp med GitHub. Så hvis nogen PR er fusioneret, kan bidragyderen se ændringen gå LIVE næsten øjeblikkeligt.

Resultatet? Jeg fik 3 PR'er og 4 anmodninger om at arbejde på kun 2 timer (fortalte dig, kraften i gratis T-shirt er meget stærk ).

Jeg gik med succes fra at være en bidragyder til en projektleder!

At forstå den anden side af mønten

Repoen blev mere og mere populær. Folk rejste spørgsmål til forslag, indsendte PR'er og kommenterede emner. Min repo fik opmærksomhed, og det var bare fantastisk.

Jeg fik meddelelser hele dagen. Hver time skulle jeg modtage mindst en anmeldelse fra GitHub! Jeg jonglerede her og der. Jeg var ved at gennemgå PR'er, besvare kommentarer, fusionere PR'er, rejse flere spørgsmål og bidrage.

En fantastisk funktion, der kom godt med at integrere Netlify, var, at den automatisk indstiller CI (Kontinuerlig integration) til dit projekt. Den udfører forskellige kontroller af den indsendte PR, og giver også en testdistribution, hvor du kan kontrollere integrationen. Jeg anbefaler at bruge denne funktion i alle projekter, du kan!

Som et resultat lærte folk at have det sjovt! Og også at få en gratis T-shirt. Jeg lærte så meget om GitHub og git. Pro tip: Hvis du vil lære git hurtigt, bliver du en open source-projektleder. Det gav mig et nyt perspektiv og udvidede min vision. Så det var en win-win situation for os alle.

”Alt, hvad der kan gå galt, vil gå galt.” - Murphys lov

I nogen tid vil jeg tjekke PR-detaljerne, skumme gennem koden, se på den implementerede integration og flette PR'erne. Nogle gange, på grund af mange verserende PR'er, ville det efter sammenlægning af den første PR skabe en ringvirkning, og der ville være konflikter i alle andre PR'er. Nu så det oprindeligt dårligt ud, men det var en velsignelse i forklædning. På grund af dette lærte jeg, hvordan jeg løser konflikter i git. Jeg løste mange konflikter. Githubs onlineeditor til fusionering af PR'er viste sig meget praktisk til små ændringer.

Selvom PR'erne ikke alle havde god kodekvalitet, fusionerede jeg stadig de fleste af dem. For da de var fra første gang bidragydere, ville jeg ikke afholde dem fra at indsende flere PR'er. Jeg kender følelsen, når du sender en PR og venter på, at vedligeholderen godkender eller kommenterer den. Så for at holde bidragydernes ånd op, besluttede jeg at fusionere PR og derefter selv rydde op (og jeg tror, ​​dette resulterede i en positiv følelse for bidragydere).

Da antallet af PR'er steg, kunne jeg ikke give meget tid til at bidrage med mig selv. Det meste af min tildelte tid ville gå til at besvare kommentarer, e-mails og sammenlægning og løsning af PR'er. Efter tre dage satte jeg mig ned for at rense koden. Det var et rod, jeg kun inviterede. Jeg indså, at jeg skulle have informeret bidragydere om i det mindste at følge nogle retningslinjer. Filnavne, funktionsnavne og projektstruktur var alt forkert. Da webstedet udviklede sig, var det også problemerne.

Jeg var nødt til at strukturere hele kodebasen. Det var en banebrydende ændring, men det var meget nødvendigt. Hvis dette fortsætter, ville koden ikke blive vedligeholdelig efter nogen tid. Dette var, da jeg indså, hvorfor mange virksomheder understreger deres kodningsstandarder. Jeg mener, jeg vidste allerede vigtigheden, men at opleve det førstehånds som projektleder var en anden ting! Jeg kunne se, hvorfor mange populære open source-projekter var stive om deres kodningsstandarder.

Jeg kan også se, hvordan min tankeproces har udviklet sig de sidste 10-11 dage. Jeg var en naiv bidragyder, der arbejdede på hans eget depot, men formåede at blive en projektleder, der arbejdede med alle andre udviklere.

GitHub-statistikker

Her er stjerner, gafler og bidragydere i de sidste 11 dage!

GitHub-statistik

Resultatet!

Et ikke-responsivt websted oprettet på 10 minutter!

HjemOm

Efter 11 dage,

HjemOm osBidragyderefoodDetails (igangværende arbejde)betingelser

Du kan også tjekke den seneste version af hjemmesiden live på https://good-food-guide.now.sh.

Hver dag forbedres webstedet på en lille eller stor måde.

Bundlinie

Denne 11 dages rejse har været fantastisk for mig. Jeg har lært meget. Nu kan jeg se begge sider af mønten.

Jeg ser et teams magt, og hvad det kan opnå. Hvis en håndfuld mennesker beslutter at arbejde på et bestemt emne, kan de løse alt. Folk har brug for et indbydende miljø og en lille smule belønning for at forblive motiverede.

Det kan være vanskeligt for nye udviklere at begynde at bidrage. De ser efter problemer, der skal løses, men det er ikke den eneste måde at begynde at bidrage med. Hovedideen er at have det sjovt og opbygge noget kollektivt for at forbedre et stykke software. Hvis du har brugt det og ved noget, du kan forbedre, kan du direkte rejse problemet, diskutere med vedligeholderen og indsende en PR. Jeg tror, ​​dette er en af ​​de bedste måder at starte på.

Det blev klart for mig, hvordan en projektleder bruger hver enkelt persons styrker til at udføre en opgave, der ville have været svært, hvis det udføres af en enkelt person. Dette er den samme situation i open source-projekter. Vedligeholders job svarer til projektlederen. De skal opretholde harmoni mellem alle udviklere og også lytte til deres tanker.

Jeg indså også, at jeg før havde denne frygt for en stor codebase, hver gang jeg ville tænke på at deltage i et nyt open source-projekt. Jeg ville samle koden, køre den og glemme den. Nu er den frygt gået, og jeg tror, ​​jeg kan tage det store skridt hen imod at bidrage til store projekter. Jeg håber at fortsætte med at lære nye ting og blive et godt aktiv for open source-samfundet.

Tak fordi du læste! Og en stor tak til Jennifer og Abbey fra freeCodeCamp for gennemgangen. De hjalp mig med at forberede denne artikel og gøre det værd at din tid.

Hvis du har spørgsmål eller forslag, så lad dem ligge i kommentarerne herunder.

P. S. Hvis du fandt, at denne artikel var nyttig, klap! Det føles givende og giver mig motivation til at fortsætte med at skrive.

Redigere:

Opdaterede URL'en til Live-webstedet til https://good-food-guide.now.sh.