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ł.

Po pierwsze , zachęcają do 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.

Następnie zmniejszają tarcie. 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.

Na koniec standandaryzują praktyki. 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 Wprowadzenie do 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, którzy są ich właścicielami. Użyj tego poziomu widoczności dla projektów typu InnerSource.
• Repozytoria prywatne są widoczne tylko dla właściciela i wszystkich zespołów lub osób, które dodają. 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 osób niekodujących, które chcą przeglądać lub omawiać projekt.
• Poziom triage jest zalecany dla kontrybutorów, którzy muszą aktywnie zarządzać kwestiami i żądaniami scalenia bez dostępu do zapisu.
• Poziom zapisu jest zalecany dla współautorów, którzy aktywnie wprowadzają zmiany do repozytorium projektu.
• Poziom konserwacji jest zalecany dla menedżerów projektów, którzy muszą zarządzać repozytorium bez dostępu do poufnych lub destrukcyjnych akcji.
• Poziom administratora jest zalecany dla osób, które potrzebują pełnego dostępu do projektu, w tym poufnych i destrukcyjnych akcji, takich jak zarządzanie zabezpieczeniami lub usuwanie repozytorium.

Dowiedz się więcej o uprawnieniach 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 przykładami Awesome 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 niesamowitej 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 kilkoma niesamowitymi szablonami zgłoszeń i próśb o połączenie na GitHubie.

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 przepływu pracy, rozważ przepływ 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ę więcej o tym, jak odnoszą się one do strategii rozgałęziania usługi 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 osiągnęli inni dzięki tym studium przypadku InnerSource.