Поддержка проектов с открытым исходным кодом

General | Amber | Комментировать запись

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

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

Читайте также: Создание pull-запроса на GitHub

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

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

Составление документации

Простая и понятная документация (которая в свою очередь обеспечит простоту использования программы) расширит базу пользователей. Со временем кто-нибудь из этих пользователей попробует внести вклад в ваш проект с открытым исходным кодом.

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

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

• README.md: краткое описание проекта и его целей.
• CONTRIBUTING.md: инструкции для разработчиков, которые хотят принять участие в создании программы.
• Лицензия программы (прочитать о создании лицензии программ с открытым исходным кодом можно здесь).

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

• Общее руководство для пользователей.
• Мануалы, которые описывают разные варианты использования программы.
• Часто задаваемые вопросы.
• Мануалы по устранению неполадок.
• Примечания к релизам (описание выявленных багов и прочая полезная информация).
• Описание функций, которые вы собираетесь добавить в следующих релизах.
• Видеоуроки.

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

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

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

Пишите документацию так, будто вы пишете её для разработчика, которого нужно быстро ввести в курс дела.

Раздел Issues

Вкладка Issues позволяет отслеживать сообщения о багах и предложения новых функций, которые можно добавить в код. Таким образом сайты для размещения репозиториев открытых проектов (GitHub, GitLab, Bitbucket) позволяют конечному пользователю сообщить о возникших проблемах, а разработчику – своевременно узнать и устранить их. Выпуская программу с открытым исходным кодом, не забудьте открыть Issues для сообщества пользователей.

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

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

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

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

Не стоит огорчаться, получая сообщения о проблемах – это хороший показатель заинтересованности пользователей в развитии и совершенствовании вашего проекта. Issues можно использовать как источник обновлений.

Поддержка новых разработчиков

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

Файл CONTRIBUTING.md должен содержать всю необходимую информацию, которую должен знать разработчик, желающий внести свой вклад в проект. Это может быть пошаговое руководство, контрольный список для разработчиков, в общем – любой удобный формат, позволяющий объяснить разработчику, как именно нужно писать код и создавать pull-запросы.

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

Также рекомендуется поддерживать список авторов и разработчиков проекта. Вы можете предложить разработчикам вносить свои имена в список самостоятельно (даже если пользователь просто поправил опечатки в документации – это достойно похвалы и внесения его имени в список).

Поддержка сообщества

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

Для продвижения проекта можно использовать:

• Блоги;
• Краткие обзоры, видеообзоры и уроки;
• Рассылку;
• Социальные сети;
• Сотрудничество с аналогичными или смежными проектами и их совместное продвижение.

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

• Вики-сайты с документацией, поддерживаемые сообществом;
• Форумы для обсуждения функций и возникших проблем;
• Список для электронной рассылки.

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

Помимо всего вышеперечисленного важно всегда оставаться вежливым, проявлять уважение к тем пользователям, которые заинтересовались вашим проектом и участием в нём.