Cum să gestionați un program InnerSource reușit

Finalizat

Aici, vom discuta cum puteți proiecta un program InnerSource pentru a vă bucura de cele mai bune modele open-source în cadrul oricărei organizații de dezvoltare software.

Ce este InnerSource?

Oricine poate utiliza, modifica și partaja gratuit software open-source. Utilizând software open-source, oricine poate vizualiza, modifica și distribui un proiect în orice scop, cu ideea că partajarea codului duce la software mai bun și mai fiabil.

InnerSource este practica de a aplica modele open-source proiectelor cu un public limitat. De exemplu, o firmă poate stabili un program InnerSource care reflectă structura unui proiect open-source tipic, cu excepția faptului că este accesibil doar angajaților acelei firme. De fapt, este un program open-source din spatele firewallului firmei dvs.

Beneficii InnerSource

Un program InnerSource poate oferi numeroase beneficii dincolo de ceea ce oferă modelele tradiționale cu sursă închisă.

În primul rând, susțin vizibilitatea internă. Accesul la codul sursă al altor proiecte de firmă poate ajuta dezvoltatorii să fie mai productivi atunci când lucrează la propriile proiecte. Aceștia pot vedea cum diferite echipe rezolvă probleme asemănătoare cu cele cu care se confruntă și găsesc adesea cod și alte active pe care le pot reutiliza. Accesul la problemele echipei, solicitările de extragere și planurile de proiect oferă, de asemenea, date mai bune pentru acestea, pentru a înțelege viteza și direcția proiectului.

Apoi, acestea reduce frecarea. Să presupunem că o echipă de consumatori depinde de o remediere a erorilor sau de o caracteristică nouă pentru un proiect deținut de o altă echipă. Într-un program InnerSource, au un canal prin care pot propune modificările de care au nevoie. Iar dacă aceste modificări nu pot fi îmbinate dintr-un motiv oarecare, echipa de consumatori are opțiunea de a solicita proiectului să-și îndeplinească cerințele.

În cele din urmă, acestea standardiza practicile. O organizație de dezvoltare cu provocări comune se confruntă cu faptul că echipele diferite diverge adesea în modurile în care operează. Construirea unui program InnerSource este o oportunitate foarte bună de a adopta convenții standard care pot fi utilizate în fiecare echipă de dezvoltare, chiar dacă nu respectă practici identice. De exemplu, două echipe pot prefera procese diferite pentru acceptarea contribuțiilor. Dacă le standardizați în modul în care comunică procesele lor diferite, este mult mai ușor ca oricine să contribuie la oricare dintre ele.

Sfat

Luați în considerare utilizarea GitHub Discussions și GitHub Projects pentru a sprijini în continuare colaborarea InnerSource între echipe.

Aceste exemple sunt doar câteva dintre avantajele oferite de programele InnerSource. Pentru a afla mai multe, consultați Introducere în InnerSource.

Configurarea unui program InnerSource pe GitHub

Setarea vizibilității și permisiunilor pentru depozit

Puteți configura depozitele GitHub cu trei niveluri de vizibilitate. Utilizatorii care nu îndeplinesc cerința de vizibilitate văd pagini "negăsite" atunci când încearcă să acceseze depozitul. Nivelurile sunt:

• depozitele de publice sunt vizibile pentru toată lumea. Utilizați această vizibilitate pentru proiecte care sunt cu adevărat open source și oferă acces persoanelor din interiorul și din afara organizației.
• Depozitele interne sunt vizibile numai pentru membrii întreprinderii care le deține.

Notă

Depozitele interne sunt disponibile numai pentru clienții GitHub Enterprise. Utilizați această vizibilitate pentru proiectele InnerSource.

• depozitele de private sunt vizibile numai pentru proprietar și pentru orice echipe sau persoane pe care le adaugă. Utilizați această vizibilitate pentru proiecte la care ar trebui să aibă acces doar anumiți utilizatori și grupuri.

După ce stabiliți vizibilitatea depozitului, puteți configura permisiunile pe baza unei persoane sau a unei echipe. Există cinci niveluri de permisiune:

