Руководство для практиков: Начало работы с отзывчивостью

Основные показатели:

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

Показатели реагирования являются важной частью оценки состояния проекта (Eghbal, 2020) и особенно актуальны для набора новых участников и удержания существующих участников. Быстрота реагирования, включая время на завершение сделки, является одним из наиболее важных факторов привлечения новичков в проект (Fronchetti et al. 2019). Опрос GitHub, проведенный в 2017 году, показал, что, размышляя о том, стоит ли участвовать в проекте с открытым исходным кодом, 95% участников заявили, что отзывчивость сопровождающих очень или несколько важна. Участники могут разочароваться, если не получат своевременного и надлежащего ответа на свой вклад, но их можно воодушевить, когда они получат быстрое и полезное решение по своему вкладу. Когда проекты реагируют на запросы, у людей может возникнуть желание вносить больший вклад или продолжать вносить свой вклад. Своевременные, вдумчивые и добрые ответы участникам указывают на то, что вы цените их работу.

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

Шаг 1: Определите тенденции

Хотя существуют и сложные способы рассмотрения отзывчивости, начать работу с показателями отзывчивости может быть несложно, если вы начнете с выявления тенденций. Глядя на Время до первого ответа, Время закрытьи Коэффициент закрытия запроса на изменение вместе вы можете получить представление о том, получают ли участники своевременный ответ и успеваете ли вы за вкладами, закрыв запросы на изменения (объединенные или закрытые без слияния).

Время до первого ответа

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

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

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

Время закрыть

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

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

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

Среднее время закрытия 8.941 дня и среднее время закрытия 4.022 дня.

Коэффициент закрытия

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

Коэффициент закрытия - поддерживает и не отстает от взносов, показывая, что они отстают в июле и августе.

На этом графике показан коэффициент закрытия запросов на изменения (запросы на слияние/вытягивание), чтобы увидеть, справляется ли проект с поступающими вкладами. Это важно по нескольким причинам. Старые запросы на изменения иногда остаются слишком долго, потому что сопровождающие не хотят сообщать кому-либо, что они не будут приняты, часто по веским причинам, таким как архитектурная несовместимость или другие конфликты с направлением проекта. Это приводит к тому, что участники зависают и не понимают, почему их запрос не объединяется, что может напрасно тратить время людей и плохо отражаться на проекте. В этом случае может помочь обучение сопровождающих тому, как важно закрывать запросы на изменения и как делать это с сочувствием и добротой по отношению к людям, которые вносят свой вклад в работу. Если даже качественные и релевантные запросы на изменения не объединяются в разумные сроки, это может указывать на то, что в проекте просто не хватает специалистов по сопровождению или что у сопровождающих не хватает пропускной способности, чтобы идти в ногу со временем. Через некоторое время объединение старых запросов на изменения также становится непрактичным, поскольку часто возникает слишком много конфликтов слияния, которые невозможно реально разрешить.

Шаг 2: Диагностика

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

Коэффициент закрытия - поддерживает и не отстает от вкладов, показывая, что проект постепенно перестал успевать за ним.

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

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

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

Время выполнения, показывающее время закрытия, постепенно увеличивается

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

Шаг 3. При необходимости соберите дополнительные данные.

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

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

Метрики:

Шаг 4. Внесите улучшения

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

Если вы видите, что скорость реагирования снижается, возможно, пришло время перевести больше участников на руководящие должности и повысить некоторых участников до сопровождающих вашего проекта. Вы можете начать с поиска участников вашего проекта, чтобы найти людей, которые регулярно вносят свой вклад, но еще не занимаются сопровождением. Хорошим первым шагом будет назначение некоторых участников на роли рецензентов, где они смогут снизить нагрузку на сопровождающих, проверяя вклады других членов сообщества. Больше людей, проверяющих вклады, должно обеспечить более быстрое получение первого ответа и улучшенный коэффициент закрытия запросов на изменения, поскольку у сопровождающих будет меньше работы для каждого вклада, и они смогут сосредоточиться на вещах, которые требуют большего опыта в рамках проекта. Вам также следует подумать, готовы ли существующие участники взять на себя роль сопровождающего в проекте, и могут ли они начать с ответственности за одну область в репозитории, используя ВЛАДЕЛЬЦЕВ или CODEOWNERS файлы для управления доступом. Если у вас еще нет хорошей документации о руководящих ролях в вашем проекте, вам также может потребоваться лучше определить роли и обязанности участников, рецензентов и сопровождающих, что может помочь в наборе новых людей на эти роли, используя что-то вроде лестница участников, См. Руководство для практикующих специалистов по устойчивому развитию чтобы узнать больше о наборе участников и продвижении их на руководящие должности.

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

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

  • Не отправлять изменения в X строк кода (подходящим порогом может быть 500–800).
  • Не отправляйте изменения, которые затрагивают более X файлов (в идеале — один файл, но если вам необходимо изменить несколько связанных файлов, ограничьте его одной функцией/проблемой для каждого запроса на изменение).
  • Храните запросы на изменения в отдельных ветках функций.
  • Четко сообщите, какие проверки будут выполняться по запросу на изменение, прежде чем их можно будет объединить (например, проверки стиля, линтеры, наборы тестов, подписанные коммиты, проверки сертификата происхождения разработчика).
  • Четкие политики и примеры именования, маркировки и маркировки запросов на изменения.
  • Обеспечьте ожидания от проверок (например, мы стараемся не оставлять проблемы/запросы на изменения открытыми более чем на X дней, мы проводим обработку невыполненной работы каждые X дней/недель/месяцев.)

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

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

Шаг 5: Мониторинг результатов

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

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

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

Предостережения и соображения

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

Дополнительное чтение

Обратная связь

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

Соавторы

Следующие люди внесли свой вклад в создание этого руководства:

  • Рассвет Фостер
  • Чан Вунг
  • Реми ДеКазмейкер
  • Луис Каньяс Диас
  • Иоахим Норейко

Рекомендации

Руководства для практиков CHAOSS — это живые документы, лицензированные MIT, и мы будем рады вашим отзывам и вкладу. Вы можете предложить изменения к этому документу на странице https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/responsiveness.md