Пітер Хинченс про Optimistic Merging: Спочатку люди, потім-код. Зберіть правильне співтовариство, і воно напише потрібний код

image

Я виступав на DomCode в листопаді 2015 року (чудова конференція, до речі; проходила в красивому маленькому містечку) і розповідав про своє списку правил для побудови open source спільнот. Один чоловік пізніше попросив мене пояснити, чому я раджу мерджить патчі швидко, не чекаючи завершення тестування безперервної інтеграції (Continuous Integration) і без повторної перевірки коду. Я буду називати цю стратегію optimistic merging (ОМ). І зараз я розповім про деяких її плюси.

Стандартна практика для багатьох спільнот — песимістичний мерджинг (ПМ). Це коли потрібно спочатку дочекатися, поки тестування безперервної інтеграції завершиться, потім переглянути код, потім протестить патчі на гілки і потім дати фідбек автору. Тоді тільки він може пофіксити патчі, і весь цей цикл почнеться заново. На цій стадії супроводжуючий запросто може сказати: «Мені не подобається, як ви це зробили» або «Це не збігається з нашим баченням проекту».

У гіршому випадку можуть пройти тижні і місяці, поки патчі не будуть прийняті. Ну, або їх можуть не прийняти ніколи, і вони будуть відхилені тисячам різних причин.

Мені здається, що у багатьох проектах концепцію ПМ розуміють дещо невірно. Давайте перерахуємо проблеми, які створює ПМ:

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

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

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

  • Він дає можливість стороннім людям «затролити» проект. Це відбувається так само просто, як відхиляється черговий патч: «мені не подобається цей код». Обговорення деталей може вимагати набагато більше зусиль, ніж власне написання коду. До того ж, набагато простіше засудити готовий патч, ніж написати його. Все це — мед для тролів і покарання для чесних контриб'юторів.

  • Він обтяжує кожного контрибьютера окремою роботою, що іронічно і водночас сумно, коли справа стосується open source. «Ми хочемо працювати разом, але нас попросили фиксить баги окремо».
А тепер давайте подивимося, як це відбувається в Оптимістичному Мердже (ОМ).
Для початку зрозуміємо, що всі патчі і все контрибьюторы різні.

Ми можемо помітити як мінімум 4 типу контриб'юторів у ореп source проектах:

  1. Хороші контрибьюторы, які знають правила і пишуть відмінні патчі.
  2. Хороші контрибьюторы, які роблять помилки і пишуть корисні патчі з купою багів.
  3. Посередні контрибьюторы, які пишуть нікому не потрібні патчі.
  4. Контрибьюторы-тролі, які ігнорують правила і пишуть шкідливі патчі.
Концепція ПМ виходить з того, що всі патчі шкідливі, поки вони не визнані чистими і корисними. В той час, як насправді більшість патчів спочатку корисні і стоять поліпшення.

Давайте порівняємо ПМ і ОМ. Що буває, коли всі 4 типи контриб'юторів послідовно приходять в проект?

  1. ПМ: В залежності від довільних критеріїв мердж патчів може проходити швидко або повільно. І принаймні один хороший контриб'ютор залишиться незадоволеним.
    ОМ: хороші контрибьюторы щасливі, і оцінені по достоїнству, і продовжують писати відмінні патчі до тих пір, поки не здадуть проект.
  2. ПМ: контрибьюторы відступають, фиксят патчі і повертаються назад кілька… приниженими.
    ОМ: другий тип контриб'юторів приєднується, щоб допомогти пофіксити їх перший патч. Ми отримуємо коротку кльову патч-вечірку. У нових контриб'юторів тепер є друзі та наставники у проекті.
  3. ПМ: Ми отримуємо словесні перепалки і нерозуміння причин, за якими суспільство так вороже.
    ОМ: Всі ігнорують посереднього контрибьютора. Якщо патч потрібно пофіксити, то це без зволікання робиться. Контриб'ютор втрачає інтерес, і в кінцевому підсумку йде з проекту.
  4. ПМ: Отримуємо перестрілку, в якій грубою силою аргументів виграє троль, що породжує реакцію «бий або біжи». Спільнота пушит огидні патчі.
    ОМ: всі існуючі контрибьюторы негайно повертаються в проект. Немає жодних обговорень. Троль може спробувати атакувати ще раз і, зрештою, виявиться забаненным. Шкідливі патчі назавжди залишаться в історії гіта.
У кожній з цих ситуацій наслідки ОМ набагато краще, ніж наслідки ПМ.

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

Посилання:
ZeroMQ (http://rfc.zeromq.org/spec:22), C4.1: the Collective Code Construction Contract.

І ще кілька порад:
  • Спочатку люди, потім-код. Зберіть правильне співтовариство, і воно напише потрібний код.
  • Спочатку прогрес, потім консенсус. Кінцевий прогрес, якого ви доб'єтеся, важливіше початкового встановлених домовленостей (не рахуючи правил).
  • Спочатку проблеми, потім рішення. Процес повинен виходити з розв'язуваної проблеми.
  • Спочатку правила, потім очікування. Записуйте ваш процес розробки або використовуйте правило C4.1.
  • Спочатку заслуги, потім повноваження. Ставтеся до всіх справедливо і рівноправно.
  • Спочатку ринок, потім продукт. Прагніть до ринку конкуруючих і взаємодіючих проектів, а не просто до створення продукту.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.