• Se recomandă citirea nivel pentru colaboratorii care doresc să vizualizeze sau să discute proiectul.
• nivel de triere este recomandat pentru colaboratorii care trebuie să gestioneze proactiv problemele și solicitările de tragere fără acces la scriere.
• se recomandă scrierea nivel pentru colaboratorii care împinge în mod activ proiectul.
• Mențineți nivel este recomandat managerilor de proiect care trebuie să gestioneze depozitul fără acces la acțiuni sensibile sau distructive.
• Nivel de administrare este recomandat persoanelor care au nevoie de acces complet la proiect, inclusiv acțiuni sensibile și distructive, cum ar fi gestionarea securității sau ștergerea unui depozit.

Aflați mai multe despre permisiunile de acces ale depozitului după nivel.

Crearea depozitelor detectabile

Pe măsură ce un program InnerSource crește, numărul de depozite se scalează probabil în mod semnificativ. Deși este excelent să aveți toate aceste active disponibile organizației, poate deveni o provocare să găsiți eficient conținut. Pentru a rezolva proactiv această problemă, este o practică recomandată ca echipele să ia în considerare ce pot face pentru a ajuta alte persoane să găsească și să lucreze cu depozitele lor.

Printre exemplele de bună practică se numără:

• Utilizați un nume descriptiv pentru depozit, cum ar fi warehouse-api sau supply-chain-web.
• Includeți o descriere concisă. O propoziție sau două ar trebui să fie suficientă pentru ca utilizatorii potențiali să știe dacă proiectul se potrivește nevoilor lor.
• Licențiați depozitul, astfel încât clienții să știe cum pot utiliza, modifica și distribui software-ul.
• Includeți un fișier README.md în depozit. GitHub utilizează acest fișier ca pagină de destinație atunci când utilizatorii vizitează depozitul.

Adăugarea unui fișier README

Un fișier README comunică așteptările pentru proiectul dvs. și vă ajută să gestionați contribuțiile. Fișierele README pot:

• Exprimați scopul și viziunea proiectului, astfel încât consumatorii potențiali să înțeleagă dacă se potrivește nevoilor lor.
• Oferiți ajutoare vizuale, cum ar fi capturi de ecran sau eșantioane de cod, pentru a ilustra proiectul în acțiune.
• Includeți linkuri către o versiune de producție sau demonstrație a aplicației pentru revizuire.
• Stabiliți așteptările pentru cerințele preliminare și procedurile de implementare.
• Includeți referințe la proiectele în care depindeți. Aceste referințe sunt o modalitate bună de a promova munca altora.
• Utilizați Markdown pentru a ghida cititorii prin conținutul formatat corect.

Dacă puneți fișierul README.md în directorul rădăcină al depozitului sau în directorul ascuns sau în docs directorul ascuns.github, GitHub recunoaște și afișează automat README vizitatorilor depozitului. Dacă un depozit conține mai multe fișiere README, atunci fișierul afișat este ales din locații în următoarea ordine:

1. Directorul .github
2. Directorul rădăcină al depozitului
3. Directorul docs

Încercați câteva exemple Awesome README.

După lansarea proiectului, utilizați e-mailul și alte canale de rețea pentru a-l promova. Atingerea unei audiențe corespunzătoare ar putea genera un impuls semnificativ în participarea la proiect.

Aflați mai multe despre fișierele README în documentația GitHub.

Gestionarea proiectelor pe GitHub

Pe măsură ce proiectele câștigă tracțiune, fluxul de utilizatori și contribuțiile pot necesita o mulțime de lucru de gestionat. În funcție de proiect, poate fi necesară o cantitate semnificativă de lucru doar pentru a gestiona așteptările participanților la proiect.

Pentru a rezolva proactiv această problemă, GitHub caută un fișier CONTRIBUTING.md în rădăcina (sau /docs sau /.github) a unui depozit. Utilizați acest fișier pentru a explica politica de contribuție pentru proiect. Detaliile exacte pot varia, dar este o idee bună să anunțați colaboratorii potențiali ce convenții urmează proiectul. De exemplu, în cazul în care echipa caută solicitări de tragere, ce detalii sunt solicitate pentru rapoartele erorilor și așa mai departe.

