Jak dobrze zarządzać programem InnerSource

Ukończone

W tym miejscu omówimy sposób projektowania programu InnerSource w celu korzystania z najlepszych wzorców typu open source w dowolnej organizacji programistycznej.

Co to jest InnerSource?

Każdy może swobodnie używać, modyfikować i udostępniać oprogramowanie typu open source. Korzystając z oprogramowania open source, każdy może wyświetlać, modyfikować i rozpowszechniać projekt w dowolnym celu z myślą, że udostępnianie kodu prowadzi do lepszego, bardziej niezawodnego oprogramowania.

InnerSource to praktyka stosowania wzorców open source do projektów z ograniczoną liczbą odbiorców. Na przykład firma może ustanowić program InnerSource, który odzwierciedla strukturę typowego projektu open source, z tą różnicą, że jest dostępny tylko dla pracowników tej firmy. W efekcie jest to program open source stojący za zaporą firmy.

Korzyści wynikające z korzystania z modelu InnerSource

Program InnerSource może oferować wiele korzyści poza tradycyjnymi modelami zamkniętych źródeł.

Przede wszystkimsprzyjają przejrzystości. Dostęp do kodu źródłowego innych projektów firmowych może przyczynić się do większej produktywności deweloperów podczas pracy nad własnymi projektami. Widzą, jak różne zespoły rozwiązują problemy podobne do tych, z którymi się borykają, i często znajdują kod i inne zasoby, których mogą używać ponownie. Dostęp do problemów wspólnych dla różnych zespołów, żądań ściągnięcia i planów projektów także zapewnia lepsze dane umożliwiające zrozumienie, w jakim kierunku zmierza projekt i jak szybko robione są postępy.

Kolejną kwestią jest eliminowanie konfliktów. Załóżmy, że zespół konsumentów jest zależny od poprawki błędów lub nowej funkcji dla projektu należącego do innego zespołu. W programie InnerSource mają kanał, za pośrednictwem którego mogą zaproponować potrzebne zmiany. A jeśli te zmiany nie mogą być scalane z jakiegokolwiek powodu, zespół konsumentów ma możliwość rozwidlania projektu, aby zaspokoić ich potrzeby.

Ostatnią zaletą jest ustandaryzowanie rozwiązań. Wspólnym problemem dla organizacji zajmujących się oprogramowaniem jest fakt, że różne zespoły mają często różne sposoby działania. Tworzenie programu InnerSource to świetna okazja do przyjęcia standardowych konwencji, które mogą być używane przez każdy zespół programistyczny, nawet jeśli nie przestrzegają identycznych praktyk. Na przykład dwa zespoły mogą preferować różne procesy akceptowania współtworzenia. Ustandaryzowanie sposobu komunikacji w odniesieniu do tych różnych procesów ułatwi użytkownikom udział w pracach każdego z tych dwóch zespołów.

To tylko kilka przykładowych korzyści, jakie daje model oprogramowania InnerSource. Aby dowiedzieć się więcej, zobacz An introduction to InnerSource (Wprowadzenie do modelu InnerSource).

Konfigurowanie programu InnerSource w usłudze GitHub

Ustawianie widoczności i uprawnień repozytorium

Repozytoria GitHub można skonfigurować z trzema poziomami widoczności. Użytkownicy, którzy nie spełniają wymagań dotyczących widoczności, zobaczą strony "nie znaleziono", gdy próbują uzyskać dostęp do repozytorium. Te poziomy są następujące:

• Repozytoria publiczne są widoczne dla wszystkich użytkowników. Tego poziomu widoczności możesz użyć w przypadku projektów typu open source, do których mogą mieć dostęp osoby z organizacji i spoza niej.
• Repozytoria wewnętrzne są widoczne tylko dla członków organizacji, do których należą. Użyj tego poziomu widoczności dla projektów typu InnerSource.
• Repozytoria prywatne są widoczne tylko dla właściciela i tych zespołów lub osób, które zostały przez niego dodane. Użyj tej widoczności dla projektów, do których powinni mieć dostęp tylko konkretni użytkownicy i grupy.

Po ustanowieniu widoczności repozytorium można skonfigurować uprawnienia dla poszczególnych lub zespołów. Istnieje pięć poziomów uprawnień:

