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

Original author: Pieter Hintjens
  • Translation
image


Я выступал на 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, которая разрабатывает биллинговая система для провайдеров, а так же разрабатывает ПО для сдачи налоговой отчетности через Интернет.

Читать еще


  • +18
  • 5.9k
  • 9
Edison
95.54
Изобретаем успех: софт и стартапы
Support the author
Share post

Comments 9

    +1
    А почему хорошая идея «deprecated»? Не взлетела на практике?

    image
      0
      Там же чуть далее написано
      Note: this RFC is superсeded by http://rfc.zeromq.org/spec:42/C4
        –13
        Я вообще противник open source.
          +2

          Почему?

          +1

          Очень спорно. "Развитие событий" 2 ОМ, 3 ПМ, 4 ПМ и 4 ОМ непонятно откуда взялось. На самом деле будет так:


          2 ОМ: будут молча мерджиться патчи с багами. Качество проекта в лучшем случае будет стоять на месте, в худшем — быстро ухудшаться. У новых пользователей от забагованности проекта будут шевелиться волосы.


          3 ПМ: ничем не отличается от 3 ОМ.


          4 ПМ: "Получаем перепалку, в которой грубой силой аргументов выигрывает тролль, что пораждает реакцию «бей или беги». Сообщество пушит отвратительные патчи." Извините, я ничего не понял. С какого рожна выигрывает тролль-то?


          4 ОМ: вообще какой-то бред написан.

            +2

            На заметку переводчику: "OM: existing contributor immediately reverts the patch." переводится как "контрибьютор немедленно откатывает патч", а не "все существующие контрибьюторы немедленно возвращаются в проект".


            "second contributor joins" переводится как "другой контрибьютор присоединяется", а не "второй тип контрибьюторов присоединяется". Смысловая разница большая.

              0
              Не согласен.

              При 2 ОМ врядли будут мерджить молча. Тут простое правило, что бессмысленный (или ухудшающий) патч, он и в африке бессмысленный. И все таки большинство людей тратят свое время, чтобы улучшить проект. Да, порой им не хватает знаний, опыта или чего то еще, чтобы сделать это хорошо. Поэтому таким нужно помочь, не молча смерждить, а помочь сделать это хорошо. При этом, естественно, придется потратить время.

              На счет 3 пункта. Просто у Вас как раз ПМ, и Вы перевели разработчиков из второй категории в третью, в этом случае действительно нет разницы.

              Про 4 ПМ согласен, непонятно почему троль выигрывает.

              А про 4 ОМ основной посыл, если я правильно понял, во фразе, «Вредоносные патчи навсегда останутся в истории гита». То есть при таком подходе, даже если потом сделать нормально, то в историии все равно останется след.

              На самом деле, для каждого проекта подход уникален, более того, на разных стадиях развития проекта он должен меняться и исходить из конкретных условий и текущих целей.
                0

                2 ОМ это про таких людей, которые делают нужные вещи в принципе, с полетом мысли, честно прикладывают усилия, но редко когда напишут 5 строчек с первого раза без багов. Из-за невнимательности, наверное. ОМ по определению подразумевает, что мы сначала мержим эти баги, а потом правим пост-фактум, когда или падает CI (тут совсем не факт, что она упадет, потому что тесты покрывают не все), или кто-то ревьюит. Но когда что-то уже смержено и не упало в CI, очень велик соблазн забить на ревью или посмотреть в полглаза, потому что у всех контрибьюторов катастрофически не хватает времени ни на что. Таким образом баги и проникают в проект. Когда есть жесткое правило о двух пре-коммит ревью, вероятность проникновения багов в код уменьшается.

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

            Only users with full accounts can post comments. Log in, please.