Dacă există un CONTRIBUTING.md, GitHub prezintă un link către acesta atunci când utilizatorii creează probleme sau solicită să îi încurajeze să o urmărească.

Vedeți câteva exemple Minunat CONTRIBUTING.md

În plus, luați în considerare adăugarea unui fișier CODEOWNERS în depozit, pentru a defini persoane sau echipe responsabile pentru revizuirea modificărilor de cod.

Crearea problemei și extragerea șabloanelor de solicitări

GitHub acceptă șabloane starter pentru probleme noi și solicitări de extragere. Utilizați aceste șabloane pentru a furniza textul descrierii inițiale pentru o problemă nou creată sau o solicitare de extragere.

De exemplu, dacă proiectul dvs. are .github/ISSUE_TEMPLATE.md, oricând un utilizator începe procesul de creare a unei probleme, acesta va vedea acest conținut. În loc să facă referire constant la detaliile necesare dintr-o CONTRIBUTING.md, acestea pot să completeze problema, cum ar fi un formular, utilizând textul șablonului.

Este același lucru pentru solicitările de tragere, cu excepția faptului că calea este .github/PULL_REQUEST_TEMPLATE.md.

Vedeți câteva problemă minunată cu GitHub & șabloane de solicitare.

Definirea fluxurilor de lucru

Pentru proiectele care încurajează contribuțiile externe, asigurați-vă că specificați ce flux de lucru urmează proiectul. Fluxul de lucru ar trebui să includă detalii despre locul și modul în care ar trebui utilizate ramurile pentru erori și caracteristici. De asemenea, ar trebui să includă modul în care ar trebui să fie deschise solicitările de tragere, iar orice alte detalii ale persoanelor din afara echipei depozitului ar trebui să știe înainte de a împinge codul. Dacă nu aveți încă un flux de lucru în minte, ar trebui să luați în considerare fluxul GitHub.

Ar trebui să comunicați o strategie pentru gestionarea lansărilor și implementărilor. Aceste părți ale fluxului de lucru afectează ramificarea și îmbinarea zilnică, deci este important să le comunicați colaboratorilor. Aflați mai multe despre modul în care acestea se referă la strategia dvs. de ramificare Git .

Succesul programului de măsurare

Orice echipă care venturează în InnerSource ar trebui să se gândească la tipurile de măsurători pe care doresc să le urmărească pentru a evalua succesul programului lor. Deși măsurătorile tradiționale, cum ar fi "timpul până la piață" și "erorile raportate" sunt încă aplicabile, acestea nu vor ilustra neapărat beneficiile obținute prin InnerSource.

În schimb, luați în considerare adăugarea măsurătorilor care arată modul în care participarea externă a îmbunătățit calitatea proiectului. Depozitul primește solicitări de extragere de la surse externe care remediază erorile și adaugă caracteristici? Există participanți activi în discuțiile din jurul proiectului și al viitorului său? Programul inspira o extensie InnerSource care aduce beneficii în altă parte din organizație?

Pe scurt, măsurătorile sunt greu, mai ales atunci când vine vorba de măsurarea valorii și efectului contribuțiilor individuale și ale echipei. Dacă sunt utilizate greșit, măsurătorile pot dăuna culturii, proceselor existente și diminuării sentimentului colectiv față de organizație sau de echipa de conducere. Atunci când vă gândiți la măsurarea adoptării InnerSource, luați în considerare următoarele instrucțiuni privind măsurătorile:

• Măsurați procesul, nu ieșirea
  • Ora de dezactivare a revizuirii codului
  • Dimensiune solicitare de tragere
  • Lucru în desfășurare
  • Ora deschiderii
• Măsura împotriva țintelor și nu a absolutului
• Măsurați echipele și nu persoanele
  • Numărul de colaboratori unici la un proiect
  • Numărul de proiecte care reutilizează codul
  • Numărul de @mentions între echipe

Aflați despre succesele pe care alții le-au bucurat în aceste studii de caz InnerSource.