• Poziom odczytu jest zalecany dla współautorów niebędących kodami, którzy chcą wyświetlać lub omawiać projekt.
• Poziom Triage (Klasyfikacja) jest zalecany w przypadku współautorów, którzy muszą aktywnie zarządzać problemami i żądaniami ściągnięcia, ale bez konieczności posiadania dostępu do zapisu.
• Poziom Write (Zapis) jest zalecany w przypadku współautorów, którzy aktywnie wypychają elementy do projektu.
• Poziom Maintain (Obsługa) jest zalecany w przypadku menedżerów projektu, którzy muszą zarządzać repozytorium bez dostępu do działań wrażliwych lub destrukcyjnych.
• Poziom Admin (Administrator) jest zalecany w przypadku osób, którym potrzebny jest pełny dostępu do projektu, w tym do działań poufnych i destrukcyjnych, takich jak zarządzanie zabezpieczeniami lub usuwanie repozytorium.

Dowiedz się więcej na temat uprawnień dostępu do repozytorium według poziomu.

Tworzenie wykrywalnych repozytoriów

W miarę zwiększania się programu InnerSource liczba repozytoriów prawdopodobnie znacznie zwiększa się w górę. Z pewnością dostęp do wszystkich tych zasobów w organizacji jest zaletą, jednak skuteczne odnajdowanie zawartości może w tych warunkach stanowić wyzwanie. Aby aktywnie rozwiązać ten problem, najlepszym rozwiązaniem jest rozważenie przez zespoły tego, co mogą zrobić, aby ułatwić innym osobom znajdowanie repozytoriów i pracę z nimi.

Oto kilka najlepszych rozwiązań:

• Używanie opisowej nazwy repozytorium, na przykład warehouse-api lub supply-chain-web.
• Dołączenie zwięzłego opisu. Zdanie lub dwa powinny wystarczyć potencjalnym użytkownikom do określenia, czy projekt może odpowiadać ich potrzebom.
• Licencjonuj repozytorium , aby klienci wiedzieli, jak mogą używać, zmieniać i rozpowszechniać oprogramowanie.
• README.md Dołącz plik do repozytorium. Usługa GitHub używa tego pliku jako strony docelowej, gdy użytkownicy odwiedzają repozytorium.

Dodawanie pliku README

Plik README komunikuje oczekiwania dotyczące projektu i pomaga zarządzać współtworzeniami. Pliki README mogą:

• Wyjaśnienie celu i wizji projektu, tak aby potencjalni użytkownicy mogli określić, czy odpowiada on ich potrzebom.
• Udostępnienie pomocy wizualnych, takich jak zrzuty ekranu lub przykłady kodu, aby zobrazować działanie projektu.
• Dołącz linki do wersji produkcyjnej lub demonstracyjnej aplikacji do przeglądu.
• Określenie oczekiwań dotyczących wymagań wstępnych i procedur wdrożenia.
• Dołącz odwołania do projektów, od których zależysz. Odwołania te są dobrym sposobem na promowanie pracy innych.
• Użyj języka Markdown, aby prowadzić czytelników przez prawidłowo sformatowaną zawartość.

Jeśli umieścisz plik README w katalogu głównym repozytorium lub w ukrytym .github lub docs katalogu, usługa GitHub rozpoznaje i automatycznie wyświetla plik README odwiedzającym repozytorium. Jeśli repozytorium zawiera więcej niż jeden plik README, zostanie wybrany z lokalizacji w następującej kolejności: .github katalog, a następnie katalog główny repozytorium, a na koniec docs katalog.

Zapoznaj się z niektórymi przykładami świetnych plików README.

Po uruchomieniu projektu użyj poczty e-mail i innych kanałów sieciowych, aby je promować. Dotarcie do właściwych odbiorców może przełożyć się na istotny wzrost liczby uczestników projektu.

Zarządzanie projektami w usłudze GitHub

W miarę wzrostu trakcji projektów napływ użytkowników i wkładów może wymagać dużej ilości pracy w zarządzaniu. W zależności od projektu może być wymagana znaczna ilość pracy tylko do zarządzania oczekiwaniami uczestników projektu.

Aby aktywnie rozwiązać ten problem, usługa GitHub szuka CONTRIBUTING.md pliku w katalogu głównym (lub /docs ) /.githubrepozytorium. Użyj tego pliku, aby wyjaśnić zasady udziału w projekcie. Szczegółowe informacje mogą się różnić, ale warto poinformować potencjalnych współautorów, jakie konwencje są zgodne z projektem. Na przykład, gdzie zespół szuka żądań ściągnięcia, jakie szczegóły są żądane w przypadku raportów o błędach itd.

