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

Завершено

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

Что такое InnerSource?

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

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

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

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

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

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

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

Эти примеры — лишь несколько из преимуществ, которые предлагают программы InnerSource. Дополнительные сведения см. в разделе Введение в InnerSource.

Настройка программы InnerSource на GitHub

Настройка видимости и разрешений репозитория

Для репозиториев GitHub можно настроить три уровня видимости. Пользователи, которые не соответствуют требованию видимости, видят страницы "не найдены" при попытке получить доступ к репозиторию. Уровни:

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

После установки видимости репозитория можно настроить разрешения на основе отдельных или команд. Существует пять уровней разрешений:

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

Дополнительные сведения о разрешениях на доступ к репозиторию по уровням.

Создавать обнаруживаемые репозитории.

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

Ниже приведены некоторые рекомендации.

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

Добавление файла README

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

• Сформулируйте цель и концепцию проекта, чтобы потенциальные потребители могли понять, насколько он отвечает их потребностям.
• Предложите визуальные вспомогательные средства, такие как снимки экрана или примеры кода, чтобы продемонстрировать проект в действии.
• Включите ссылки на рабочую или демонстрационную версию приложения для проверки.
• Задайте ожидания для необходимых компонентов и процедур развертывания.
• Включите ссылки на проекты, от которых зависите. Эти ссылки являются хорошим способом продвижения работы других.
• Используйте Markdown, чтобы помочь читателям правильно отформатировать содержимое.

Если вы помещаете файл README в корневой каталог репозитория или в скрытый .github или docs каталог, GitHub распознает и автоматически помещает файл README в посетители репозитория. Если репозиторий содержит несколько файлов README, файл для отображения выбирается из расположений в следующем порядке: каталог .github, корневой каталог репозитория и, наконец, каталог docs.

Ознакомьтесь со статьей Прекрасные примеры файлов сведений README.

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

Управление проектами на 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.

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

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

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

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

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

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

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