Sikeres InnerSource-programok kezelése

Befejezett

Itt bemutatjuk, hogyan tervezhet Egy InnerSource-programot, hogy a nyílt forráskódú minták közül a legjobbat élvezhesse bármely szoftverfejlesztő szervezeten belül.

Mi az az InnerSource?

Bárki szabadon használhatja, módosíthatja és megoszthatja a nyílt forráskódú szoftvereket. Nyílt forráskódú szoftverek használatával bárki megtekintheti, módosíthatja és terjesztheti a projekteket bármilyen célra azzal a gondolattal, hogy a kód megosztása jobb, megbízhatóbb szoftverekhez vezet.

Az InnerSource a nyílt forráskódú minták korlátozott célközönséggel rendelkező projektekre való alkalmazásának gyakorlata. Előfordulhat például, hogy egy vállalat létrehoz egy InnerSource-programot, amely egy tipikus nyílt forráskódú projekt struktúráját tükrözi, azzal a kivételével, hogy csak az adott vállalat alkalmazottai számára érhető el. Valójában ez egy nyílt forráskódú program a cég tűzfala mögött.

Az InnerSource előnyei

Az InnerSource-programok számos előnnyel járnak a hagyományos, zárt forráskódú modelleken túl.

Először is támogatják a belső láthatóságot. A többi céges projekt forráskódjának elérése segíthet a fejlesztőknek abban, hogy hatékonyabban dolgozzanak a saját projektjeiken. Láthatják, hogy a különböző csapatok hogyan oldják meg a tapasztaltakhoz hasonló problémákat, és gyakran találnak olyan kódot és egyéb eszközöket, amelyeket újra felhasználhatnak. A csapat problémáinak, lekéréses kérelmeinek és projektterveinek elérése emellett jobb adatokat biztosít számukra a projekt sebességének és irányának megismeréséhez.

Emellett csökkentik a súrlódásokat. Tegyük fel, hogy egy fogyasztói csapat egy másik csapat tulajdonában lévő projekt hibajavításától vagy új funkciójától függ. Az InnerSource-programokban van egy csatorna, amelyen keresztül javasolhatják a szükséges módosításokat. És ha ezek a módosítások semmilyen okból nem egyesíthetők, a fogyasztói csapat elágaztathatja a projektet az igényeiknek megfelelően.

Végül pedig szabványosítják a gyakorlatokat. Gyakori kihívás a fejlesztői szervezetek számára, hogy a különböző csapatok gyakran eltérő módokon működnek. Az InnerSource-program létrehozása nagyszerű lehetőség arra, hogy olyan szabványos konvenciókat fogadjon el, amelyeket minden fejlesztőcsapat használhat, még akkor is, ha nem követik az azonos eljárásokat. Előfordulhat például, hogy két csapat különböző folyamatokat szeretne a hozzájárulások elfogadásához. Ha arra kötelezik őket, hogy szabványosítsák a kommunikációjukat a különböző folyamataikkal kapcsolatban, az sokkal könnyebbé teszi, hogy bárki hozzájárulást küldjön bármelyiküknek.

Jótanács

Fontolja meg a GitHub-vitafórumok és a GitHub-projektek használatát az InnerSource csapatok közötti együttműködésének további támogatásához.

Ezek a példák csupán néhányat sorolnak fel az InnerSource-programok által nyújtott előnyök közül. További információért lásd: Az InnerSource bemutatása.

InnerSource-program beállítása a GitHubon

Adattár láthatóságának és engedélyeinek beállítása

A GitHub-adattárakat három láthatósági szinttel konfigurálhatja. Azok a felhasználók, akik nem felelnek meg a láthatósági követelményeknek, a "nem találhatók" oldalak jelennek meg, amikor megpróbálják elérni az adattárat. A szintek a következők:

• A Nyilvános adattárak mindenki számára láthatók. Ezt a láthatóságot olyan projektekhez használja, amelyek valóban nyílt forráskódúak, és a szervezeten belüli és kívüli személyeknek egyaránt hozzáférést biztosítanak.
• A belső adattárak csak a tulajdonos vállalat tagjai számára láthatók.

Megjegyzés:

A belső adattárak csak a GitHub Enterprise-ügyfelek számára érhetők el. Ezt a láthatóságot használja az InnerSource-projektekhez.

• A Privát adattárak csak a tulajdonos és az általuk hozzáadott csapatok vagy személyek számára láthatók. Használja ezt a láthatóságot olyan projektekhez, amelyekhez csak bizonyos felhasználóknak és csoportoknak kell hozzáféréssel rendelkezniük.

