Керування успішною програмою InnerSource

Завершено

Тут ми обговорюємо, як ви можете розробити програму InnerSource, щоб користуватися найкращими шаблонами з відкритим кодом у будь-якій організації з розробки програмного забезпечення.

Що таке Внутрішнє джерело?

Будь-який користувач може вільно використовувати, змінювати та надавати спільний доступ до програмного забезпечення з відкритим кодом. Використовуючи програмне забезпечення з відкритим кодом, будь-хто може переглядати, змінювати та розповсюджувати проект з будь-якою метою з думкою про те, що код спільного доступу призводить до кращого та надійнішого програмного забезпечення.

InnerSource – це практика застосування шаблонів з відкритим кодом до проектів з обмеженою аудиторією. Наприклад, компанія може створити програму InnerSource, яка відображає структуру типового проекту з відкритим кодом, за винятком того, що вона доступна лише працівникам цієї компанії. По суті, це програма з відкритим кодом, яка стоїть за брандмауером вашої компанії.

Переваги InnerSource

Програма InnerSource може запропонувати численні переваги, окрім традиційних моделей із закритим вихідним кодом.

По-перше, вони підтримують внутрішню видимість. Доступ до вихідного коду інших корпоративних проектів може допомогти розробникам працювати над власними проектами ефективніше. Вони можуть бачити, як різні команди вирішують проблеми, схожі на ті, з якими вони стикаються, і часто знаходити код та інші активи, які вони можуть повторно використовувати. Доступ до проблем групи, запитів на витягування та планів проектів також надає кращі дані, щоб вони розуміли швидкість і напрямок проекту.

Далі вони зменшити тертя. Припустімо, що команда споживачів залежить від виправлення помилок або нової функції для проекту, який належить іншій команді. У програмі InnerSource вони мають канал, через який вони можуть запропонувати необхідні зміни. І якщо ці зміни не можна злити з будь-якої причини, команда споживачів може розщедлити проект відповідно до своїх потреб.

Нарешті, вони стандартизувати практики. Поширені проблеми, з якими стикаються організації з розвитку, полягає в тому, що різні команди часто розходяться в тому, як вони працюють. Побудова програми InnerSource – це чудова можливість прийняти стандартні конвенції, які можна використовувати в кожній команді розробників, навіть якщо вони не дотримуються однакових практик. Наприклад, дві команди можуть надавати перевагу різним процесам для прийняття внесків. Маючи їх стандартизувати на тому, як вони доносять свої різні процеси робить його набагато легше для будь-якого внеску або.

Порада

Розгляньте можливість використання GitHub Discussions та GitHub Projects для подальшої підтримки співпраці InnerSource між командами.

Ці приклади є лише кількома перевагами, якими користуються програми InnerSource. Докладні відомості див. в статті Загальні відомості про innerSource.

Налаштування програми InnerSource на GitHub

Установлення видимості сховища та дозволів

Ви можете налаштувати репозиторії GitHub із трьома рівнями видимості. Користувачі, які не відповідають вимогам видимості, бачать "не знайдено" сторінки під час спроби отримати доступ до вашого сховища. Рівні:

• спільні репозиторії видимі для всіх користувачів. Використовуйте цю видимість для проектів, які дійсно є відкритим вихідним кодом і пропонують доступ до користувачів у вашій організації та за її межами.
• Внутрішні репозиторії видимі лише членам підприємства, якому вони належать.

Нотатка

Внутрішні репозиторії доступні лише для клієнтів GitHub Enterprise. Ця видимість використовується для проектів InnerSource.

• приватні репозиторії видимі лише для власника та будь-яких команд або окремих осіб, яких вони додають. Ця видимість використовується для проектів, до яких мають мати доступ лише певні користувачі та групи.

Після встановлення видимості сховища ви можете налаштувати дозволи на індивідуальній або командній основі. Існує п'ять рівнів дозволів:

• Рівень читання рекомендовано для співавторів, які не є співавторами, які хочуть переглянути або обговорити проект.
• рівні Triage рекомендовано для співавторів, яким потрібно завчасно керувати проблемами та запитами на витягування без доступу до записування.
• рівень записування рекомендовано для співавторів, які активно підштовхуються до проекту.
• Рівень підтримки рекомендовано для керівників проектів, яким потрібно керувати сховищем без доступу до конфіденційних або руйнівних дій.
• рівня адміністраторів рекомендовано користувачам, яким потрібен повний доступ до проекту, зокрема конфіденційні та руйнівні дії, наприклад керування безпекою або видалення сховища.

Дізнайтеся більше про дозволи на доступ до сховища за рівнем.

Створення видимих репозиторіїв

У міру зростання програми InnerSource кількість репозиторіїв, ймовірно, значно збільшується. Хоча це чудово, щоб всі ці активи були доступні в організації, це може стати проблемою для ефективного пошуку вмісту. Щоб завчасно вирішити цю проблему, командам рекомендовано розглянути, що вони можуть зробити, щоб іншим було легше знаходити та працювати зі своїми репозиторіями.

Нижче наведено кілька практичних порад.

• Використовуйте описове ім'я сховища, наприклад warehouse-api або supply-chain-web.
• Додайте стислий опис. Речення або два має бути достатньо, щоб потенційні користувачі знали, чи може проект відповідати їхнім потребам.
• Ліцензувати сховище, щоб клієнти знали, як вони можуть використовувати, змінювати та розповсюджувати програмне забезпечення.
• Додайте файл README.md до сховища. GitHub використовує цей файл як цільову сторінку, коли люди відвідують сховище.

