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

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

Мантейнер CodeTriage.com и один из организаторов Keep Ruby Weird Ричард «Ruby Hero» Шниман считает, что сопровождение пакетов требует от участника проекта слишком больших временных затрат на получение необходимой информации. Какую версию ПО вы используете? Работала ли программа раньше? При каких условиях возникает ошибка? Уточнение деталей утомительно и не особенно интересно.

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

С баг-репортами происходит примерно то же самое. Умение проводить «сортировку» — важнейший навык для любого мантейнера. Причём, он может быть приобретён достаточно быстро и не требует серьёзных знаний в области программирования.

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

Ричард Шниман выделяет несколько аспектов эффективной работы в области сопровождения открытого ПО.

Выбери пакеты

Прежде всего, следует выбрать проект, работа в рамках которого принесёт максимальную пользу и сообществу, и участнику. Например, программисту на Python можно обратить внимание на Django, Requests library, или иные активно развиваемые пакеты.

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

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

Ричард Шниман предлагает следующий алгоритм работы над проблемой:

10) Сообщение об ошибке.

20) Сбор информации для её воспроизведения.

30) Если ошибка не воспроизводится, то GOTO 20.

По сути, это и есть основная часть работы по «сортировке» ошибки.

Следи за актуальностью

Любая проблема имеет «срок годности». Через некоторое время сообщивший о ней пользователь может самостоятельно найти решение. Или ошибка пропадёт сама собой — так тоже бывает.

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

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

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

Отслеживай регрессии

Если программа перестала нормально работать после обновления, то вероятнее всего имеет место регрессия. Как правило, это самые простые ошибки для мантейнера. В этом случае баг-репорт содержит слова «раньше работало, а теперь нет». Тем не менее, дополнительной информации в нём всегда бывает недостаточно.

Её можно получить, задав автору баг-репорта следующие вопросы: «Какая версия используется сейчас? Какая версия использовалась до появления ошибки?». Главная задача — получить от пользователя какие-то инструкции, которые позволят воспроизвести проблему.

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

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

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

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

Доверяй, но проверяй

Чтение баг-репортов сродни чтению газет — не стоит сразу и безоговорочно верить всему, что там написано. Причём, и там, и тут чаще всего уместно говорить не о сознательном обмане, а о недостаточной компетентности автора.

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

Хороший мантейнер никогда не забывает поблагодарить автора образцово составленного отчёта. Тем более, что он сэкономил время, необходимое для выявления и исправления недостатка ПО.

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

Выходи за рамки

Иногда пользователи сообщают об ошибках, которые таковыми вовсе не являются. Просто люди недостаточно внимательно изучили документацию или не поняли её. Не следует в этом случае писать «RTFM» и закрывать баг-репорт. Мантейнеру бывает полезно поставить себя на место пользователя и всё-таки поискать недостатки в проекте — именно такой подход позволяет ему повысить свою репутацию и даже приобрести нового потенциально полезного участника сообщества.

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

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

Работай с дублями

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

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

В конце концов, одна голова — хорошо, а две — всё-таки лучше.

Ищите закономерности

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

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