Что значит быть сопровождающим?

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

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

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

Документирование ваших процессов

Записывать вещи - одна из самых важных вещей, которую вы можете делать как сопровождающий.

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

Записывая вещи, легче сказать «нет», когда что-то не вписывается в ваши рамки. Это также облегчает людям участие и помощь. Вы никогда не знаете, кто может читать или использовать ваш проект.

Даже если вы не используете полные абзацы, лучше писать тезисы, чем не писать вообще.

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

Запишите видение вашего проекта

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

Наличие четкого, задокументированного видения позволяет вам сосредоточиться и избежать «расползания по масштабам» от вкладов других людей.

Например, @lord обнаружил, что видение проекта помогло ему понять, на какие запросы следует потратить время. Как новый сопровождающий, он сожалел, что не придерживался масштабов своего проекта, когда получил свой первый запрос функции для Slate.

Сообщите о своих ожиданиях

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

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

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

Все это нормально! Просто убедитесь, что об этом знают другие люди.

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

Вот несколько правил, которые стоит записать:

  • Как отзыв рассматривается и принимается (Нужны ли им тесты? Шаблон задачи?)
  • Типы вклада, которые вы примете (Вам нужна помощь только с определенной частью вашего кода?)
  • Когда уместно следить (например, «Вы можете ожидать ответа от сопровождающего в течение 7 дней. Если к тому времени вы ничего не услышали, не стесняйтесь пинговать тему».)
  • Сколько времени вы тратите на проект (например, «Мы тратим на этот проект всего около 5 часов в неделю»)

Джекилл, CocoaPods, и Homebrew - несколько примеров проектов с основными правилами для сопровождающих и участников.

Поддерживайте общедоступность

Не забывайте также документировать свое общение. Везде, где вы можете, делитесь информацией о своем проекте публично. Если кто-то пытается связаться с вами в частном порядке, чтобы обсудить запрос функции или потребность в поддержке, вежливо направьте его на общедоступный канал связи, такой как список рассылки или средство отслеживания проблем (issues).

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

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

Учитесь говорить “нет”

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

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

Сказать «нет» - это не весело, но «Ваш вклад не соответствует критериям этого проекта» кажется менее личным, чем «Мне не нравится ваш вклад».

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

Поддерживайте дружескую беседу

Одно из самых важных мест, где вы будете практиковаться, говоря «нет», - это проблемы (issues) и очередь запросов на перенос. Как сопровождающий проекта, вы неизбежно получите предложения, которые не захотите принимать.

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

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

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

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

Лучше сразу закрыть те взносы, которые вы не хотите принимать. Если ваш проект уже страдает от большого отставания, у @steveklabnik есть предложения как эффективно сортировать проблемы.

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

Если вы не хотите принимать вклад:

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

Для ответа не должно быть более 1-2 предложений. Например, когда пользователь celery сообщил об ошибке, связанной с Windows, @berkerpeksag ответил:

Снимок экрана с сельдереем

Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как сказал @jessfraz выразился:

Я разговаривал с сопровождающими из нескольких различных проектов с открытым исходным кодом, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы сопровождающего - это сказать «нет» патчам, которые вам не нужны.

Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило открытого исходного кода, согласно @shykes: «Нет - временно, да - навсегда». Сочувствовать энтузиазму другого человека - это хорошо. Отказ от вклада - это не то же самое, что отказ от человека, стоящего за ним.

В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы практикуетесь говорить «нет», тем легче это становится. Обещаю.

Быть инициативным

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

Если вы получаете слишком много некачественных материалов, потребуйте от участников заранее поработать, например:

  • Заполнить шаблон/контрольный список для проблемы (issue) и запроса на перенос (pull request)
  • Открыть проблему перед отправкой запроса на перенос

Если они не соблюдают ваши правила, немедленно закройте проблему и укажите на свою документацию.

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

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

Примите наставничество

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

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

Используйте свое сообщество

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

Разделите рабочую нагрузку

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

Один из способов привлечь новых участников - явно обозначить проблемы, которые достаточно просты для начинающих. Затем GitHub будет отображать эти проблемы в различных местах платформы, делая их более заметными.

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

Поощрение других разделить право собственности на проект может значительно снизить вашу рабочую нагрузку, как обнаружила @lmccart в своем проекте p5.js.

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

Если другие люди с энтузиазмом относятся к его направлению, предоставьте им доступ к правкам (to commit) или официально передайте контроль кому-то другому. Если кто-то разветвил (fork) ваш проект и активно поддерживает его в другом месте, подумайте о том, чтобы сделать ссылку на ответвление из вашего исходного проекта. Здорово, что так много людей хотят, чтобы ваш проект продолжал жить!

@progrium обнаружил, что документирование видения его проекта Dokku помогло достичь этих целей даже после того, как он ушел из проекта:

Я написал вики-страницу с описанием того, что я хотел и почему я этого хотел. Почему-то для меня стало неожиданностью, что сопровождающие начали продвигать проект в этом направлении! Произошло ли это именно так, как я хотел? Не всегда. Но это все же приблизило проект к тому, что я написал.

Позвольте другим создавать нужные им решения

Если потенциальный участник придерживается другого мнения о том, что должен делать ваш проект, вы можете мягко поощрить его к работе над собственным ответвлением (fork).

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

То же самое относится к пользователю, которому действительно нужно решение, для создания которого у вас просто нет пропускной способности. Предлагая API-интерфейсы и хуки настройки, можно помочь другим удовлетворить их собственные потребности без необходимости напрямую изменять исходный код. @orta обнаружил, что поощрение плагинов для CocoaPods привело к «некоторым из самых интересных идей»:

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

Принесите роботов

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

Требовать тесты и другие проверки для улучшения качества вашего кода

Один из наиболее важных способов автоматизации проекта - это добавление тестов.

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

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

Если вы добавляете тесты, обязательно объясните, как они работают в вашем файле CONTRIBUTING (руководство участника).

Используйте инструменты для автоматизации основных задач сопровождения

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

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

  • semantic-release автоматизирует ваши выпуски (release).
  • mention-bot упоминает потенциальных рецензентов для запросов на перенос (pull request).
  • Danger помогает автоматизировать проверку кода.
  • no-response закрывает проблемы, когда автор не ответил на запрос дополнительной информации.
  • dependabot-preview проверяет ваши файлы зависимостей каждый день на наличие устаревших требований и если находит, то открывает для них индивидуальные запросы на перенос.

Для отчетов об ошибках и других общих материалов на GitHub есть Шаблоны проблем (issue) и шаблоны запросов на перенос (pull request), которые вы можете создать для упрощения взаимодействия с сообществом. @TalAter создал Руководство по выбору своего собственного приключения, чтобы помочь вам написать свою проблему и шаблоны запросов на перенос (pull request).

Для управления уведомлениями по электронной почте вы можете настроить фильтры электронной почты для сортировки по приоритету.

Если вы хотите стать немного более продвинутым, руководства по стилю и линтеры могут стандартизировать вклады в проект и упростить их просмотр и принятие.

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

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

Нажать паузу - это нормально

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

Возможно, вы чувствуете себя подавленным или чувствуете растущее чувство страха, когда думаете о своих проектах. А между тем проблемы (issues) и запросы на перенос (pull request) накапливаются.

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

Это ясно без слов, если устали - сделайте перерыв! Вам не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять отпуск на месяц после 14 лет волонтерской работы в открытом исходном коде.

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

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

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

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

Береги себя в первую очередь!

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