Az adattár láthatóságának létrehozása után egyéni vagy csapatonként konfigurálhatja az engedélyeket. Öt jogosultsági szint van:

• Olvasási szint azoknak a nem kódoló közreműködőknek ajánlott, akik meg szeretnék tekinteni vagy megvitatni a projektet.
• Az Osztályozási szint olyan közreműködők számára ajánlott, akiknek proaktívan kell kezelniük a problémákat és a lekéréses kérelmeket, írási hozzáférés nélkül.
• Az Írási szint olyan közreműködők számára ajánlott, akik aktívan leküldést végeznek a projektbe.
• A Karbantartási szint olyan projektmenedzserek számára ajánlott, akiknek anélkül kell kezelniük az adattárat, hogy bizalmas vagy romboló műveletekhez férnének hozzá.
• A Felügyeleti szint azok számára ajánlott, akiknek teljes hozzáférésre van szükségük a projekthez, beleértve a bizalmas és rombolóó műveleteket, például a biztonság kezelését vagy az adattár törlését.

További információ az adattár szintenkénti hozzáférési engedélyeiről.

Felderíthető adattárak létrehozása

Az InnerSource-programok növekedésével az adattárak száma valószínűleg jelentősen felskálázható. Habár nagyszerű, hogy mindezek az eszközök elérhetők a szervezet számára, a tartalom hatékony keresése kihívássá válhat. A probléma proaktív megoldása érdekében ajánlott, hogy a csapatok átgondolják, mit tehetnek annak érdekében, hogy mások könnyebben megtalálják és használják az adattáraikat.

Néhány ajánlott eljárás például a következő:

• Használjon leíró nevet az adattárhoz. Példa: warehouse-api vagy supply-chain-web.
• Adjon meg egy rövid leírást. Egy-két mondatnak elégnek kell lennie ahhoz, hogy a lehetséges felhasználók tudják, hogy a projekt megfelel-e az igényeinek.
• Licencelje az adattárat , hogy az ügyfelek tudják, hogyan használhatják, módosíthatják és terjeszthetik a szoftvert.
• Adjon meg egy README.md fájlt az adattárban. A GitHub ezt a fájlt használja kezdőlapként, amikor a felhasználók meglátogatják az adattárat.

README-fájl hozzáadása

A README-fájlok közlik a projekt elvárásait, és segítenek a közreműködések kezelésében. A README-fájlok:

• Fogalmazza meg a projekt célját és vízióját, hogy a potenciális fogyasztók tudják, hogy megfelel-e az igényeiknek.
• A projekt működés közbeni szemléltetéséhez biztosítson vizuális segédeszközöket, például képernyőképeket vagy kódmintákat.
• Tekintse meg az alkalmazás éles vagy demo verziójára mutató hivatkozásokat.
• Határozza meg az előfeltételekre és az üzembe helyezési eljárásokra vonatkozó elvárásokat.
• Adjon meg hivatkozásokat azokra a projektekre, amelyektől függ. Ezek a hivatkozások jó módszer mások munkájának előmozdítására.
• A Markdown használatával végigvezeti az olvasókat a megfelelően formázott tartalmakon.

Ha a README.md fájlt az adattár gyökérkönyvtárába vagy a rejtett .github könyvtárba docs helyezi, a GitHub felismeri és automatikusan felfedi a README-et az adattár látogatói számára. Ha egy adattár több README-fájlt tartalmaz, akkor a megjelenő fájl a következő sorrendben lesz kiválasztva a helyekről:

1. A .github könyvtár
2. Az adattár gyökérkönyvtára
3. A docs könyvtár

Megtekinthet néhány nagyszerű példát README fájlokra.

A projekt elindítása után használja az e-maileket és más hálózati csatornákat a projekt előléptetéséhez. A megfelelő célközönség elérése jelentősen növelheti a projektben való részvételt.

További információ a README-fájlokról a GitHub dokumentációjában.

Projektek kezelése a GitHubon

A projektek vontatásának következtében a felhasználók és a hozzájárulások beáramlása sok munkát igényelhet a kezeléshez. A projekttől függően jelentős mennyiségű munkára lehet szükség csak a projekt résztvevőinek elvárásainak kezeléséhez.

A probléma proaktív megoldásához a GitHub egy CONTRIBUTING.md fájlt keres egy adattár gyökerében (vagy /docs/.github ) . Ebben a fájlban ismertetheti a projektre vonatkozó hozzájárulási szabályzatot. A pontos részletek eltérhetnek, de érdemes tudatni a lehetséges közreműködőkkel, hogy milyen konvenciók szerint haladnak a projekttel. Például ahol a csapat lekéréses kérelmeket keres, milyen adatokat kér a hibajelentésekhez, és így tovább.