Додавання файлу README

Файл README повідомляє очікування щодо проекту та допомагає керувати внесками. Файли README можуть:

• Сформулювати мету і бачення проекту, щоб потенційні споживачі розуміли, чи відповідає він їхнім потребам.
• Запропонуйте візуальні засоби, наприклад знімки екрана або зразки коду, щоб проілюструвати проект у дії.
• Додайте посилання на серійну або демонстраційну версію програми для перевірки.
• Установлення очікувань для обов'язкових умов і процедур розгортання.
• Додайте посилання на проекти, від яких ви залежатимете. Ці посилання є хорошим способом сприяти роботі інших користувачів.
• Використовуйте Markdown, щоб направляти читачів за допомогою правильно відформатованого вмісту.

Якщо ви розмістите свій файл README.md у кореневому каталозі вашого репозиторію, або в прихованому .githubdocs каталозі, GitHub розпізнає та автоматично виводить ваш README на поверхню відвідувачам репозиторію. Якщо репозиторій містить більше одного файлу README, то показаний файл вибирається з місць у такому порядку:

1. Довідник .github
2. Кореневий каталог репозиторію
3. Довідник docs

Перегляньте деякі приклади README у форматі README.

Коли проект запуститься, використовуйте електронну пошту та інші мережеві канали для його просування. Досягнення відповідної аудиторії може призвести до значного підвищення участі в проекті.

Дізнайтеся більше про файли README у документації GitHub.

Керування проектами на GitHub

Оскільки проекти набирають сили, приплив користувачів і внесків може вимагати багато роботи для керування. Залежно від проекту, для керування очікуваннями учасників проекту може знадобитися значний обсяг роботи.

Щоб завчасно вирішити цю проблему, GitHub шукає файл CONTRIBUTING.md в кореневому сховищі (або /docs чи /.github). Цей файл призначено для пояснення політики внесків для проекту. Точні відомості можуть відрізнятися, але варто повідомити потенційних співавторів про те, за якими конвенціями слідує проект. Наприклад, де команда шукає запити на витягування, які відомості запитано для звітів про помилки тощо.

Якщо CONTRIBUTING.md існує, GitHub представляє посилання на нього, коли користувачі створюють проблеми або витягують запити, щоб заохотити їх до його виконання.

Перегляньте кілька прикладів CONTRIBUTING.md

Крім того, радимо додати файл CODEOWNERS до сховища, щоб визначити осіб або команди, які відповідають за перегляд змін коду.

Створення шаблонів запитань і питань

GitHub підтримує початкові шаблони для нових проблем і запитів на витяг. Використовуйте ці шаблони, щоб надати початковий текст опису для новоствореної проблеми або запиту на витягування.

Наприклад, якщо проект .github/ISSUE_TEMPLATE.md, коли користувач починає процес створення проблеми, він побачить цей вміст. Замість того, щоб постійно посилатися на необхідні відомості з CONTRIBUTING.md, вони можуть просто заповнити цю проблему, як форма, використовуючи текст шаблону.

Це те ж саме для запитів на витягування, за винятком того, що шлях .github/PULL_REQUEST_TEMPLATE.md.

Перегляньте деякі awesome GitHub питання & витягнути запит шаблони.

Визначення робочих циклів

Для проектів, які заохочували зовнішні внески, обов'язково вкажіть робочий цикл, за яким слід виконувати проект. Робочий цикл має містити відомості про те, де та як слід використовувати гілки для помилок і функцій. Він також повинен включати в себе, як запити на витягування повинні бути відкриті, і будь-які інші деталі, які люди за межами команди сховища повинні знати, перш ніж вони push-код. Якщо у вас ще немає на увазі робочий цикл, радимо потік GitHub.

Слід повідомити про стратегію керування випусками та розгортаннями. Ці частини робочого циклу впливають на щоденне розгалуження та об'єднання, тому важливо повідомити їх співавторам. Дізнайтеся більше про те, як вони пов'язані з вашою стратегією розгалуження Git.

Вимірювання успішності програми

Будь-яка команда, що переходить у InnerSource, повинна подумати про типи показників, які вони хочуть відстежувати, щоб оцінити успіх своєї програми. Хоча традиційні показники, такі як "час на ринок" і "повідомлення про помилки", все ще застосовні, вони не обов'язково збираються проілюструвати переваги, досягнуті через InnerSource.

Натомість варто додати показники, які показують, як зовнішня участь покращила якість проекту. Чи отримує сховище запити на витягування із зовнішніх джерел, які виправляють помилки та додають функції? Чи є активні учасники обговорень навколо проекту та його майбутнього? Чи надихає програма розширення InnerSource, яке стимулює переваги в інших місцях організації?

Коротше кажучи, показники важкі, особливо коли мова йде про вимірювання значення та ефекту внесків окремих осіб і команд. У разі неправильного використання показники можуть завдати шкоди культурі, існуючим процесам і применшити колективні настрої щодо організації або керівної команди. Розмірковуючи над вимірюванням усиновлення InnerSource, зверніть увагу на такі рекомендації щодо показників:

• Процес вимірювання, а не вивід
  • Час повороту перевірки коду
  • Розмір запиту на витяг
  • Триває робота
  • Час відкриття
• Вимірювання цільових об'єктів, а не абсолютних
• Вимірювання команд, а не окремих користувачів
  • Кількість унікальних співавторів проекту
  • Кількість кодів повторного використання проектів
  • Кількість @mentions між командами

Дізнайтеся про успіхи, якими користувалися інші користувачі в цих тематичних дослідженнях InnerSource.