Jak spravovat úspěšný program InnerSource

Dokončeno

Zde probereme, jak můžete navrhnout program InnerSource, který vám umožní využívat nejlepší opensourcové vzory v rámci jakékoli organizace pro vývoj softwaru.

Co je InnerSource?

Kdokoli může volně používat, upravovat a sdílet opensourcový software. Pomocí opensourcového softwaru může kdokoli zobrazit, upravit a distribuovat projekt pro jakýkoli účel s myšlenkou, že sdílení kódu vede k lepšímu a spolehlivějšímu softwaru.

InnerSource je postup použití opensourcových vzorů u projektů s omezenou cílovou skupinou. Například společnost může vytvořit program InnerSource, který zrcadlí strukturu typického opensourcového projektu, s tím rozdílem, že je přístupný pouze zaměstnancům této společnosti. V důsledku toho se jedná o opensourcový program za bránou firewall vaší společnosti.

Výhody programu InnerSource

Program InnerSource může nabídnout řadu výhod nad rámec tradičních uzavřených zdrojových modelů.

Za prvé podporují interní viditelnost. Přístup ke zdrojovému kódu jiných projektů společnosti může vývojářům pomoct dosahovat vyšší produktivity při práci na jejich vlastních projektech. Vidí, jak různé týmy řeší problémy podobné těm, kterým čelí, a často najdou kód a další prostředky, které můžou znovu použít. Přístup k problémům, žádostem o přijetí změn a plánům projektu týmu také znamená, že mají k dispozici lepší data, což jim umožní lépe pochopit rychlost a směr projektu.

Dále snižují tření. Řekněme, že spotřebitelský tým závisí na opravě chyb nebo na nové funkci projektu vlastněného jiným týmem. V programu InnerSource mají kanál, prostřednictvím kterého mohou navrhnout změny, které potřebují. A pokud se tyto změny z nějakého důvodu nedají sloučit, má tým příjemců možnost vytvořit projekt tak, aby vyhovoval jejich potřebám.

Nakonec standardizují postupy. Běžným problémem, se kterým se potýkají organizacemi zabývající se vývojem, je to, že fungování jednotlivých týmů se často liší. Vytvoření programu InnerSource je skvělou příležitostí k přijetí standardních konvencí, které se dají použít v každém vývojovém týmu, i když nedodržují stejné postupy. Například dva týmy můžou preferovat různé procesy pro přijímání příspěvků. Pokud budou týmy nuceny své odlišné procesy komunikovat standardizovaným způsobem, bude pro všechny jednodušší přispívat do obou procesů.

Tip

Zvažte použití diskuzí GitHubu a projektů GitHubu k další podpoře spolupráce InnerSource napříč týmy.

Toto jsou některé příklady výhod, které programy InnerSource přinášejí. Další informace najdete v tématu Úvod do InnerSource.

Nastavení programu InnerSource na GitHubu

Nastavení viditelnosti a oprávnění úložiště

Úložiště GitHub můžete nakonfigurovat se třemi úrovněmi viditelnosti. Uživatelům, kteří nesplňují požadavek viditelnosti, se při pokusu o přístup k úložišti zobrazí stránky nenalezena. Jsou to tyto úrovně:

• Veřejná úložiště jsou viditelná všem uživatelům. Tuto viditelnost použijte pro projekty, které jsou skutečně open source a nabízejí přístup lidem v rámci vaší organizace i mimo ni.
• Interní úložiště jsou viditelná jenom členům podniku, kteří je vlastní.

Poznámka:

Interní úložiště jsou dostupná jenom zákazníkům GitHub Enterprise. Tuto viditelnost použijte pro projekty InnerSource.

• Soukromá úložiště jsou viditelná pouze pro vlastníka a všechny týmy nebo jednotlivce, které přidají. Tuto viditelnost použijte pro projekty, ke kterým by měli mít přístup jenom konkrétní uživatelé a skupiny.

Jakmile vytvoříte viditelnost úložiště, můžete nakonfigurovat oprávnění pro jednotlivce nebo týmy. Existuje pět úrovní oprávnění:

• Úroveň čtení se doporučuje pro přispěvatele bez kódu, kteří chtějí projekt zobrazit nebo probrat.
• Úroveň triáže se doporučuje pro přispěvatele, kteří potřebují proaktivní správu problémů a žádostí o přijetí změn bez přístupu k zápisu.
• Úroveň přispívání se doporučuje pro přispěvatele, kteří aktivně přispívají do projektu.
• Úroveň údržby se doporučuje pro projektové manažery, kteří potřebují spravovat úložiště bez přístupu k citlivým nebo destruktivním akcím.
• Úroveň správce se doporučuje pro uživatele, kteří potřebují úplný přístup k projektu, včetně citlivých a destruktivních akcí, jako je správa zabezpečení nebo odstranění úložiště.

Přečtěte si další informace o oprávněních pro přístup k úložišti podle úrovně.

Jak vytvářet zjistitelná úložiště

S růstem programu InnerSource se počet úložišť pravděpodobně výrazně vertikálně navyšuje. I když je skvělé mít všechny tyto prostředky k dispozici pro organizaci, může začít být problém s efektivním vyhledáváním obsahu. Pokud chcete tento problém proaktivně vyřešit, je osvědčeným postupem, aby týmy zvážily, co můžou udělat, aby ostatním usnadnily hledání a práci s jejich úložišti.

Některé z osvědčených postupů:

• Použijte popisný název úložiště, například warehouse-api nebo supply-chain-web.
• Uveďte stručný popis. Stačí jedna nebo dvě věty, aby potenciální uživatelé věděli, jestli projekt vyhovuje jejich potřebám.
• Licencujte úložiště , aby zákazníci věděli, jak můžou software používat, měnit a distribuovat.
• Zahrňte README.md do úložiště soubor. GitHub tento soubor používá jako cílovou stránku, když uživatelé navštíví úložiště.

Přidání souboru README

Soubor README komunikuje s očekáváními pro váš projekt a pomáhá spravovat příspěvky. Soubory README můžou:

• Vymezte účel a vizi projektu, aby mohli potenciální uživatelé zjistit, jestli odpovídá jejich potřebám.
• Nabídněte vizuální pomůcky, jako jsou snímky obrazovky nebo vzorový kód, pro ilustraci projektu v akci.
• Uveďte odkazy na produkční nebo ukázkovou verzi aplikace ke kontrole.
• Stanovte očekávání ohledně předpokladů a postupů nasazení.
• Zahrnout odkazy na projekty, na kterých závisíte. Tyto odkazy jsou dobrým způsobem, jak propagovat práci ostatních.
• Pomocí Markdownu můžete čtenáře provést správně naformátovaným obsahem.

Pokud umístíte soubor README.md do kořenového adresáře úložiště nebo do skrytého adresáře nebo docs do adresáře.github, GitHub rozpozná a automaticky zobrazí soubor README návštěvníkům úložiště. Pokud úložiště obsahuje více než jeden soubor README, vybere se zobrazený soubor z umístění v následujícím pořadí:

1. Adresář .github
2. Kořenový adresář úložiště
3. Adresář docs

Podívejte se na některé úžasné příklady README.

Jakmile se projekt spustí, můžete ho propagovat pomocí e-mailu a dalších síťových kanálů. Oslovení vhodného publika by mohlo významně podpořit účast na projektu.

Další informace o souborech README najdete v dokumentaci k GitHubu.

Správa projektů na GitHubu

Vzhledem k tomu, že projekty získávají trakci, může nárůst uživatelů a příspěvků vyžadovat spoustu práce, aby bylo možné spravovat. V závislosti na projektu může být potřeba značné množství práce jenom ke správě očekávání účastníků projektu.

Pokud chcete tento problém proaktivně vyřešit, GitHub hledá CONTRIBUTING.md soubor v kořenovém adresáři (nebo /docs ) /.githubúložiště. Tento soubor použijte k vysvětlení zásad příspěvků pro daný projekt. Přesné podrobnosti se můžou lišit, ale je vhodné dát potenciálním přispěvatelům vědět, jaké konvence projekt sleduje. Například tam, kde tým hledá žádosti o přijetí změn, jaké podrobnosti jsou požadovány pro zprávy o chybách atd.

