Fortsetter serien om de forskjellige måtene man kan lære om de tekniske aspektene ved Bitcoin, i denne artikkelen vil vi fokusere på gode første problemer i Bitcoin Core GitHub-depotet.

Bitcoin Core er allment anerkjent som referanseimplementering for Bitcoin. Selv om navnet “Bitcoin Core” ikke ble brukt før 2013, klienten selv kan spore sine røtter helt tilbake til den aller første utgivelsen av Satoshi Nakomoto i 2009. Andre Bitcoin-implementeringer som libbitcoin (C ++), bcoin (Javascript) og btcd (Go) ble opprettet senere.

Bli kjent med GitHub

Bitcoin Core er et open source-prosjekt. Koden og dokumentasjonen kan vises og lastes ned av alle med internettforbindelse. Bitcoin Core (og mange andre programvareprosjekter) bruker åpen kildekode og ikke-proprietær Git versjonskontrollsystem for å spore endringer i kodebasen på tvers av distribuerte bidragsytere..

Git ble utviklet av skaperen av Linux-kjernen, Linus Torvalds. I motsetning til dette tilbyr GitHub (nylig ervervet av Microsoft) proprietær programvare som tilbyr praktiske verktøy og sosiale funksjoner rundt Git-protokollen. Bitcoin Core er ikke avhengig av GitHub for sin pågående overlevelse, selv om det ville være upraktisk og forstyrrende hvis prosjektet plutselig ble flyttet eller forhindret fra å bruke GitHub-programvare i fremtiden.

I løpet av Microsofts oppkjøp av GitHub var det diskusjon i Bitcoin-fellesskapet og på andre open source-prosjekter om de skal gå over fra fremtidig avhengighet av GitHub. Dette synet blir stadig mer populært ettersom det blir større antall bidragsytere og potensielle bidragsytere utestengt fra å bruke GitHub-programvare. Det er også muligheten for at Microsoft kan gjøre det første trekket og forby hele prosjekter hvis de blir oppfattet som politisk kontroversielle. Tiden vil vise om Bitcoin Core og andre Bitcoin-implementeringer fortsetter å utnytte GitHubs riktignok godt utformede, brukervennlige funksjoner i årene som kommer.

Finn et godt første nummer

En av disse funksjonene er GitHub-problemer som brukes til å kunngjøre og spore feil, forbedringer og forespørsler. Enhver GitHub-bruker kan opprette et problem, men det anbefales at de bare åpner et problem etter å ha undersøkt det og diskutert det med eksisterende bidragsytere på IRC. Du trenger ikke be om tillatelse til å begynne å jobbe med et problem. Men hvis du gjør det, oppfordres du til å kommentere problemet for å oppmuntre til samarbeid med andre bidragsytere. Det er også en god måte å be om hjelp hvis og når du trenger det.

Formålet med “God første utgave” etiketten er å markere hvilke problemer som passer for en ny bidragsyter som kanskje ikke har en dyp forståelse av kodebasen. Et godt første nummer er ikke rettet mot nybegynnere av programvareutvikling. I det minste trenger du grunnleggende Git-ferdigheter og ideelt sett også C ++ og / eller Python-ferdigheter, gitt at Bitcoin Core-kodebasen er skrevet på disse språkene.

Gode ​​førsteutgaver for Bitcoin Core fremhever de “nyttige ferdighetene” for å løse problemet. Det er en god ide å lære C ++ og / eller Python for å gi kodelaterte bidrag, men hvis du ikke er dyktig i disse språkene, kan du velge å komme i gang ved å gjøre en vesentlig forbedring av dokumentasjonen eller finne en god første utgave som krever skallskripting, Automake eller CMake erfaring.

‘Skrivefeil’ mot ‘Ekte’ problemer

Noen mennesker kommer i gang med å korrigere grunnleggende skrivefeil i variabelnavn, kommentarer eller dokumentasjon. Jeremy Rubin har spøkte at han bevisst legger igjen skrivefeil i sine bidrag, slik at nye bidragsytere kan finne dem og rette dem. Selv om dette er en måte å komme i gang som en ny bidragsyter, er det bedre å fokusere på gode første problemer i stedet for å sende inn pull-forespørsler (PRs) for skrivefeil..

Gode ​​første utgaver har blitt fremhevet som noe som mangler og har betydelig verdi for prosjektet av eksisterende bidragsytere. De blir ikke satt opp for å identifisere skrivefeil, og eksisterende bidragsytere og vedlikeholdere foretrekker å fokusere tiden sin på å gjennomgå og slå sammen høy prioritet for gjennomgang trekk forespørsler. (Pull-forespørsler er foreslåtte endringer av bidragsytere som bare slås sammen av vedlikeholdere etter gjennomgang, og når det er tilstrekkelig enighet for å gjøre det.) 

Det ville derfor være bedre å korrigere skrivefeil som en del av en mer omfattende trekkforespørsel. Som diskutert tidligere, er det verdt å huske at gjennomgang av eksisterende PR generelt er mer verdifullt enn å sende inn nye. John Newbery anbefaler at en god tommelfingerregel er å gjennomgå 5–15 PR for hver PR du sender inn personlig. I skrivende stund er det omtrent 300 åpne trekkforespørsler og 700 åpne problemer som krever testing og gjennomgang.

Mange muligheter til å øve og lære

Fabian Jahr, en nylig ny bidragsyter til Bitcoin Core, har identifisert at den viktigste ferdigheten ofte mangler nye bidragsytere, er tilstrekkelig Git-ferdighet, for eksempel evnen til å squash forplikter. Bidragsytere må oppgi Git-kommandoer i kommandolinjen. Hvis du er nybegynner for kommandolinjen og / eller Git, er det best å fullføre opplæringsprogrammer og øve på andre prosjekter som ikke er underlagt ressursbegrensningene til Bitcoin Core.

Det er mange Git tutorials online (noen av dem gratis) og Justin Moon’s Mooniversity kurs (betalt) vil også hjelpe deg med å lære forutsetningene for å samhandle med og bidra til Bitcoin Core fra kommandolinjen. Ikke vær redd for å be om hjelp fra nylige nye bidragsytere online eller på ditt lokale Socratic Seminar hvis du trenger ytterligere veiledning.

Be om hjelp

En av utfordringene med å ta ombord nye bidragsytere er at oppgaver som tar en erfaren bidragsyter en kort periode å fullføre, kan ta en ny bidragsyter mye lenger tid. Dette krever at nye bidragsytere fortsetter når de møter utfordringer og ber om hjelp når det er nødvendig. Nylige nye bidragsytere til Bitcoin Core kan være en god første anløpshavn, da de kanskje kan løse problemet ditt; hvis ikke, bør de kunne henvise deg til en passende langsiktig bidragsyter. Du kan også kommentere problemet du jobber med for å merke at du trenger hjelp.

I et intervju med Bitcoin Magazine Vlad Costea husket Chaincode Labs ingeniør Carl Dong å sette opp en IFTTT e-postvarsel som vil bli rapportert hver gang det var et nytt “godt første nummer” lagt ut av eksisterende bidragsytere. Dette var en av strategiene han brukte for å komme i gang med Bitcoin-utvikling og identifisere noen miniprosjekter som han hadde ferdighetene til å bidra til. Dong har siden opprettet Twitter-kontoen @GoodFirstIssues som alle kan følge for varsler om nye gode førsteutgaver.

Takk til Jon Atack og Marco Falke for deres bidrag til denne artikkelen.