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

• «Проблема»
• «Не работает»
• «Сломанный»
• «Сбой»
• «Ошибка»
• «Баг»
• «Не работает»
• «Поломка»
• «Не могу выстроить»
• «Не удалось установить»
• «Не работает»
• «Помощь»
• «Не компилируется»
• «Ошибка»
• «Не подключается»
• «Проблема»

Отлично. Ничего особенного.

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

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

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

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

«Это не работает».

Очевидно, что проект ДЕЙСТВИТЕЛЬНО «работает». Вы уже пару дней пользуетесь им ежедневно, и он делает именно то, что вам нужно.

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

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

В системе отслеживания проблем GitHub мы не обращаемся за помощью. Мы жалуемся на то, что пытались сделать, но «не сработало».

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

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

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

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

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

По мере роста количества проектов, которые вы выпускаете как проекты с открытым исходным кодом, растет и количество проблем. Жалобы приходят даже на проекты, которыми вы больше не пользуетесь. Можно ли игнорировать эти проблемы? Каждый раз, когда вы публикуете новый проект, вы подписываете неявный договор с «сообществом» о его поддержке на всю жизнь. А поддержка — это не столько исправление ошибок, сколько помощь пользователям в решении проблем, которые у вас никогда не возникали, коренные причины которых часто совершенно не связаны с вашими проектами.

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

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

За некоторыми из этих проблем «не работает» кроются анонимные сотрудники компании, которые открывают проблемы с аккаунтами, в которых нет активности на GitHub, помимо открытия тикетов поддержки и «запросов функций». С голосами «большого пальца вверх» от аналогичных аккаунтов, появляющихся сразу после публикации. „Не работает. Мы ждем решения“. Если это не заявка «не работает», то это команда: „Отметьте новый выпуск. Это блокирует наши процессы“.

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

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

»Не устанавливается на платформе Titan под управлением BeOS для iPhone 4 (китайская версия 2.7 Pro)"

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

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

Между тем стресс усиливается. Каждая новая заявка вызывает стресс и беспокойство. Не о содержании, а о том, что нужно сделать, чтобы ее закрыть. Сколько времени и сил на это потребуется.

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

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

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

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

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

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

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

А до этого момента накапливающиеся заявки «не работает» делают вашу работу ненужной и неприятной.

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

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

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

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

Mitigations

За примерно 24 месяца, после неоднократных нервных срывов из-за проблем с GitHub, я сделал несколько вещей, которые мне очень помогли.

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

С github-auto-locker закрытые задачи автоматически блокируются через пару месяцев. Если вопрос закрыт, дело закрыто. «Я тоже», всплывающее на тему, о которой говорилось много лет назад, раздражает. Если есть что-то новое, откройте новую заявку, тем более что программное обеспечение могло сильно измениться с момента первоначального обсуждения, и контекст может отличаться.

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

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

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

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

---

• Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
• В современном автомобиле строк кода больше чем…
• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• McKinsey: переосмысляем софт и архитектуру электроники в automotive