Ранее на этой неделе я опубликовал разглагольствования о том, как запрос на включение, который я написал для пакета с открытым исходным кодом, оставался без проверки более 2 лет. Это не был пост, который мне особенно нравился, потому что он родился из-за разочарования, но момент заставил меня задуматься о моих собственных проектах OSS и вернуться к ним. Результатом этих проверок стало несколько усовершенствований проектов и их рабочих процессов, разработанных таким образом, чтобы способствовать конструктивному взаимодействию с членами сообщества, использующими мое программное обеспечение. А теперь я делюсь с вами этими изменениями, чтобы вы могли их рассмотреть для своих собственных проектов OSS:


Конфигурация проекта

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


Это зависит

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


Шаблоны

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


вопросы

Вы можете не только предоставить шаблон для вопросов, но вы можете предоставить контекстный шаблон, основанный на типе поданного вопроса. До сих пор для моих проектов я сохранял эту конфигурацию относительно простой с двумя типами проблем: Bug а также Feature Request. Шаблон ошибки задает вопросы для сбора доказательств, чтобы помочь устранить проблемы, в то время как Шаблон запроса функции будут вопросы, связанные с определением объема пользовательской истории.


Пулл-реквесты

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


Документация

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


README.md

Хотя вы можете понять, как использовать открытый исходный код без документации, принятие зависит от единственного практического руководства для реализации. README.md — это обычный документ, который сегодня можно найти в большинстве проектов с открытым исходным кодом, и он должен содержать некоторый ключевой контент:

  • Раздел «Начало работы», в котором описаны этапы установки и базовая реализация.
  • Словарь, который описывает методы, входы или выходы
  • Цитаты и справочные ссылки


Руководство по содействию

Если ваш файл README.md невелик, вы можете включить в него этот раздел, но, вероятно, практичнее рассматривать его как отдельный документ.

Руководство по содействию используются для описания того, как кто-то может участвовать в проекте. Он должен описывать как обсуждения, так и вклады в код. Вещи, которые вы бы включили в качестве рекомендаций по содействию:

  • Если участник должен подписать лицензионное соглашение участника (CLA). (Добавляйте один из них только в том случае, если он был рекомендован вашим юристом).
  • Стандарты сообщества, например допустимый тип языка в обсуждениях (например, запрещение целенаправленных оскорблений).
  • Руководство по стилю для внесения изменений в код
  • Рабочий процесс (пример: проблема должна быть одобрена, прежде чем будет принят PR)


Действия на гитхабе

Действия на гитхабе предоставляет моим проектам легко настраиваемое решение CI/CD для автоматизации различных этапов рабочих процессов моего проекта. Ниже приведены несколько действий, которые я часто использую:


Сборка и тестирование

Я рассматриваю эти два основных шага, которые есть почти в каждом проекте OSS. Наличие их в качестве действий Github является требованием для обеспечения большей автоматизации рабочего процесса для проекта. Например, если мой проект OSS имеет достаточное тестовое покрытие, я могу автоматизировать прием запросов на вытягивание Dependabot, которые проходят Github Action.


Опубликовать/развернуть

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


Несвежий дворник

Что мне нравится в действия/устарел GHA заключается в том, что он выполняет задачи по очистке моих задач и запросов на слияние. Если в течение 30 дней у кого-либо из них нет новых действий, Stale применяется метка и добавляется комментарий, предупреждающий, что элемент будет закрыт через 30 дней, если не произойдет никаких новых действий. Через 60 дней бездействия действие автоматически закроет элемент и добавит дополнительное сообщение.


Вилка синхронизации

На навскидку мой проект OSS является ответвлением другого проекта, у меня есть Действие Github, которое автоматически создает запросы на вытягивание при обновлении родительского проекта..

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


Покрытие кода

В зависимости от уровня качества моего проекта OSS, у меня может быть строгий 100% test политика покрытия для любых взносов. Хотя мне не нужен сторонний сервис для обеспечения соблюдения такого правила, удобный интерфейс с графическим интерфейсом полезен при просмотре отчетов о покрытии. Существует несколько сторонних зависимостей, которые предлагают отчеты о покрытии кода, и многие из них бесплатны для общедоступных проектов с открытым исходным кодом.


Оповещения

я большой поклонник Слабый для работы, поэтому я настроил свой собственный экземпляр «песочницы» mainwaring.slack.com. Я единственный член своей организации, и вместо того, чтобы использовать его для социального общения, я использую его для сбора событий из сторонних сервисов, таких как Github. Это позволяет мне иметь #open-source-projects канал, где будут появляться уведомления при возникновении новых действий, таких как сообщение о проблеме или отправка запроса на слияние.


Регулярные проверки

Еще один неофициальный Процесс, который я делаю, заключается в регулярной проверке моих проектов, как правило, не реже одного раза в год, но, возможно, и чаще, если какой-либо из моих проектов OSS имеет более высокий трафик. Задачи, которые я выполняю при регистрации, включают:

  • Решите, должен ли этот проект быть заархивирован или нет.
  • Просмотрите все нерешенные вопросы или PR и примите решения, чтобы их можно было закрыть.
  • Зависимости и уязвимости
    • Включите Dependabot, если он еще не настроен
    • Примените любые незавершенные обновления зависимостей
    • Проверяйте уязвимости и принимайте решения в области информационной безопасности
  • Просмотрите вилки проекта: Вилки часто представляют собой небольшие модификации проекта, это может дать вам представление о том, каких функций вам не хватает в вашем проекте.
  • Обзор документации
    • Обновляйте язык по мере необходимости, чтобы улучшить общение
    • Добавляйте дополнительные элементы, такие как значки или мультимедиа, чтобы сообщать подробности о проекте.
  • Обзор CI/CD
    • Добавьте шаги автоматизации рабочего процесса, как указано
  • Опубликовать новую версию