Ha létezik ilyen CONTRIBUTING.md , a GitHub egy hivatkozást jelenít meg rá, amikor a felhasználók problémákat vagy lekéréses kérelmeket hoznak létre, hogy arra ösztönözzék őket, hogy kövessék azt.

Megtekinthet néhány nagyszerű példát CONTRIBUTING.md fájlokra

Emellett érdemes lehet egy CODEOWNERS-fájlt hozzáadni az adattárhoz a kódmódosítások áttekintéséért felelős személyek vagy csapatok definiálásához.

Probléma és lekéréses kérelemsablonok létrehozása

A GitHub támogatja a kezdősablonok használatát az új problémákhoz és lekéréses kérelmekhez. Ezekkel a sablonokkal megadhatja egy újonnan létrehozott probléma vagy lekéréses kérelem kezdeti leírásának szövegét.

Ha például a projekt rendelkezik .github/ISSUE_TEMPLATE.md, bármikor, amikor egy felhasználó elindítja a probléma létrehozásának folyamatát, ezt a tartalmat látják. Ahelyett, hogy folyamatosan hivatkozniuk kellene a szükséges részletekre egy CONTRIBUTING.mdsablonból, egyszerűen kitölthetik a problémát, mint egy űrlapot a sablonszöveg használatával.

Ez ugyanúgy működik, mint a lekéréses kérelmek esetében, azzal a különbséggel, hogy az elérési út .github/PULL_REQUEST_TEMPLATE.md.

Megtekinthet néhány nagyszerű példát a GitHub problémákhoz és lekéréses kérelmekhez készült sablonjaira.

Munkafolyamatok definiálása

A külső hozzájárulásokat ösztönző projektek esetében mindenképpen meg kell adnia, hogy a projekt milyen munkafolyamatokat követ. A munkafolyamatnak tartalmaznia kell annak részleteit, hogy hol és hogyan kell az ágakat használni a hibákhoz és a funkciókhoz. Tartalmaznia kell a lekéréses kérelmek megnyitásának módját is, valamint az adattár csapatán kívüli személyeknek a leküldéses kód leküldése előtt tudniuk kell minden más adatot. Ha még tervezett munkafolyamatot, érdemes megfontolni a GitHub-folyamat használatát.

Kommunikálnia kell a kiadások és az üzembe helyezések kezelésének stratégiáját. A munkafolyamat ezen részei hatással vannak a napi elágaztatásra és egyesítésre, ezért fontos, hogy közölje őket a közreműködőkkel. További információ arról, hogyan kapcsolódnak a Git-elágazási stratégiához.

A program sikerességének mérése

Minden csapat, amely belefog az InnerSource használatába, át kell gondolnia, hogy milyen metrikákat szeretnének nyomon követni a program sikerességének méréséhez. Bár továbbra is alkalmazhatók az olyan hagyományos mérőszámok, mint például a „piacra kerülési idő” és a „jelentett hibák száma”, nem feltétlenül szemléltetik az InnerSource használatával elért előnyöket.

Ehelyett fontolja meg olyan metrikák hozzáadását, amelyek azt mutatják, hogy a külső részvétel hogyan javította a projekt minőségét. Érkeznek a hibákat kijavító és funkciókat hozzáadó lekéréses kérelmek az adattárba külső forrásokból? Vannak aktív résztvevők a projektről és annak jövőjéről folytatott megbeszéléseken? A program az InnerSource olyan bővítését ösztönzi, amely a szervezet más részein is előnyöket biztosít?

Röviden: a metrikák nehézkesek, különösen akkor, ha az egyéni és csapatbeli hozzájárulások értékének és hatásának méréséről van szó. Ha nem használják azokat megfelelően, a metrikák akár károsak is lehetnek a kultúrára, a meglévő folyamatokra, és ronthatják a szervezet vagy a vezetői csapat kollektív hangulatát. Az InnerSource bevezetésének mérése során vegye figyelembe a metrikákra vonatkozó alábbi útmutatást:

• Mérési folyamat, nem kimenet
  • Kódfelülvizsgálatok átfutási ideje
  • Lekéréses kérelmek mérete
  • Folyamatban lévő megoldások
  • Megnyitásig eltelt idő
• Célokhoz és nem abszolút értékekhez kell mérni
• Csoportok és nem egyének mérése
  • Projekt egyedi közreműködőinek száma
  • Kódot újrafelhasználó projektek száma
  • Csapatok közötti említések (@mentions) száma

Megismerheti az InnerSource-esettanulmányokban mások által élvezett sikereket.