Чия відповідальність несе виправлення помилок?

Ситуація, яка виникала кілька разів у проектах з відкритим кодом, виглядає так:

1. Я помічаю помилку в нашому розгортанні і з'ясовую швидкий виправлення. (Наприклад, просто коментуючи код, який нам насправді не потрібен.)
2. Я витрачаю трохи додаткових зусиль, щоб з’ясувати справжню помилку, придумати патч і надіслати його за допомогою Git pull запиту чи подібного.
3. Мій запит на відхилення відхилено. Можливо, патч був недосконалим (наприклад, включені рядки, які він не повинен мати), можливо, він порушував стиль кодування, можливо, він мав інші розгалуження. А може, я зробив щось не так у Git - запит на притягнення повинен був бути переоформлений чи щось. Підтримувач надає відгуки про те, як поліпшити виправлення, і просить надіслати його повторно.

На даний момент я розгублений щодо того, як далеко я повинен пройти. Що стосується мене, у мене немає проблеми: я виправив її ще на кроці 1. Я повідомив про проблему, навіть вжив заходів, щоб виправити її для інших. Але я не відчуваю, що це "мій" запит на тягу, тому я не відчуваю, що відповідальність за поліпшення виправлення повинна прийти до мене.

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

Чи є в цих ситуаціях стандартний етикет? Як вони вирішуються? Моя реакція незвична? Як далеко ви очікуєте зайти, щоб прийняти виправлення помилок?

(Зверніть увагу, коли я кажу "проект з відкритим кодом", деякі з них дуже малі, але це не можуть бути захопленнями - просто невеликі програмні проекти, які корисні для декількох організацій, які зобов'язують ресурси розробника працювати над ними. У випадку очевидної відповіді це "виправити виправлення та повторно надіслати", розумійте, що я маю обов'язки перед роботодавцем працювати над речами, які їм приносять користь. Витратити час на виправлення помилки, яка не впливає на нас, було б неправильним ...)

Що стосується мене, якщо ви виявите помилку або маєте запит на вдосконалення, не є учасником проекту, і ви подали звіт про дефекти через відповідні канали, ви закінчите. Що стосується повернення громаді, кожен, хто використовує проект із відкритим кодом та виявить дефект, повинен повідомити про це.

Спроба знайти рішення, спроектувати його та втілити його є бонусом до проекту. Якщо ви це зробили, може бути хорошою ідеєю надіслати його або через запит на витягнення, або, можливо, надіслати дельти файлів команді розробників разом із звітом про дефекти або запитом на покращення, щоб дати їм щось працювати. Однак вони не зобов'язані приймати ваш внесок у проект.

Мені здається неправильним очікувати того, що користувач буде робити патчі. Досить легко взяти участь у дискусії про проблему, але це набагато більша інвестиція в часі, щоб знайти рішення. Жоден проект не повинен очікувати, що учасники, які не внесли участь у програмі, стануть учасниками, аби вирішити одну проблему.

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

І ти не без проблем. Ваш виправлення не буде в наступному оновлення. Тож вам доведеться перезавантажувати і сподіватися, що це спрацює або помасажуйте його на місце, коли ви захопите нову версію. Тож перехід до основного проекту дозволить заощадити вам та вашій компанії час.

Це вам болить, але ви вносите свій внесок у співтовариство. Я, безумовно, ціную всіх учасників роботи. Це не як якісне програмне забезпечення, а просто магічне генезування з маси. Хтось повинен виконати роботу. (То хто дивовижний? Ти дивовижний). Якщо ви цього не відчуваєте, повідомте громаді, що, хоча ви цінуєте обговорення того, як воно має бути, ви просто занадто зайняті, щоб це зробити. Я маю на увазі, що вони збираються робити? Знизити зарплату?

Є один принцип, який полегшує розуміння культури з відкритим кодом: людина, яка виконує роботу, вирішує, над чим працювати. Це одне із його звернень порівняно з роботою на день розробників. Вашим пріоритетом №1 може бути №50 у їхньому відставанні. Якщо ви не виправите свій запит на витяг, з часом він, ймовірно, скрутиться до верху, і вони подбають про нього. Однак якщо вам це зробити досить легко, вони зараз про це подбають.

Інша причина, по якій вони просять вас виправити запит на витяг, є більш великодушною. Вони хочуть, щоб ви отримали кредит за ваш внесок, невеликий, як це може бути. Якщо ви робите виправлення, ваше ім’я - це ім’я в полі автора. Більшість людей пишаються своїм внеском, щоб хотіли побачити це, тож умова експлуатації за замовчуванням утримувачів - це дозволяти їм.

Що стосується вашої відповідальності перед вашим роботодавцем, якщо ваш бізнес покладається на цей код, ви не робите їм користь. Роботодавці знають користь робочого, який потребує часу, щоб заточити його інструменти.

AFAIK, відкритим кодом є те, що відповідальність за виправлення помилок залишається тим, хто достатньо дбає про помилку, щоб впоратися з тягарем, щоб забезпечити її виправлення. Залежно від обставин, я робив усе, просто не звертаючи уваги на проблему, щоб вирішити проблему (надавши патчі та сперечаючись, щоб вони були прийняті), щоб переконатися, що це було виправлено.

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

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

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

Для розробника з відкритим кодом існує два типи проблем:

• (а) проблеми без виправлення
• (b) проблеми, викликані пластиром

Я думаю, що більшість розробників / розробників пакетів з відкритим кодом ЛЮБИТЬ ідею допомагати непрофесійним учасникам швидко розвивати свої патчі.

Однак їх основна мета - мінімізувати кількість проблем типу B. Ось чому планка встановлена ​​досить високо.

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

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

Кінцевий результат цілком вартий того. Такі речі, як те, що можна сказати "Чи потрібно кодувати? Так ... Ви щодня працюєте над тим, що я писав".