Slik administrerer du et vellykket InnerSource-program

  • 8 minutter

Her diskuterer vi hvordan du kan utforme et InnerSource-program for å få det beste ut av åpen kildekode-mønstre i alle programvareutviklingsorganisasjoner.

Hva er InnerSource?

Alle kan fritt bruke, endre og dele åpen kildekode-programvare. Ved hjelp av åpen kildekode-programvare kan hvem som helst vise, endre og distribuere et prosjekt til ethvert formål med ideen om at deling av kode fører til bedre og mer pålitelig programvare.

InnerSource er praksisen med å bruke åpen kildekode-mønstre på prosjekter med begrenset målgruppe. Et firma kan for eksempel etablere et InnerSource-program som gjenspeiler strukturen til et typisk åpen kildekode-prosjekt, bortsett fra at det bare er tilgjengelig for de ansatte i firmaet. I praksis er det et åpen kildekode-program bak firmaets brannmur.

InnerSource-fordeler

Et InnerSource-program kan tilby mange fordeler utover det tradisjonelle lukkede kildemodeller gir.

For det første støtter de intern synlighet. Tilgang til kildekoden for andre firmaprosjekter kan hjelpe utviklere med å bli mer produktive når de arbeider med sine egne prosjekter. De kan se hvordan forskjellige team løser problemer som ligner på de de står overfor, og finner ofte kode og andre ressurser som de kan bruke på nytt. Tilgang til teamproblemer, pull-forespørsler og prosjektplaner gir også bedre data for dem for å forstå hastigheten og retningen til prosjektet.

Deretter de redusere friksjonen. La oss si at et forbrukerteam er avhengig av en feilretting eller ny funksjon for et prosjekt som eies av et annet team. I et InnerSource-program har de en kanal der de kan foreslå endringene de trenger. Og hvis disse endringene ikke kan slås sammen av en eller annen grunn, har forbrukerteamet muligheten til å bruke prosjektet til å dekke behovene deres.

Til slutt de standardisere praksis. En vanlig utfordring utviklingsorganisasjoner står overfor er at ulike team ofte avviker på måtene de opererer på. Å bygge et InnerSource-program er en flott mulighet til å vedta standardkonvensjoner som kan brukes på tvers av alle utviklingsteam, selv om de ikke følger identiske praksiser. To team foretrekker for eksempel kanskje forskjellige prosesser for å godta bidrag. Å la dem standardisere på måten de kommuniserer sine ulike prosesser på, gjør det mye enklere for alle å bidra til begge.

Tips

Vurder å bruke GitHub-diskusjoner og GitHub-prosjekter for ytterligere å støtte InnerSource-samarbeid på tvers av team.

Disse eksemplene er bare noen få av fordelene som nytes av InnerSource-programmer. Hvis du vil ha mer informasjon, kan du se En innføring i InnerSource.

Konfigurere et InnerSource-program på GitHub

Angi synlighet og tillatelser for repositorium

Du kan konfigurere GitHub-repositorier med tre synlighetsnivåer. Brukere som ikke oppfyller synlighetskravet, ser «ikke funnet»-sider når de prøver å få tilgang til repositoriet. Nivåene er:

  • offentlige repositorier er synlige for alle. Bruk denne synligheten for prosjekter som virkelig er åpen kildekode, og gi tilgang til personer i og utenfor organisasjonen.
  • Interne depoter er bare synlige for medlemmer av bedriften som eier dem.

Merk deg

Interne repositorier er bare tilgjengelige for GitHub Enterprise-kunder. Bruk denne synligheten for InnerSource-prosjekter.

  • private repositorier er bare synlige for eieren og eventuelle team eller enkeltpersoner de legger til. Bruk denne synligheten for prosjekter som bare bestemte brukere og grupper skal ha tilgang til.

