Чья ответственность за исправление ошибки?

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

1. Я замечаю ошибку в нашем развертывании и разрабатываю быстрый хак-патч. (Например, просто комментируя код, который нам на самом деле не нужен.)
2. Я потратил немного дополнительных усилий, чтобы выяснить реальную ошибку, придумать патч и отправить его с помощью Git pull request или подобного.
3. Мой запрос на получение отклонен. Возможно, патч был несовершенен (например, включены строки, которых у него не должно быть), возможно, он нарушал стиль кодирования, возможно, имел другие последствия. Или, может быть, я сделал что-то не так в Git - запрос на удаление должен был быть перебазирован или что-то в этом роде. Сопровождающий предоставляет отзыв о том, как улучшить исправление, и просит повторно отправить его.

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

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

Есть ли в этих ситуациях стандартный этикет? Как они решаются? Моя реакция необычна? Как далеко вы должны пройти, чтобы исправить ошибку?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для разработчика с открытым исходным кодом есть два типа проблем:

• (а) проблемы без патча
• (б) проблемы, вызванные патчем

Я думаю, что большинство сопровождающих / разработчиков пакетов с открытым исходным кодом ЛЮБИТ идею о том, чтобы помочь ускорить работу с патчами сторонним разработчикам.

Их основная цель, однако, сводит к минимуму количество проблем типа b. Вот почему планка установлена ​​довольно высоко.

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

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

Конечный результат полностью стоит того. Такие вещи, как возможность сказать: «Я пишу код? Да ... Вы запускаете то, что я писал каждый день».