Pokud nějaký existuje CONTRIBUTING.md , GitHub na něj zobrazí odkaz, když uživatelé vytvářejí problémy nebo žádosti o přijetí změn, aby ho mohli sledovat.

Podívejte se na některé úžasné příklady CONTRIBUTING.md

Kromě toho zvažte přidání souboru CODEOWNERS do úložiště, abyste definovali jednotlivce nebo týmy, které zodpovídají za kontrolu úprav kódu.

Vytvoření šablon problémů a žádostí o přijetí změn

GitHub podporuje úvodní šablony pro nové problémy a žádosti o přijetí změn. Pomocí těchto šablon můžete zadat počáteční text popisu nově vytvořeného problému nebo žádosti o přijetí změn.

Pokud má váš projekt .github/ISSUE_TEMPLATE.mdnapříklad , kdykoli uživatel spustí proces vytváření problému, uvidí tento obsah. Místo neustálého odkazování na požadované podrobnosti z ovládacího CONTRIBUTING.mdprvku můžou problém jednoduše vyplnit jako formulář pomocí textu šablony.

Stejné je to i pro žádosti o přijetí změn. Rozdílná je pouze cesta, která je: .github/PULL_REQUEST_TEMPLATE.md.

Podívejte se na některé úžasné šablony problémů a pull requestů na GitHubu.

Definování pracovních postupů

Pro projekty, které podporují externí příspěvky, je nutné určit, jaký pracovní postup se bude na projektu dodržovat. Pracovní postup by měl obsahovat podrobnosti o tom, kde a jak se mají větve používat pro chyby a funkce. Měl by také obsahovat způsob otevření žádostí o přijetí změn a všechny další podrobnosti, které by měli znát lidé mimo tým úložiště, než nasdílí kód. Pokud jste ještě nepřemýšleli o pracovním postupu, měli byste zvážit GitHub flow.

Měli byste informovat o tom, jakou máte strategii pro správu vydaných verzí a nasazení. Tyto části pracovního postupu ovlivňují každodenní větvení a slučování, takže je důležité je sdělit přispěvatelům. Přečtěte si další informace o tom, jak souvisí s vaší strategií větvení Gitu.

Měření úspěchu programu

Každý tým, který se rozhodne pro program InnerSource, by měl popřemýšlet o tom, jaké metriky chce sledovat, aby dokázal posoudit úspěch svého programu. Je sice možné použít tradiční metriky jako „doba uvedení na trh“ a „nahlášené chyby“, ty ale nemusí nutně ilustrovat výhody dosažené prostřednictvím programu InnerSource.

Místo toho zvažte přidání metrik, které ukazují, jak externí účast zlepšila kvalitu projektu. Dostává úložiště žádosti o přijetí změn, prostřednictvím kterých jsou opravovány chyby a přidávány funkce, z externích zdrojů? Jsou v diskusích o projektu a jeho budoucnosti aktivní účastníci? Motivuje využívání programu InnerSource k jeho rozšíření, na základě čehož pak bude možné využívat jeho výhody i v jiných částech organizace?

Stručně řečeno, metriky jsou obtížné, zejména pokud jde o měření hodnoty a účinku příspěvků jednotlivců a týmů. Při nesprávném použití mohou metriky poškodit firemní kulturu, existující procesy a zhoršit kolektivní mínění o organizaci nebo vedoucím týmu. Při zvažení měření přechodu na InnerSource zvažte následující doprovodné materiály k metrikám:

• Proces měření, ne výstup
  • Celková doba zpracování revize kódu
  • Velikost žádostí o přijetí změn
  • Probíhající práce
  • Čas nutný k otevření
• Měření podle cílů a ne podle absolutních hodnot
• Měření týmů a ne jednotlivců
  • Počet jedinečných přispěvatelů do projektu
  • Počet projektů opětovně používajících kód
  • Počet zmínek (@mentions) mezi týmy

Seznamte se s úspěchy, které ostatní měli v rámci těchto případových studií InnerSource.