Når du har etablert synlighet for repositorium, kan du konfigurere tillatelser på individuell basis eller teambasis. Det finnes fem tillatelsesnivåer:

  • Les-nivået anbefales for bidragsytere som ikke er kodet, som ønsker å vise eller diskutere prosjektet.
  • Triage-nivå anbefales for bidragsytere som trenger proaktivt å håndtere problemer og hente forespørsler uten skrivetilgang.
  • Skrive nivå anbefales for bidragsytere som aktivt sender til prosjektet.
  • Vedlikehold nivå anbefales for prosjektledere som trenger å administrere repositoriet uten tilgang til sensitive eller destruktive handlinger.
  • administrator nivå anbefales for personer som trenger full tilgang til prosjektet, inkludert sensitive og destruktive handlinger som å administrere sikkerhet eller slette et repositorium.

Lær mer om tilgangstillatelser for repositorium etter nivå.

Opprett oppdagbare repositorier

Etter hvert som et InnerSource-program vokser, skaleres antall repositorier sannsynligvis betydelig opp. Selv om det er flott å ha alle disse ressursene tilgjengelige for organisasjonen, kan det bli en utfordring å effektivt finne innhold. For proaktivt å løse dette problemet, er det en anbefalt fremgangsmåte for team å vurdere hva de kan gjøre for å gjøre det enklere for andre å finne og arbeide med repositoriene sine.

Noen anbefalte fremgangsmåter inkluderer:

  • Bruk et beskrivende repositoriumnavn, for eksempel warehouse-api eller supply-chain-web.
  • Inkluder en kortfattet beskrivelse. En setning eller to bør være nok til at potensielle brukere kan vite om prosjektet passer deres behov.
  • Lisensier repositoriet slik at kundene vet hvordan de kan bruke, endre og distribuere programvaren.
  • Inkluder en README.md fil i repositoriet. GitHub bruker denne filen som målside når personer besøker repositoriet.

Legge til en VIKTIG-fil

En README-fil kommuniserer forventningene til prosjektet og hjelper deg med å administrere bidrag. README-filer kan:

  • Artikuler formålet og visjonen til prosjektet slik at potensielle forbrukere forstår om det passer deres behov.
  • Tilby visuelle hjelpemidler, for eksempel skjermbilder eller kodeeksempler, for å illustrere prosjektet i praksis.
  • Inkluder koblinger til en produksjons- eller demoversjon av appen for gjennomgang.
  • Angi forventninger for forutsetninger og distribusjonsprosedyrer.
  • Inkluder referanser til prosjektene du er avhengig av. Disse referansene er en god måte å fremme andres arbeid på.
  • Bruk Markdown til å veilede leserne gjennom riktig formatert innhold.

Hvis du legger README.md-filen i depotets rotkatalog, eller i den skjulte .github katalogen eller docs , gjenkjenner GitHub og viser automatisk README til besøkende på depotet. Hvis et repositorium inneholder mer enn én README-fil, velges filen som vises, fra plasseringer i følgende rekkefølge:

  1. Katalogen .github
  2. Repositoriets rotkatalog
  3. Katalogen docs

Sjekk ut noen Fantastiske README-eksempler.

Når prosjektet startes, kan du bruke e-post og andre nettverkskanaler til å promotere det. Å nå et passende publikum kan gi et betydelig løft i prosjektdeltakelse.

Finn ut mer om README-filer i GitHub-dokumentasjonen.

Behandle prosjekter på GitHub

Etter hvert som prosjekter får trekkraft, kan tilstrømningen av brukere og bidrag kreve mye arbeid for å administrere. Avhengig av prosjektet kan det være nødvendig med en betydelig mengde arbeid bare for å håndtere forventningene til prosjektdeltakerne.

GitHub ser etter en CONTRIBUTING.md fil i roten (eller /docs eller /.github) i et repositorium for å proaktivt løse dette problemet. Bruk denne filen til å forklare bidragspolicyen for prosjektet. De nøyaktige detaljene kan variere, men det er lurt å la potensielle bidragsytere få vite hvilke konvensjoner prosjektet følger. Der teamet for eksempel leter etter pull-forespørsler, hvilke detaljer som er forespurt for feilrapporter og så videre.

