Как управлять успешной программой InnerSource

  • 8 мин

Здесь мы обсудим, как создать программу InnerSource, чтобы насладиться лучшими шаблонами с открытым кодом в любой организации разработки программного обеспечения.

Что такое InnerSource?

Любой пользователь может свободно использовать, изменять и предоставлять общий доступ к программному обеспечению с открытым кодом. С помощью программного обеспечения с открытым исходным кодом любой пользователь может просматривать, изменять и распространять проект для любой цели с тем, что общий доступ к коду приводит к улучшению, более надежному программному обеспечению.

InnerSource — это практика применения шаблонов с открытым исходным кодом к проектам с ограниченной аудиторией. Например, компания может установить программу InnerSource, которая отражает структуру типичного проекта с открытым исходным кодом, за исключением того, что он доступен только сотрудникам этой компании. Фактически это программа разработки с открытым кодом, защищенная брандмауэром компании.

Преимущества InnerSource

Программа InnerSource может предложить многочисленные преимущества, помимо тех, которые предоставляют традиционные модели закрытого исходного кода.

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

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

Наконец, они стандартизуют методики. Частой трудностью при разработке является то, что разные команды часто расходятся в методах своей работы. Создание программы InnerSource — это отличная возможность принять стандартные соглашения, которые можно использовать во всех командах разработчиков, даже если они не соответствуют идентичным методикам. Например, две команды могут предпочесть разные процессы для принятия взносов. Благодаря стандартизации способа взаимодействия с их различными процессами, вносить свой вклад становится гораздо проще.

Подсказка

Рассмотрите возможность использования обсуждений GitHub и проектов GitHub для дальнейшей поддержки совместной работы 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 в корневой каталог репозитория или в скрытый .github или docs каталог, GitHub распознает и автоматически помещает файл README в посетители репозитория. Если репозиторий содержит несколько readME-файлов, показанный файл выбирается из расположений в следующем порядке:

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

Ознакомьтесь с некоторыми потрясающими примерами 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.

Ознакомьтесь с некоторыми замечательными шаблонами проблем и запросов на вытягивание GitHub.

Определение рабочих процессов

Для проектов, которые приветствуют внешние вклады, необходимо указать, какой рабочий процесс следует использовать в проекте. Рабочий процесс должен содержать сведения о том, где и как должны использоваться ветви для ошибок и функций. Он также должен включать в себя, как следует открывать запросы на вытягивание, а другие сведения, которые находятся за пределами команды репозитория, должны знать, прежде чем отправлять код. Если у вас еще нет рабочего процесса, рекомендуется рассмотреть GitHub flow.

Необходимо сообщить о стратегии управления выпусками и развертываниями. Эти части рабочего процесса влияют на повседневное ветвление и слияние, поэтому важно сообщить им участникам. Узнайте больше о том, как они связаны с стратегией ветвления Git.

Измерение успешности программы

Любой команде, приступающей к работе с InnerSource, следует подумать о том, какие метрики они хотят использовать, чтобы оценивать успешность своей работы. Хотя традиционные метрики, такие как "время до выхода на рынок" и "число найденных ошибок", по-прежнему применимы, они необязательно будут иллюстрировать преимущества использования InnerSource.

Вместо этого попробуйте добавить метрики, которые показывают, как внешнее участие улучшило качество проекта. Получает ли репозиторий запросы на вытягивание из внешних источников, которые устраняют ошибки и добавляют компоненты? Есть ли активные участники обсуждения проекта и его будущего? Вдохновляет ли программа расширение InnerSource, которое обеспечит выгоды в других частях организации?

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

  • Процесс измерения, а не выходные данные
    • Время цикла проверки кода.
    • Размер запроса на вытягивание.
    • Проблемы и их решение.
    • Время на открытие.
  • Измеряйте соответствие целям, а не абсолютным значениям.
  • Измерение команд и не отдельных лиц
    • Число уникальных участников проекта.
    • Число проектов, повторно использующих код.
    • Количество межкомандных @mentions.

Узнайте об успехах, которых добились другие в этих кейс-исследованиях InnerSource.