Я выступал на DomCode в ноябре 2015 года (отличная конференция, кстати; проходила в маленьком красивом городке) и рассказывал о своем списке правил для построения open source сообществ. Один человек позже попросил меня объяснить, почему я советую мерджить патчи быстро, не дожидаясь завершения тестирования непрерывной интеграции (Continuous Integration) и без перепроверки кода. Я буду называть эту стратегию optimistic merging (ОМ). И сейчас я расскажу о некоторых ее плюсах.
Стандартная практика для многих сообществ — пессимистичный мерджинг (ПМ). Это когда нужно сначала дождаться, пока тестирование непрерывной интеграции завершится, потом пересмотреть код, потом протестить патчи на ветви и затем дать фидбэк автору. Тогда только он может пофиксить патчи, и весь этот цикл начнется заново. На этой стадии сопровождающий запросто может сказать: «Мне не нравится, как вы это сделали» или «Это не совпадает с нашем видением проекта».
В худшем случае могут пройти недели и месяцы, пока патчи не будут приняты. Ну, или их могут не принять никогда, и они будут отклонены по тысячам разных причин.
Мне кажется, что во многих проектах концепцию ПМ понимают несколько неверно. Давайте перечислим проблемы, которые создает ПМ:
- Он как бы говорит участникам: «вы виновны, пока не доказано обратное». И это негативное послание вызывает у них отрицательные эмоции. Участники, чувствующие себя не в своей тарелке, всегда будут искать альтернативы данному проекту. Отпугивать участников — плохо. Но еще хуже — наживать себе тихих, молчаливых врагов.
- Он дает сопровождающим некое покровительство над контрибьюторами, которым многие злоупотребляют. Они могут делать это неосознанно. Тем не менее, эта проблема широко распространена. Сопровождающие по своей природе стремятся всегда оставаться главными в проекте. И если у них есть возможность держать потенциальных конкурентов на расстоянии, они будут это делать.
- Он дает дорогу дискриминации. Можно утверждать, что проект принадлежит сопровождающим, поэтому у них есть возможность выбирать с кем работать. Мое мнение: проекты, в которых идет разлад между участниками, умрут, и заслуживают этого.
- Он замедляет «цикл обучения». Инновации требуют быстрых экспериментально-провально-успешных циклов. Некоторые из них помогают найти какую-либо проблему или понять, что продукт неэффективен. Некоторые вносят поправки, которые затем тестируются и работают или проваливаются. Так мы учимся чему-то новому. Чем быстрее будет протекать этот цикл, тем быстрее и аккуратнее будет продвигаться проект.
- Он дает возможность посторонним людям «затроллить» проект. Это происходит так же просто, как отклоняется очередной патч: «мне не нравится этот код». Обсуждения деталей может потребовать намного больше усилий, чем собственно написание кода. К тому же, гораздо проще осудить готовый патч, чем написать его. Все это — мед для троллей и наказание для честных контрибьюторов.
- Он обременяет каждого контрибьютера отдельной работой, что иронично и одновременно грустно, когда дело касается open source. «Мы хотим работать вместе, но нас попросили фиксить баги по отдельности».
А теперь давайте посмотрим, как это происходит в Оптимистичном Мердже (ОМ).
Для начала поймем, что все патчи и все контрибьюторы разные.
Мы можем заметить как минимум 4 типа контрибьюторов в оpen source проектах:
- Хорошие контрибьюторы, которые знают правила и пишут отличные патчи.
- Хорошие контрибьюторы, которые делают ошибки и пишут полезные патчи с кучей багов.
- Посредственные контрибьюторы, которые пишут никому не нужные патчи.
- Контрибьюторы-тролли, которые игнорируют правила и пишут вредоносные патчи.
Концепция ПМ исходит из того, что все патчи вредоносные, пока они не признанны чистыми и полезными. В то время, как в действительности большинство патчей изначально полезны и стоят улучшения.
Давайте же сравним ПМ и ОМ. Что бывает, когда все 4 типа контрибьюторов последовательно приходят в проект?
- ПМ: В зависимости от произвольных критериев мердж патчей может проходить быстро или медленно. И по крайней мере один хороший контрибьютор останется недовольным.
ОМ: хорошие контрибьюторы счастливы, и оценены по достоинству, и продолжают писать отличные патчи до тех пор, пока не сдадут проект. - ПМ: контрибьюторы отступают, фиксят патчи и возвращаются назад несколько… униженными.
ОМ: второй тип контрибьюторов присоединяется, чтобы помочь пофиксить их первый патч. Мы получаем короткую клевую патч-вечеринку. У новых контрибьюторов теперь есть друзья и наставники в проекте. - ПМ: Мы получаем словесные перепалки и непонимание причин, по которым общество так враждебно.
ОМ: Все игнорируют посредственного контрибьютора. Если патч нужно пофиксить, то это без промедления делается. Контрибьютор теряет интерес, и в конечном итоге уходит из проекта. - ПМ: Получаем перепалку, в которой грубой силой аргументов выигрывает тролль, что пораждает реакцию «бей или беги». Сообщество пушит отвратительные патчи.
ОМ: все существующие контрибьюторы немедленно возвращаются в проект. Нет никаких обсуждений. Тролль может попробовать атаковать еще раз и, в конце концов, окажется забаненным. Вредоносные патчи навсегда останутся в истории гита.
В каждой из этих ситуаций последствия ОМ гораздо лучше, чем последствия ПМ.
В большинстве случаев (для патчей, над которыми еще предстоит много работать) ОМ создает условия для обучения и наставничества. И это именно то, что можно увидеть в проекте ZeroMQ, и та причина, по которой с ними настолько классно работать.
Ссылки:
ZeroMQ (http://ift.tt/1jFtsGT), C4.1: the Collective Code Construction Contract.
И еще несколько советов:
- Сначала люди, потом код. Соберите правильное сообщество, и оно напишет нужный код.
- Сначала прогресс, потом консенсус. Конечный прогресс, которого вы добьетесь, важнее первоначального установленных договоренностей (не считая правил).
- Сначала проблемы, потом решения. Процесс должен исходить из решаемой проблемы.
- Сначала правила, потом ожидания. Записывайте ваш процесс разработки или используйте правило C4.1.
- Сначала заслуги, потом полномочия. Относитесь ко всем справедливо и равноправно.
- Сначала рынок, затем продукт. Стремитесь к рынку конкурирующих и взаимодействующих проектов, а не просто к созданию продукта.
Комментарии (0)