Hvis det finnes en CONTRIBUTING.md, presenterer GitHub en kobling til den når brukere oppretter problemer eller henter forespørsler for å oppmuntre dem til å følge den.

koblinger til bidragsretningslinjer.

Sjekk ut noen Awesome CONTRIBUTING.md eksempler

Vurder i tillegg å legge til en CODEOWNERS-fil i repositoriet for å definere enkeltpersoner eller team som er ansvarlige for å se gjennom kodeendringer.

Opprette maler for problem og pull-forespørsel

GitHub støtter startmaler for nye problemer og pull-forespørsler. Bruk disse malene til å angi den første beskrivelsesteksten for et nylig opprettet problem eller en pull-forespørsel.

Hvis prosjektet for eksempel har .github/ISSUE_TEMPLATE.md, når en bruker starter prosessen med å opprette et problem, ser de dette innholdet. I stedet for å hele tiden referere til de nødvendige detaljene fra en CONTRIBUTING.md, kan de bare fylle ut problemet som et skjema ved hjelp av malteksten.

Et nytt problem ved hjelp av malen.

Det er det samme for pull-forespørsler, bortsett fra at banen er .github/PULL_REQUEST_TEMPLATE.md.

Sjekk ut noen Awesome GitHub-problem & pull-forespørselsmaler.

Definer arbeidsflyter

For prosjekter som oppmuntrer til eksterne bidrag, må du angi hvilken arbeidsflyt prosjektet følger. Arbeidsflyten bør inneholde detaljer om hvor og hvordan grener skal brukes for feil og funksjoner. Det bør også omfatte hvordan pull-forespørsler skal åpnes, og andre detaljer personer utenfor repositoriumteamet bør vite før de sender kode. Hvis du ennå ikke har en arbeidsflyt i tankene, bør du vurdere GitHub-flyten.

Du bør formidle en strategi for å administrere utgivelser og distribusjoner. Disse delene av arbeidsflyten påvirker den daglige forgreningen og flettingen, så det er viktig å kommunisere dem til bidragsytere. Lær mer om hvordan de forholder seg til Git-forgreningsstrategien.

Måling av programsuksess

Ethvert team som drar inn i InnerSource bør tenke på hva slags måledata de ønsker å spore for å måle suksessen til programmet. Mens tradisjonelle måledata som "tid til marked" og "bugs rapportert" fortsatt gjelder, kommer de ikke nødvendigvis til å illustrere fordelene som oppnås gjennom InnerSource.

Vurder i stedet å legge til måledata som viser hvordan ekstern deltakelse forbedret prosjektkvaliteten. Mottar repositoriet pull-forespørsler fra eksterne kilder som løser feil og legger til funksjoner? Er det aktive deltakere i diskusjoner rundt prosjektet og dens fremtid? Inspirerer programmet en InnerSource-utvidelse som driver fordeler andre steder i organisasjonen?

Kort sagt, måledata er vanskelige, spesielt når det gjelder måling av verdien og effekten av individuelle og teambidrag. Hvis de misbrukes, kan måledata skade kulturen, eksisterende prosesser og redusere den kollektive stemningen mot organisasjonen eller ledergruppen. Når du tenker på måling av InnerSource-innføring, bør du vurdere følgende veiledning om måledata:

  • Målprosess, ikke utdata
    • Behandlingstid for kodegjennomgang
    • Pull-forespørselsstørrelse
    • Arbeid pågår
    • På tide å åpne
  • Mål mot mål og ikke absolutter
  • Måle team og ikke enkeltpersoner
    • Antall unike bidragsytere til et prosjekt
    • Antall prosjekter som bruker kode på nytt
    • Antall @mentions på tvers av team

Lær om suksessene andre likte i disse innersource case-studiene.