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

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

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

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

• Он как бы говорит участникам: «вы виновны, пока не доказано обратное». И это негативное послание вызывает у них отрицательные эмоции. Участники, чувствующие себя не в своей тарелке, всегда будут искать альтернативы данному проекту. Отпугивать участников — плохо. Но еще хуже — наживать себе тихих, молчаливых врагов.
• Он дает сопровождающим некое покровительство над контрибьюторами, которым многие злоупотребляют. Они могут делать это неосознанно. Тем не менее, эта проблема широко распространена. Сопровождающие по своей природе стремятся всегда оставаться главными в проекте. И если у них есть возможность держать потенциальных конкурентов на расстоянии, они будут это делать.
  
  
• Он дает дорогу дискриминации. Можно утверждать, что проект принадлежит сопровождающим, поэтому у них есть возможность выбирать с кем работать. Мое мнение: проекты, в которых идет разлад между участниками, умрут, и заслуживают этого.
  
  
• Он замедляет «цикл обучения». Инновации требуют быстрых экспериментально-провально-успешных циклов. Некоторые из них помогают найти какую-либо проблему или понять, что продукт неэффективен. Некоторые вносят поправки, которые затем тестируются и работают или проваливаются. Так мы учимся чему-то новому. Чем быстрее будет протекать этот цикл, тем быстрее и аккуратнее будет продвигаться проект.
  
  
• Он дает возможность посторонним людям «затроллить» проект. Это происходит так же просто, как отклоняется очередной патч: «мне не нравится этот код». Обсуждения деталей может потребовать намного больше усилий, чем собственно написание кода. К тому же, гораздо проще осудить готовый патч, чем написать его. Все это — мед для троллей и наказание для честных контрибьюторов.
  
  
• Он обременяет каждого контрибьютера отдельной работой, что иронично и одновременно грустно, когда дело касается open source. «Мы хотим работать вместе, но нас попросили фиксить баги по отдельности».

А теперь давайте посмотрим, как это происходит в Оптимистичном Мердже (ОМ).
Для начала поймем, что все патчи и все контрибьюторы разные.

Мы можем заметить как минимум 4 типа контрибьюторов в оpen 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.
• Сначала заслуги, потом полномочия. Относитесь ко всем справедливо и равноправно.
• Сначала рынок, затем продукт. Стремитесь к рынку конкурирующих и взаимодействующих проектов, а не просто к созданию продукта.

Перевод: Алена Карнаухова

Поддержка публикации — компания Edison, которая разрабатывает биллинговая система для провайдеров, а так же разрабатывает ПО для сдачи налоговой отчетности через Интернет.

Читать еще

• Стратегическая речь Пола Грэма на Defcon 2005: «Неравенство и риск»
• Пол Грэм: крэк, метамфетамин, интернет и Facebook