Sådan administrerer du et vellykket InnerSource-program

  • 8 minutter

Her diskuterer vi, hvordan du kan designe et InnerSource-program for at få det bedste ud af open source-mønstre i enhver softwareudviklingsorganisation.

Hvad er InnerSource?

Alle kan frit bruge, ændre og dele open source-software. Ved hjælp af open source-software kan alle få vist, ændre og distribuere et projekt til ethvert formål med den idé, at delingskode fører til bedre og mere pålidelig software.

InnerSource- er praksis med at anvende open source-mønstre på projekter med en begrænset målgruppe. En virksomhed kan f.eks. oprette et InnerSource-program, der afspejler strukturen i et typisk projekt med åben kildekode, bortset fra at det kun er tilgængeligt for medarbejderne i virksomheden. Det er i realiteten et program med åben kildekode bag din virksomheds firewall.

InnerSource-fordele

Et InnerSource-program kan give mange fordele ud over, hvad traditionelle modeller med lukket kildekode giver.

For det første understøtter de intern synlighed. Adgang til kildekoden for andre virksomhedsprojekter kan hjælpe udviklere med at være mere produktive, når de arbejder på deres egne projekter. De kan se, hvordan forskellige teams løser problemer, der ligner dem, de står overfor, og de kan ofte finde kode og andre aktiver, som de kan genbruge. Adgang til teamproblemer, pullanmodninger og projektplaner giver også bedre data, så de kan forstå projektets hastighed og retning.

Derefter de reducere friktion. Lad os sige, at et forbrugerteam er afhængig af en fejlrettelse eller en ny funktion for et projekt, der ejes af et andet team. I et InnerSource-program har de en kanal, hvorigennem de kan foreslå de ændringer, de har brug for. Og hvis disse ændringer ikke kan flettes med af en eller anden grund, har forbrugerteamet mulighed for at fortrikke projektet, så det opfylder deres behov.

Endelig de standardisere fremgangsmåder. En almindelig udfordring for udviklingsorganisationer er, at forskellige teams ofte divergerer i den måde, de arbejder på. Oprettelse af et InnerSource-program er en god mulighed for at vedtage standardkonventioner, der kan bruges på tværs af alle udviklingsteams, selvom de ikke følger identiske fremgangsmåder. To teams foretrækker f.eks. forskellige processer til accept af bidrag. At få dem til at standardisere på den måde, de kommunikerer deres forskellige processer på, gør det meget nemmere for alle at bidrage til begge.

Tips

Overvej at bruge GitHub-diskussioner og GitHub-projekter til yderligere at understøtte InnerSource-samarbejde på tværs af teams.

Disse eksempler er blot nogle få af fordelene ved InnerSource-programmer. Du kan få mere at vide under En introduktion til InnerSource-.

Konfigurer et InnerSource-program på GitHub

Angiv lagerets synlighed og tilladelser

Du kan konfigurere GitHub-lagre med tre synlighedsniveauer. Brugere, der ikke opfylder synlighedskravet, kan se sider med "ikke fundet", når de forsøger at få adgang til dit lager. Niveauerne er:

  • Offentlige lagre er synlige for alle. Brug denne synlighed til projekter, der virkelig er åben kildekode og giver adgang til personer i og uden for din organisation.
  • Interne lagre er kun synlige for medlemmer af den virksomhed, der ejer dem.

Notat

Interne lagre er kun tilgængelige for GitHub Enterprise-kunder. Brug denne synlighed til InnerSource-projekter.

  • Private lagre er kun synlige for ejeren og de teams eller enkeltpersoner, de tilføjer. Brug denne synlighed til projekter, som kun bestemte brugere og grupper skal have adgang til.

Når du har etableret synligheden af lageret, kan du konfigurere tilladelser på individuel basis eller teambasis. Der er fem tilladelsesniveauer:

  • Niveauet Læs anbefales for ikke-kodede bidragydere, der vil have vist eller diskutere projektet.
  • Triage niveau anbefales til bidragydere, der har brug for proaktivt at administrere problemer og pullanmodninger uden skriveadgang.
  • Niveauet Skriv anbefales til bidragydere, der aktivt pusher til projektet.
  • Bevar niveau anbefales til projektledere, der har brug for at administrere lageret uden adgang til følsomme eller destruktive handlinger.
  • Administrator niveau anbefales til personer, der har brug for fuld adgang til projektet, herunder følsomme og destruktive handlinger, f.eks. administration af sikkerhed eller sletning af et lager.

Få mere at vide om adgangstilladelser til lager efter niveau.

Opret fundne lagre

I takt med at et InnerSource-program vokser, skaleres antallet af lagre sandsynligvis betydeligt. Selvom det er fantastisk at have alle disse aktiver tilgængelige for organisationen, kan det blive en udfordring at finde indhold effektivt. Hvis du proaktivt vil løse dette problem, er det bedste praksis for teams at overveje, hvad de kan gøre for at gøre det nemmere for andre at finde og arbejde med deres lagre.

Nogle få bedste fremgangsmåder omfatter:

  • Brug et beskrivende lagernavn, f.eks. warehouse-api eller supply-chain-web.
  • Medtag en præcis beskrivelse. En sætning eller to skal være nok til, at potentielle brugere kan vide, om projektet kan passe til deres behov.
  • Licenser dit lager, så kunderne ved, hvordan de kan bruge, ændre og distribuere softwaren.
  • Medtag en README.md fil i lageret. GitHub bruger denne fil som landingsside, når folk besøger lageret.

Tilføj en README-fil