Jeśli istnieje CONTRIBUTING.md , usługa GitHub wyświetla link do niego, gdy użytkownicy tworzą problemy lub żądania ściągnięcia, aby zachęcić ich do korzystania z niego.

Zapoznaj się z przykładami świetnych plików CONTRIBUTING.md

Ponadto rozważ dodanie pliku CODEOWNERS do repozytorium w celu zdefiniowania osób lub zespołów odpowiedzialnych za przeglądanie modyfikacji kodu.

Tworzenie szablonów problemów i żądań ściągnięcia

Usługa GitHub obsługuje szablony startowe dla nowych problemów i żądań ściągnięcia. Użyj tych szablonów, aby podać początkowy tekst opisu nowo utworzonego problemu lub żądania ściągnięcia.

Jeśli na przykład projekt ma .github/ISSUE_TEMPLATE.mdwartość , gdy użytkownik rozpocznie proces tworzenia problemu, zobaczy tę zawartość. Zamiast stale odwoływać się do wymaganych szczegółów z obiektu CONTRIBUTING.md, mogą po prostu wypełnić problem, taki jak formularz przy użyciu tekstu szablonu.

Tak samo działa to w przypadku żądań ściągnięcia, z tą różnicą, że ścieżka do szablonu jest następująca: .github/PULL_REQUEST_TEMPLATE.md.

Zapoznaj się z przykładami świetnych szablonów do tworzenia problemów i żądań ściągnięcia w usłudze GitHub.

Definiowanie przepływów pracy

W przypadku projektów z udziałem zewnętrznych współautorów warto określić przepływ pracy. Przepływ pracy powinien zawierać szczegółowe informacje o tym, gdzie i jak gałęzie powinny być używane w przypadku usterek i funkcji. Powinna również obejmować sposób otwierania żądań ściągnięcia, a wszystkie inne osoby spoza zespołu repozytorium powinny wiedzieć przed wypchnięciem kodu. Jeśli nie masz jeszcze pomysłu na przepływ pracy, rozważ skorzystanie z przepływu pracy usługi GitHub.

Przekaż, jaka jest strategia dotycząca zarządzania wersjami i wdrożeniami. Te części przepływu pracy wpływają na codzienne rozgałęzianie i scalanie, dlatego ważne jest, aby komunikować się z współautorami. Dowiedz się, jaki wpływ mają one na Twoją strategię rozgałęziania w systemie Git.

Pomiar skuteczności programu

Zespół rozpoczynający pracę z modelem InnerSource powinien pomyśleć, jakich metryk będzie używać w celu określenia powodzenia swojego programu. Tradycyjne metryki, takie jak czas wprowadzenia produktu na rynek czy zgłoszone usterki, nadal mogą się przydać, ale niekoniecznie dobrze zilustrują korzyści osiągnięte dzięki zastosowaniu modelu InnerSource.

Zamiast tego rozważ dodanie metryk, które pokazują, w jaki sposób udział zewnętrzny poprawił jakość projektu. Czy repozytorium otrzymuje żądania ściągnięcia z zewnętrznych źródeł, które pozwalają naprawiać usterki i dodawać funkcje? Czy uczestnicy aktywnie biorą udział w dyskusjach na temat projektu i jego przyszłości? Czy program stanowi inspirację do rozszerzania modelu InnerSource w sposób przynoszący korzyści w innej części organizacji?

Krótko mówiąc, metryki są trudne, zwłaszcza jeśli chodzi o mierzenie wartości i wpływu wkładu poszczególnych i zespołów. Jeśli metryki będą używane nieprawidłowo, mogą zaszkodzić kulturze firmy i istniejącym procesom oraz pogorszyć opinię na temat organizacji lub jej kierownictwa. Podczas mierzenia wdrożenia rozwiązania InnerSource należy wziąć pod uwagę następujące wskazówki dotyczące metryk:

• Proces mierzenia, a nie dane wyjściowe
  • Czas przetwarzania przeglądu kodu
  • Rozmiar żądania ściągnięcia
  • Praca w toku
  • Czas potrzebny na otwarcie projektu
• Pomiar względem celów, a nie wartości bezwzględnych
• Mierzenie zespołów, a nie osób
  • Liczba unikatowych współautorów projektu
  • Liczba projektów, w których kod jest ponownie używany
  • Liczba oznaczeń @mentions pomiędzy zespołami

Dowiedz się więcej o sukcesach, które inni cieszyli się w tych badaniach przypadków InnerSource.