The Right Way to Report a Bug

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Вы знаете, в Zerocracy вы либо программист, либо тестировщик, и мы платим за каждую найденную и сообщенную ошибку. Хотя, не совсем так. Мы платим за каждый отчет об ошибке, который проектный архитектор считает достаточно хорошим для оплаты. Решение архитектора полностью субъективно и неоспоримо, в соответствии с §29 Политики. Некоторые из наших разработчиков находят это несправедливым и просят меня объяснить, как они могут сообщать об ошибках так, чтобы они определенно получали оплату. Вот неисчерпывающий список моих рекомендаций.

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

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

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

Запишите себя в роль пострадавшего. Не говорите просто “класс сломан” - в этом утверждении нет пострадавшего. Так что, никому не нужно спасать жизни. Ошибка незначительна - отсутствует необходимость в оплате. Вместо этого скажите “Я не могу использовать этот класс”. Выступите в роли пострадавшего. Или даже лучше, представьте группу пострадавших: “Никто не может действительно использовать этот класс”.

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

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

Будьте заинтересованными. Скажите что-то вроде “Я готов провести дополнительное исследование и предоставить дополнительные детали, если вам нужно”. Конечно, вы не будете этого делать (в большинстве случаев), но вы должны сказать это. Это будет выглядеть так, будто вам действительно важно, и эта ошибка приходит прямо от вашего сердца. Как они могут не заплатить за это?

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

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

Я верю, что если вы следуете этим простым рекомендациям, вы станете более успешным автором отчетов об ошибках. По крайней мере, в Zerocracy.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 04:43

sixnines availability badge   GitHub stars