En README-fil kommunikerer forventninger til dit projekt og hjælper dig med at administrere bidrag. VIGTIGT-filer kan:

  • Udform projektets formål og vision, så potentielle forbrugere forstår, om det passer til deres behov.
  • Tilbyd visuelle hjælpemidler, f.eks. skærmbilleder eller kodeeksempler, for at illustrere projektet i aktion.
  • Medtag links til en produktions- eller demoversion af appen til gennemsyn.
  • Angiv forventninger til forudsætninger og installationsprocedurer.
  • Medtag referencer til de projekter, du er afhængig af. Disse referencer er en god måde at fremme andres arbejde på.
  • Brug Markdown til at guide læserne gennem korrekt formateret indhold.

Hvis du placerer din README.md fil i dit lagers rodmappe eller i den skjulte .github mappe eller docs mappe, genkender GitHub og viser automatisk din README til lagerbesøgende. Hvis et lager indeholder mere end én README-fil, vælges den viste fil fra placeringer i følgende rækkefølge:

  1. Vejviseren .github
  2. Lagerets rodmappe
  3. Vejviseren docs

Se nogle Fantastiske README-eksempler.

Når projektet er startet, skal du bruge mail og andre netværkskanaler til at promovere det. Når man når ud til en passende målgruppe, kan det give et betydeligt løft i projektdeltagelsen.

Få mere at vide om README-filer i GitHub-dokumentationen.

Administrer projekter på GitHub

I takt med at projekter får trækkraft, kan tilstrømningen af brugere og bidrag kræve masser af arbejde at administrere. Afhængigt af projektet kan der være behov for en betydelig arbejdsmængde blot for at administrere projektdeltagernes forventninger.

GitHub søger proaktivt efter en CONTRIBUTING.md fil i roden (eller /docs eller /.github) i et lager. Brug denne fil til at forklare projektets bidragspolitik. De nøjagtige detaljer kan variere, men det er en god idé at fortælle potentielle bidragydere, hvilke konventioner projektet følger. Hvor teamet f.eks. leder efter pullanmodninger, hvilke oplysninger der anmodes om for fejlrapporter osv.

Hvis der findes en CONTRIBUTING.md, præsenterer GitHub et link til den, når brugerne opretter problemer eller trækker anmodninger for at tilskynde dem til at følge den.

Links til retningslinjer for bidrag.

Se nogle Fantastiske CONTRIBUTING.md eksempler

Overvej desuden at føje en kodeejerfil til lageret for at definere personer eller teams, der er ansvarlige for at gennemse kodeændringer.

Opret skabeloner til problem- og pullanmodninger

GitHub understøtter startskabeloner til nye problemer og pullanmodninger. Brug disse skabeloner til at angive den indledende beskrivelsestekst for et nyligt oprettet problem eller en pullanmodning.

Hvis dit projekt f.eks. har .github/ISSUE_TEMPLATE.md, får brugeren vist dette indhold, når en bruger starter processen med at oprette et problem. I stedet for hele tiden at skulle referere til de nødvendige oplysninger fra en CONTRIBUTING.md, kan de bare udfylde problemet, f.eks. en formular, ved hjælp af skabelonteksten.

Et nyt problem med skabelonen.

Det er det samme for pullanmodninger, bortset fra at stien er .github/PULL_REQUEST_TEMPLATE.md.

Se nogle Awesome GitHub-problem & pullanmodningsskabeloner.

Definer arbejdsprocesser

For projekter, der opfordrer til eksterne bidrag, skal du angive, hvilken arbejdsproces projektet skal følge. Arbejdsprocessen skal indeholde oplysninger om, hvor og hvordan forgreninger skal bruges til fejl og funktioner. Det bør også omfatte, hvordan pullanmodninger skal åbnes, og alle andre oplysninger, som personer uden for lagerteamet skal vide, før de pushkode. Hvis du endnu ikke har en arbejdsproces i tankerne, bør du overveje at GitHub-flowet.

Du skal kommunikere en strategi for administration af udgivelser og udrulninger. Disse dele af arbejdsprocessen påvirker den daglige forgrening og fletning, så det er vigtigt at kommunikere dem til bidragydere. Få mere at vide om, hvordan de er relateret til din Git-forgreningsstrategi.

Succes med måleprogram

Ethvert team, der går ind i InnerSource, bør tænke på de typer målepunkter, de vil spore for at måle succesen af deres program. Mens traditionelle målepunkter som "tid til marked" og "rapporterede fejl" stadig gælder, vil de ikke nødvendigvis illustrere de fordele, der opnås via InnerSource.

Overvej i stedet at tilføje målepunkter, der viser, hvordan ekstern deltagelse forbedrede projektkvaliteten. Modtager lageret pullanmodninger fra eksterne kilder, der retter fejl og tilføjer funktioner? Er der aktive deltagere i diskussioner om projektet og dets fremtid? Er programmet inspirerende for en InnerSource-udvidelse, der skaber fordele andre steder i organisationen?

Kort sagt er målepunkterne svære, især når det kommer til at måle værdien og effekten af individuelle bidrag og teambidrag. Hvis metrikværdier misbruges, kan de skade kulturen, eksisterende processer og mindske den kollektive tillid til organisationen eller ledelsesteamet. Når du overvejer at måle indføringen af InnerSource, skal du overveje følgende vejledning i målepunkter:

  • Målingsproces, ikke output
    • Tid til ændring af kodegennemgang
    • Størrelse på pullanmodning
    • Igangværende arbejde
    • Tid til at åbne
  • Mål i forhold til mål og ikke absolutte tal
  • Mål teams og ikke enkeltpersoner
    • Antal entydige bidragydere til et projekt
    • Antal projekter, der genbruger kode
    • Antal @mentions på tværs af teams

Få mere at vide om de succeser, andre har haft i disse InnerSource-casestudier.