Как стать автором
Обновить
0
Philtech Initiative
Общественное благо через цифровые технологии

Как построить сообщество. Перевод книги «Социальная архитектура»: Глава 4. Протокол для коллаборации C4

Время на прочтение 24 мин
Количество просмотров 3.5K
Автор оригинала: Pieter Hintjens
«Это эссенция тридцатилетнего опыты разработки программного обеспечения.»

image

Процесс ZeroMQ: C4


Когда мы говорим о ZeroMQ, мы иногда имеем в виду libzmq — основную библиотеку. В начале 2012 года мы синтезировали процесс libzmq в формальный и многоразовый протокол для совместной работы, который мы назвали “Контрактом на разработку коллективного кода” или C4. Вы можете рассматривать это как слой над лицензией (например, MPLv2). Это наши правила, и я объясню причины возникновения каждого из них.

C4 — это эволюция модели GitHub Fork + Pull. Вы можете подумать, что я поклонник git и GitHub. И это точно: эти два инструмента оказали положительное влияние на нашу работу в последние годы, особенно когда речь идет о создании сообщества.

Язык

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе следует интерпретировать так, как описано в RFC 2119.

Начиная с RFC 2119, в тексте про C4 четко указано, что он намерен выступать в качестве протокола, а не как случайно написанный набор рекомендаций. Протокол — это договор между сторонами, который определяет права и обязанности каждой стороны. Они могут быть знакомы в сети, или могут быть незнакомцами, работающими в одном проекте.

Я думаю, что C4 — это первый пример того, как кто-то пытался кодифицировать нормативы сообщества как формальную и многоразовую спецификацию протокола. Раньше наши правила были распространены на нескольких страницах вики и были во многом специфичны для libzmq. Но опыт учит нас, что чем более формальные, точные и многоразовые правила, тем легче становится незнакомым между собой людям сотрудничать. А меньшее количество разногласий означает более масштабируемое сообщество. Во время C4 у нас также было некоторое несогласие в проекте libzmq над тем, какой процесс мы использовали. Не все чувствовали себя связанными одними и теми же правилами. Скажем так, некоторые люди считали, что у них особый статус, и это создавало конфликт с остальной частью сообщества. Таким образом, спецификация сделала вещи понятнее.

Использовать С4 легко: просто разместите свой проект на GitHub, заставьте другого человека присоединиться и откройте функцию pull request. В своем README поместите ссылку на C4, и все. Мы сделали это в целом ряде проектов, и, похоже, это работает. Я не раз испытывал приятное удивление, применяя эти правила к своей собственной работе, например в проекте CZMQ. Никто из нас не бесподобен настолько, что мог бы работать без остальных.

Цели

Спецификация C4 предназначена для обеспечения оптимальной неоднократной модели сотрудничества для проектов с открытым исходным кодом.

Вкратце причина создания C4 заключалась в том, чтобы положить конец разногласиям в процессе сотрудничества в libzmq. Инакомыслящие ушли в другие места. Сообщество ZeroMQ плавно и легко расцветало, как я и предсказывал. Большинство людей были удивлены этому, но и удовлетворены. Не было никакой реальной критики C4, кроме ее ветвящейся политики, о которой я расскажу позже, поскольку она заслуживает отдельного обсуждения.

Есть причина, по которой я рассматриваю историю создания здесь: как основатель сообщества, вы просите людей инвестировать в вашу собственность, товарный знак и брендинг. В свою очередь, как мы и поступаем в случае с ZeroMQ, вы можете использовать этот брендинг, чтобы установить планку качества. Когда вы загружаете продукт маркированный «ZeroMQ», вы знаете, что он был выпущен по определенным стандартам. Это основное правило качества: запишите свой процесс; иначе вы не сможете его улучшить. Наши процессы не идеальны, они никогда и не станут таковыми. Но любой недостаток в них может быть исправлен и протестирован.

Поэтому очень важно сделать C4 пригодным для многократного использования. Чтобы узнать больше о наилучшем возможном процессе, нам нужно собрать результаты максимально широкого спектра проектов.

У всего этого есть следующие определенные цели: расширение сообщества, формируемого вокруг проекта, уменьшение порога вхождения для новых участников и создание масштабируемой модели партнерства с позитивной обратной связью.

Целью номер один является размер и жизнеспособность сообщества — не техническое качество, не прибыль, не производительность, не доля рынка. Цель — просто количество людей, которые вносят свой вклад в проект. Наука здесь проста: чем больше сообщество, тем точнее результаты.

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

Возможно, худшей проблемой, с которой мы столкнулись в libzmq, была зависимость от людей, которые могли понять код, управлять ветками GitHub и делать чистые релизы — все в одно и то же время. Это похоже на поиск спортсменов, которые могут бегать марафоны и спринты, плавать, а также поднимать вес. Мы, люди, можем быть очень хороши, соблюдая специализацию. Просить нас быть действительно хорошими в двух противоречивых вещах не лучшая идея: это резко сократит число кандидатов, что плохо для любого проекта. У нас была эта проблема в libzmq в 2009 году или около того, и она была решена путем разделения роли Мейнтейнера на две: один человек делает патчи, а другой выпускает релизы.
Обеспечение более быстрой и точной разработки проекта путем развития процесса принятия решений.

Это теория — не полностью доказанная, но и не сфальсифицированная. Чем больше сообщество и число людей, которые могут участвовать в дискуссиях, не опасаясь быть подвергнутыми критике или увольнению, тем быстрее и точнее разрабатывается программное обеспечение. Скорость здесь довольно субъективна. Быстрое движение в неправильном направлении не просто бесполезно, оно сильно наносит ущерб проекту (а мы испытали много чего в libzmq, прежде чем перешли на C4).

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

Это занимательное влияние на процесс: git-ветка мастер обычно всегда идеально стабильна. Это связано с размером изменений и временем ожидания, т.е. периодом от написания кем-то кода до его полноценного использования кем-то еще. И все же нормальный процесс обучения проектировки обычно повторяется в проектах, пока не становится стабильным и незыблемым.

Уменьшение внутренней сложности репозиториев, что приводит к облегчению для участия контрибьюторов и уменьшению объема ошибок.

Любопытное наблюдение: люди, которые преуспевают в сложных ситуациях, любят повышать градус запутанности, потому что тогда они сохраняют свою высокую ценность. Это эффект Кобры (загуглите это). Git сделал ветви легкими и оставил нас со слишком распространенным синдромом «git прост, если вы понимаете, что ветвь git — это просто сложенное пятимерное лептонное пространство, которое имеет оторванную историю без промежуточного кеша». Разработчики не должны чувствовать себя глупыми из-за своих инструментов. Я видел слишком много высококлассных разработчиков, запутавшихся в структурах репозитория и не принимающих общепринятую мудрость о ветвях git. Мы скоро вернемся, чтобы разобраться с git-ветвями, дорогой читатель.

Обеспечение статуса коллективной собственности проекту, что увеличивает финансовую мотивацию участников и снижает риск плагиата со стороны враждебных организаций.

В конечном счете, все мы — экономические существа, и ощущение, что «мы владеем этим, и наша работа никогда не может быть использована против нас», значительно облегчает людям жизнь, чтобы инвестировать в проект с открытым исходным кодом, такой как ZeroMQ. И это не может быть просто чувство, это должно быть реальностью. Существует целый ряд аспектов для создания коллективной собственности, мы рассмотрим их один за другим, когда мы пройдемся по C4.

Основные положения

Проект ДОЛЖЕН использовать распределенную систему управления версиями git.

У Git есть свои недостатки. Его API-интерфейс командной строки ужасно непоследовательный, и у него сложная, неряшливая внутренняя модель, которой он тычет вам в лицо по любому поводу. Но, несмотря на то, что он делает все возможное, чтобы заставить своих пользователей чувствовать себя глупо, git делает свою работу действительно очень хорошо. Более прагматично, я обнаружил, что если вы держитесь подальше от определенных областей (ветвей!), люди быстро учатся git и не совершают много ошибок. Это подходит для меня.

Проект ДОЛЖЕН быть размещен на github.com или его эквиваленте, называемом здесь «Платформа».

Я уверен, что однажды какая-нибудь крупная фирма купит GitHub и сломает ее, и на ее место встанет другая платформа. До сих пор Github обслуживает почти идеальный набор минимальных, быстрых, простых инструментов. Я направил туда сотни людей, и все они до сих пор там, словно мухи, застрявшие в блюдце с медом.

Проект ДОЛЖЕН использовать систему управления проектами.

Мы допустили ошибку в libzmq, перейдя на Jira, потому что мы тогда еще не научились правильно использовать трекер GitHub. Jira — отличный пример того, как превратить что-то полезное в запутанный беспорядок, потому что бизнес зависит от продажи большего количества «функций». Но даже не критикуя Jira, сохранение трекера задач на той же платформе означает, что на один пользовательский интерфейс, который придется учить, станет меньше, одним логином станет меньше, появится плавная интеграция между проектами и патчами.

Проект ДОЛЖЕН иметь четко документированные рекомендации по стилю кода.

Это плагин протокола: вставьте здесь правила стиля кода. Если вы не документируете стиль кода, который вы используете, у вас нет оснований, кроме предубеждений, чтобы отклонить патчи.

«Участник (Contributor)» — это человек, который хочет предоставить патч, являющийся набором коммитов, которые решают четко определенные проблемы. «Мейнтейнер (Maintainer)» — это человек, который объединяет патчи в проекте. Мейнтейнеры не являются разработчиками; их работа заключается в соблюдении процесса разработки.

Теперь мы переходим к определениям сторон и разделению ролей, которые избавили нас от пагубной структурной зависимости от редких людей. Это хорошо работает в libzmq, но, как вы увидите, это зависит от остальной части процесса. C4 — не скатерть-самобранка, вам понадобится весь процесс (или что-то очень похожее), чтобы все не рассыпалось на части.

Участники НЕ ДОЛЖНЫ иметь возможность коммитить в репозиторий, если они не являются также Мейнтейнерами. Мейнтейнеры ДОЛЖНЫ иметь возможность коммитить в репозиторий.

Чего мы хотели избежать, так это того, чтобы люди проталкивали свои изменения непосредственно в мастер-ветку. Это был самый большой источник проблем в libzmq исторически: большие массы сырого кода, на стабилизацию которых потребовались бы месяцы или годы. В конечном итоге мы следовали другим проектам ZeroMQ, таким как PyZMQ, с использованием запросов на загрузку. Мы пошли дальше и указали, что все изменения должны идти по тому же пути. Никаких исключений для «особых людей».

Каждый, без различия или дискриминации, ДОЛЖЕН иметь равное право на возможность стать Участником в соответствии с условиями этого контракта.

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

Я думаю, что эта борьба между индивидуальным опытом и коллективным разумом разыгрывается и в других областях. Она создала Википедию, и до сих пор продолжает это делать, уже спустя десятилетие после того, как превзошла все, что могла бы сделать небольшая группа экспертов. По мне так мы делаем программное обеспечение, медленно синтезируя самые точные знания, так же, как мы делаем статьи в Википедии.

Лицензирование и собственность

Проект ДОЛЖЕН использовать такую ​​же лицензию, как MPLv2, или вариант GPLv3 (GPL, LGPL, AGPL).

Я уже объяснил, как полная ремиксабельность (возможность повторной работы с материалом) создает лучший масштаб, и почему MPLv2 или GPL и их варианты кажутся оптимальным контрактом на ремиксабельное программное обеспечение. Если вы крупный бизнес, нацеленный на то, чтобы сбрасывать код на рынке, вам не нужен C4, но тогда вам и нет дела до сообщества.

Все вклады в исходный код проекта («патчи») ДОЛЖНЫ использовать ту же лицензию, что и для проекта.

Это устраняет необходимость в какой-либо конкретной лицензии или соглашении об участии в разработке патчей. Вы делаете форк MPLv2 или GPL кода, публикуете свою переделанную версию на GitHub, и вы или кто-либо еще можете отправить это как исправление к исходному коду. BSD этого не допускает. Любая работа, содержащая BSD-код, может также содержать нелицензионный проприетарный код, поэтому вам нужно разрешение от автора кода, прежде чем вы сможете его переделывать.

Все патчи принадлежат их авторам. НЕ ДОЛЖЕН присутствовать никакой процесс присвоения авторских прав.

Здесь мы подходим к основной причине того, что люди уверены в своем вкладе в ZeroMQ: логически невозможно купить авторские права на создание конкурента с закрытым исходным кодом для ZeroMQ. iMatix тоже не может этого сделать. И чем больше людей посылают патчи, тем сложнее это становится. ZeroMQ не просто свободен и открыт сегодня — эта его особенность позволит ему оставаться таким всегда. Обратите внимание, что это не относится ко всем проектам MPLv2 / GPL, многие из которых по-прежнему требуют возврата авторских прав своим мейнтейнерам.

Каждый Участник ДОЛЖЕН быть ответственным за идентификацию себя в Списке участников проекта.

Другими словами, мейнтейнеры не являются карма-бухгалтерами. Любой, кто хочет добиться одобрения, должен сам заявить об этом.

Требования к патчу


В этом разделе мы определяем обязательства Участника: в частности, что представляет собой «годный» патч, чтобы у Мейнтенеров были правила, в соответствии с которыми они могут принимать решения о принятии или отклонении патча.

Мейнтейнеры и Участники ДОЛЖНЫ иметь учетную запись на Платформе и ДОЛЖНЫ использовать свое настоящее имя или известный псевдоним.

В худшем случае, когда кто-то разместил вредный код (запатентованный или принадлежащий кому-то другому), мы должны уметь отслеживать, кто это сделал и когда, чтобы мы могли удалить код. Указывать настоящие имя или известный псевдоним — это теоретическая стратегия по снижению риска появления фиктивных патчей. Мы не знаем, работает ли это, потому что у нас еще не было проблем с этим.

Патч ДОЛЖЕН представлять собой минимальное решение конкретной идентифицированной и согласованной проблемы.

Это реализация принципа Ориентированной на простоту разработки, про который я расскажу в этой главе позже. Одна явная проблема — одно минимальное решение, применение, тестирование, повторение.

Патч ДОЛЖЕН придерживаться правил стиля кода проекта (style guidelines), если они определены.

Это просто здравомыслие. Я потратил время на очистку чужих патчей, потому что они настаивали на том, чтобы ставить else рядом с if, а не ниже, как того требует Вселенная. Последовательный код выглядит здоровым.

Патч ДОЛЖЕН придерживаться руководящих принципов «Разработка публичных Интерфейсов», определенных ниже.

Ах, боль, боль. Я не говорю о том времени, когда мне было восемь лет, и я наступил на доску с торчащем из нее 4-дюймовым гвоздем. Это было еще ничего. Я говорю о 2010-2011 годах, когда у нас было несколько параллельных релизов ZeroMQ, каждый из которых имел разные несовместимые API или проводные протоколы. Это были упражнения в плохих правилах, бессмысленно соблюдаемых, которые и сегодня все еще причиняют нам боль. Правило гласило: «Если вы измените API или протокол, вы ДОЛЖНЫ создать новую основную версию». Проткните мою ногу гвоздем, это менее болезненно.

Одним из больших изменений, которые мы сделали с C4, является запрет подобного санкционированного саботажа. Удивительно, но это даже не сложно. Мы просто не разрешаем нарушать существующие публичные контракты, и точка, если только все не согласятся с этим, тогда да. Как сказал Линус Торвальдс 23 декабря 2012 года: «МЫ НЕ НАРУШАЕМ ПОЛЬЗОВАТЕЛЬСКОЕ ПРОСТРАНСТВО!»

Патч НЕ ДОЛЖЕН включать нетривиальный код из других проектов, если только Участник не является изначально автором этого кода.

Это правило имеет два эффекта. Во-первых, оно заставляет людей делать минимальные решения, потому что они не могут просто импортировать образцы существующего кода. Из того, что я наблюдал в других случаях, это всегда приводит к плохим результатам, если только импортированный код не разделен очень четко. Во-вторых, оно устраняет споры по поводу лицензий. Вы пишете патч, вы можете опубликовать его как LGPL, и мы можем принять его. Но если вы найдете фрагмент кода в 200 строк в Интернете и попытаетесь вставить его, мы откажем.

Патч ДОЛЖЕН четко компилироваться и проходить самотестирование проекта, по крайней мере, на основной целевой платформе.

Для кросс-платформенных проектов справедливо условие, чтобы патч работал в среде разработки, используемой Участником.

Сообщение коммита ДОЛЖНО состоять из одной короткой (менее 50 символов) строки, в которой задается проблема («Проблема: ...»), за которой следует пустая строка, а затем предлагаемое решение («Решение: ...») ).

Это хороший формат для сообщений коммита, который подходит для эл. почты (первая строка становится темой, а остальная часть — телом письма).

«Корректный патч» — это патч, который удовлетворяет вышеуказанным требованиям.

Если вдруг это не понятно, возвращаемся к формулировкам и определениям.

Процесс разработки


В этом разделе мы поэтапно описываем процесс разработки.
Изменения в проекте ДОЛЖНЫ регулироваться алгоритмом точного выявления проблем и применения минимальных точных решений этих проблем.

Это эссенция тридцатилетнего опыты разработки программного обеспечения. Это крайне простой подход к разработке: делайте минимальные точные решения реальных проблем, ни больше, ни меньше. В ZeroMQ у нас не было места запросам дополнительных функций. Отношения к дополнительным функциям как к багам смущало некоторых новичков. Но это работало, и не только в open-source. Формулировка проблемы, которую мы пытаемся решить, с учетом каждого отдельного изменения, является главным при принятии решения о том, нужно ли внедрять изменение или нет.

Чтобы запросить изменения, пользователь ДОЛЖЕН зарегистрировать проблему на Платформе.

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

Пользователь или Участник ДОЛЖНЫ описать проблему, с которой они столкнулись.

«Проблема: нам нужна функция X. Решение: сделать это» — вот так не правильно. «Проблема: пользователь не может выполнять простые задачи A или B, кроме как с помощью сложного обхода. Решение: сделать функцию X» является достойным объяснением. Т.к. каждый, с кем я когда-либо работал, должен был усвоить это, то стоит еще раз повторить: сначала определяйте реальную проблему, а только затем ее решение.

Пользователь или Участник ДОЛЖНЫ стремиться к консенсусу относительно точности их наблюдения и ценности решения проблемы.

И поскольку многие очевидные проблемы иллюзорны, ясно излагая проблему, мы даем другим возможность исправить нашу логику. «Вы используете только A и B, потому что функция C ненадежна. Решение: сделайте функцию C работоспособной».

Пользователи НЕ ДОЛЖНЫ регистрировать запросы на новые возможности, идеи, предложения или любые решения проблем, которые явно не задокументированы и не доказуемы.

Существует несколько причин не регистрировать идеи, предложения или запросы функций. По нашему опыту, они просто накапливаются в трекере задач, пока их кто-нибудь не удалит. Лучше, когда мы рассматриваем все изменения как решения проблем, ведь тогда мы сможем трезво расставлять приоритеты. Либо проблема реальна, и кто-то хочет ее решить сейчас, либо ее нет в повестке. Поэтому спискам желаний — нет.

Таким образом, история версий проекта ДОЛЖНА быть списком значимых проблем, документируемых и решаемых.

Мне бы очень хотелось, чтобы трекер GitHub просто перечислил все проблемы, которые мы решили в каждом релизе. Сегодня нам приходится писать это вручную. Если вы размещаете номер проблемы в каждом коммите, и если использовать трекер GitHub, о который мы, к сожалению, еще не сделали для ZeroMQ, эту историю релизов легче делать механически.

Чтобы работать над проблемой, Участник ДОЛЖЕН сделать форк репозитория проекта, а затем работать с этой копией.

Здесь мы объясняем модель GitHub fork + pull request, чтобы вновь прибывшим приходилось изучать только один процесс (С4), чтобы стать участником.

Чтобы отправить патч, Участник ДОЛЖЕН создать Pull Request в проект.

GitHub сделал это настолько простым, что нам не нужно для этого изучать команды git. Иногда я рассказываю людям, которые мне особенно не нравится, что командная строка git потрясающая, и все, что им нужно сделать, — это детально изучить внутреннюю модель git, прежде чем пытаться использовать ее в реальной работе. Когда я вижу их несколько месяцев спустя, они выглядят… измененными.

Участник НЕ ДОЛЖЕН производить коммиты непосредственно в проект.

Любой, кто размещает патч, является Участником, и все Участники следуют одинаковым правилам. Никаких особых привилегий для оригинальных авторов, потому что в противном случае мы не создаем сообщество, а только увеличиваем наши эго.

Чтобы обсудить патч, люди МОГУТ комментировать коммиты и Pull Request’ы на Платформе или в другом месте.

Случайно распределенные дискуссии могут сбивать с толку, но GitHub решает это для всех текущих участников, отправляя электронные письма тем, кто должен следить за тем, что происходит. У нас был тот же опыт и то же решение в Wikidot, и оно работает. Нет никаких доказательств того, что обсуждение в разных местах имеет какой-либо негативный эффект.

Чтобы принять или отклонить патч, Мейнтейнер ДОЛЖЕН использовать интерфейс платформы.

Работа через веб-интерфейс GitHub означает, что Pull Request’ы регистрируются как проблемы с рабочим процессом и обсуждением. Я уверен, что есть и более сложные способы работы. Все усложнить очень просто, а вот за простотой стоят огромные усилия.

Мейнтейнер НЕ ДОЛЖЕН принимать свой собственный патч.

Было правило, которое мы определили много лет назад, чтобы остановить выгорание людей: не менее двух человек на проект. Проекты одного человека, как правило, заканчиваются слезами или, по крайней мере, горькой тишиной. У нас довольно много данных о выгорании, почему это происходит и как его предотвратить (даже вылечить). Я расскажу об этом позже в этой главе, потому что, если вы работаете с открытым исходным кодом, вам нужно знать о рисках. Правило «не принимать свой собственный патч» преследует две цели. Во-первых, если вы хотите, чтобы ваш проект был сертифицирован C4, вам нужно взаимодействовать хотя бы с одним человеком, который мог бы помочь. Если никто не хочет вам помочь, возможно, вам нужно переосмыслить свой проект. Во-вторых, контроль за каждым патчем делает его намного более удовлетворительным, удерживает нас в правильном направлении и останавливает нас, если мы нарушаем правила из-за спешки или лени.

Мейнтейнеры НЕ ДОЛЖНЫ делать оценочные суждения относительно корректных патчей.

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

Мейнтейнерам СЛЕДУЕТ быстро принимать исправления.

Существует критерий, который я называю период ожидания изменений, который равен периоду от определения проблемы до тестирования ее решения. Чем быстрее — тем лучше. Если Мейнтейнеры не могут реагировать на Pull Request’ы так быстро, как люди от них того ожидают, значит они не выполняют свою работу (или им нужно больше рук).

Мейнтейнеры МОГУТ принимать некорректные исправления от других Участников с целью: (а) прекращения бесплодных дискуссий, (б) улавливания неправильных патчей в истории, (в) привлечения Участников к улучшению качества их патчей.

Получается, что быстрое принятие несовершенных патчей, что я называю «оптимистичным слиянием», всегда приводит к лучшим результатам, чем требование от участников идеальной работы.

Обычная практика (пессимистичное слияние, ПС) – ждать, пока не будет окончено длительное интеграционное тестирование (CI), потом выполнить ревизию кода, потом протестировать патч в отдельной ветке, и позже отписать автору отзыв. Автор может исправить патч, и тогда цикл тест/ревизия запускается снова. На этой стадии мейнтейнер может сделать (и часто делает) ценное суждение вроде «мне не нравится, как вы это сделали» или «это не соответствует нашему видению проекта».

В худшем случае патчи могут ждать одобрения неделями, месяцами. Или могут вообще не дождаться. Или они будут отклонены, с какими-нибудь отговорками или доводами.
ПС характерно для большинства проектов, и я уверен, что в большинстве случаев не правильно.

Начну с перечисления проблем, которые создает ПС:

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

А теперь посмотрим, как все работает при Оптимистичном слиянии (ОС). Для начала необходимо понять, что не все патчи или участники одинаковы. В наших open source проектах мы наблюдали следующие четыре группы:

  1. Хорошие участники, которые знают правила и пишут прекрасно, идеальные патчи.
  2. Хорошие участники, которые делают ошибки и пишут полезные, но все же битые патчи.
  3. Посредственные участники, создающие патчи, которые никто не замечает или не придает значения.
  4. Участники-тролли, которые игнорируют правила и которые пишут вредоносные патчи.

ПС утверждает, что все патчи вредоносные, пока не доказано обратное (4). А на самом деле большинство патчей полезны и стоят того, чтобы заняться их улучшением (2).

Посмотрим на сценарии ПС и ОС:

  1. ПС: скорость слияния патчей зависит от неопределенных, произвольных критериев. И иногда хороший участник останется с плохим впечатлением. ОС: хорошие участники будут чувствовать себя счастливыми и ценимыми и продолжат делать прекрасные патчи пока не закончат с этим проектом.
  2. ПС: участник сдается, правит патч, возвращается словно униженным. ОС: второй участник подключается, чтобы помочь первому отладить их патч. У нас тут короткая, счастливая патч-партия. У нового участника теперь есть помощник и друг в проекте.
  3. ПС: мы наблюдаем словесную войну и все удивляются, почему сообщество такое враждебное. ОС: посредственный участник повсеместно игнорируется. Если патч требует доработки, то это произойдет быстро. Участник теряет интерес, и происходит откат патча.
  4. ПС: словесная перебранка, в которой побеждают тролли лишь за счет упорства в споре. Общество захлестывают дерись-или-беги эмоции. Продавливаются плохие патчи. ОС: существующий участник сразу откатывает патч. Нет никаких споров. Тролли могут попробовать еще раз, но сразу будут забанены. Вредоносные патчи остаются в git-истории навечно.

В любом случае у ОС результат лучше, чем у ПС.

В большинстве случаев (когда патчи требуют дальнейшей доработки) ОС создает условия для наставничества и менторства. И мы на самом деле наблюдали это в проектах ZeroMQ, и именно поэтому над ними так весело работается.

Пользователь, создавший задачу, ДОЛЖЕН закрыть задачу после проверки исправления.

Когда один человек открывает задачу, а другой работает над ней, лучше позволит первому человеку закрыть задачу. Это будет двойной проверкой того, что задача была решена правильно.

Любой участник, который имеет оценочные суждения о патче, ДОЛЖЕН выразить их через свои собственные патчи.

По сути, целью здесь является позволить пользователям пробовать патчи, а не тратить время в спорах, обсуждая «за» и «против». Насколько легко сделать патч, настолько легко его откатить и применить другой. Вы можете предположить, что это приведет к «войне патчей», но такого не случалось. У нас было несколько случаев в работе с libzmq, когда патчи одного участника уничтожались другим участником, который чувствовал, что эксперимент не двигается в правильном направлении. Это легче, чем пытаться достигнуть консенсуса.

Мейнтейнеры ДОЛЖНЫ закрывать задачи пользователей, которые остаются без действий в течение неприемлемо долгого периода времени.

Держите трекер задач в чистоте.

Ветки и релизы


Когда работает C4, мы получаем два больших упрощения процесса загрузок. Первый: нам не нужно использовать ветки. Второе, мы загружаем все с мастера.

Это процесс, который мы объясняем в этом разделе.

Проект ДОЛЖЕН иметь одну ветку («мастер»), которая всегда содержит последнюю версию, и ДОЛЖЕН всегда компилироваться.

Понятно, что каждый патч что-то да добавляет, но не лишне об этом напомнить. Если мастер-ветка не развивается (и проходит свои тесты), кому-то нужно проснуться.

В проекте НЕ ДОЛЖНЫ использоваться «topic branch» по какой-либо причине. В персональных ветках МОГУТ быть использованы «topic branch».

Вскоре я вернусь к веткам. Вкратце (или «tl;dr», как говорят в интернете), ветки делают репозиторий сложным и разреженным, требуют единогласия – все это дорого, и этого следует избегать.

Для создания стабильного релиза, Мейнтейнер должен использовать тэг в репозитории. Стабильные релизы всегда ДОЛЖНЫ быть отделены от мастер-ветки.

Эволюция публичных контрактов


Под «публичными контрактами» я подразумеваю API и протоколы. До конца 2011 года естественное счастливое состояние libzmq было омрачено нарушенными обещаниями и нарушенными контрактами. Мы полностью прекратили давать обещания (т.н. «дорожные карты») для libzmq, и наша доминирующая теория изменений теперь заключается в том, что они внедряются внимательно и аккуратно со временем. На встрече в Чикаго в 2012 году Гарретт Смит и Чак Ремес назвали это «пьяной спотыкающейся походкой в сторону величия», так я сейчас об этом думаю.

Мы прекратили нарушать публичные контракты, просто запретив эту практику. Раньше это было «хорошо» (как и в случае с нами, и все горько жаловались, а мы их игнорировали) — ломать API или протокол до такой степени, что нам приходилось менять номер версии. Звучит неплохо, пока вы не получите одновременно находящиеся в стадии разработки версии ZeroMQ 2.0, 3.0 и 4.0, не совместимые друг с другом.

Все публичные соглашения (API или протоколы) ДОЛЖНЫ документироваться.

Вы думаете, что это было придумано для профессиональных инженеров-программистов, но нет, это не так. Это — правило. Если вы хотите сертификации C4 для своего проекта, убедитесь, что ваши публичные договоренности задокументированы. Никаких отговорок вроде «это указано в коде». Код не является договором. (Да, я намерен в какой-то момент создать процесс сертификации C4, как индикатор качества проектов с открытым исходным кодом).

Все публичные контракты ДОЛЖНЫ иметь пространство для расширения и экспериментов.

Так, на самом деле общественные договоры меняются. Дело не в том, чтобы не менять их, а в том, что менять их следует безопасно. Это значит обучать (особенно протокольных) разработчиков создавать для этих маневров пространство заранее.

Патч, который изменяет стабильный публичный договор, НЕ ДОЛЖЕН нарушать работоспособность существующих приложений, если не будет преобладающего консенсуса относительно ценности этого решения.

Иногда патч исправляет плохой API, который никем не используется. Нам нужна свобода, но она должна базироваться на консенсусе, а не догматах одного человека. Однако делать рандомные изменения «просто потому что» не есть хорошо. В ZeroMQ v3.x разве мы выиграли от переименования ZMQ_NOBLOCK в ZMQ_DONTWAIT? Конечно, это ближе к POSIX сокету recv(), но разве это повод разрушать тысячи приложений? Никто никогда не заявлял это как задачу. Искажение цитаты Столлмана: «ваша свобода создавать идеальная мир заканчивается в дюйме от моего приложения».

Патч, вводящий новые функции, ДОЛЖЕН делать это с использованием новых имен (новую договоренность).

В ZeroMQ мы раз или два сталкивались с новыми функциями, которые использовали старые имена (или хуже – имена, которые еще использовались где-то). В ZeroMQ v.3.0 был недавно представленный сокет «ROUTER», который был полностью другим, нежели существующий сокет «ROUTER» в 2.х. Господи, фейспалм, почему? Причина: очевидно, даже умных людей иногда стоит контролировать, чтобы они не совершали глупых поступков.

Новые контракты ДОЛЖНЫ маркироваться как «черновик» («draft»), пока они не станут стабильными и не будут использоваться реальными пользователями.
Старые контракты ДОЛЖНЫ систематически отмечаться как «устаревшие» («deprecated»).

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

Старые контракты ДОЛЖНЫ систематически отмечаться как «устаревшие» («deprecated») и заменяться их новыми аналогами по мере необходимости.
По прошествии достаточного количества времени, устаревшие контракты ДОЛЖНЫ быть удалены.

В теории это дает приложениям время двигаться в сторону новых стабильных интерфейсов без риска. Вы можете сначала сделать апгрейд, удостовериться, что все работает, а потом со временем доработать все, чтобы устранить зависимость от устаревших и предыдущих протоколов и API.

Имена устаревших контрактов НЕ ДОЛЖНЫ повторно использоваться новыми контрактами.

Ах, да, помню радость от того, что в ZeroMQ v3.x переименовали топовые функции API (zmq_send[3] и zmq_recv[3]) и выбросили старые названия новых методов, которые были крайне несовместимы (и которые, я подозреваю, мало кто использовал). Вы, должно быть, опять запутались, ударили себя по лбу, но это реально то, что произошло, и я был также виновен, как и все остальные. Ведь, в конце концов, мы же сменили номер версии! Единственная польза этого опыта была в том, что мы вывели это правило.

Администрирование проекта


Учредители проекта ДОЛЖНЫ выступать в качестве Администраторов по набору Мейнтейнеров.

Кто-то должен управлять проектом, и имеет смысл, что учредители должны начать с этого.

Администраторы ДОЛЖНЫ обеспечить свою собственную преемственность, продвигая наиболее эффективных Мейнтейнеров.

В то же время как учредитель проекта вы на самом деле хотели бы сойти с этого пути прежде, чем станете слишком привязанным к нему. Продвижение самых активных и надежных Мейнтейнеров будет полезным для всех.

Новый Участник, который делает правильные патчи, который четко понимает цели проекта, и процесс разработки ДОЛЖЕН быть приглашен стать Мейнтейнером.

Повышайте участников быстро, когда видно, что они заслуживают этого. Все остальное контрпродуктивно.

Администраторы ДОЛЖНЫ отстранять Мейнтейнеров, неактивных в течение длительного периода времени, или неоднократно нарушивших изложенный процесс разработки.

Это было предложение Яна Барбера: нам нужен способ убирать неактивных Мейнтейнеров. Первоначально Мейнтейнеры были самоизбранными, но это затрудняет удаление нарушителей спокойствия (которые редки, но не неизвестны).

Администраторы ДОЛЖНЫ блокировать «плохих участников», которые вызывают стресс и причиняют боль другим людям, участвующим в проекте. Это должно быть сделано после публичного обсуждения, с возможностью для всех сторон говорить. «Плохой участник» — это тот, кто неоднократно игнорирует правила и культуру проекта, выставляет беспочвенные аргументы, производит враждебные или оскорбительные действия, и который не может самостоятельно корректировать свое поведение, когда другие просят его сделать это.

Время от времени ваши проекты будут привлекать людей неправильного характера. С течением времени вы станете быстрее примечать этих людей. C4 помогает двумя способами. Во-первых, устанавливая строгие правила, он отталкивает искателей хаоса и хулиганов, которые не могут терпеть чужие правила. Во-вторых, это дает вам как Администратору возможность заблокировать их. Мне нравится давать таким людям время, чтобы они могли проявить себя и получать их патчи в публичной записи (причина для слияния плохих патчей, которые, конечно же, можно удалить после подходящей паузы).

Перевод книги «Социальная архитектура»:




Об авторе
«К сожалению, мы не выбираем себе смерть, но мы можем встретить ее достойно, чтобы нас запомнили, как мужчин.»
— к/ф «Гладиатор»



Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer в iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот о буферизации данных, обслуживанию очередей, установлению и восстановлению соединений и прочие), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

  • Автор более 30 протоколов и распределенных систем.
  • Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
  • Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
  • CEO сервиса по созданию собственных вики-проектов Wikidot.
  • Он был активистом open standards и основателем Digital Standards Organization.
  • Питер в 2007-м был назван одним из 50 самых влиятельных людей в области «Интеллектуальная собственность».

Подробнее тут: Тридцать пять лет я, как некромант, вдыхал жизнь в мертвое железо при помощи кода

Пришло время для моей последней статьи. Я мог бы написать еще, есть время, но потом буду думать о других вещах: о том, как удобнее устроиться в постели, когда принимать болеутоляющие и о людях рядом со мной.

… я хочу написать одну последнюю модель, последний протокол, который посвящён тому, как уйти из жизни, имея в запасе некоторые знания и время. В этот раз я не буду офоррмлять RFC. :)
Протокол ухода из жизни

Сайт Питера Хинченса
Статья в Википедии

Мысли и идеи Питера Хинченса на Хабре:


О проекте по переводу книги
Я, при поддержке Филтех-акселератора, планирую опубликовать на Хабре (и, может быть, в бумаге) перевод книги «Social Architecture». Имхо, это лучшее (если не единственное адекватное) пособие по управлению/построению/улучшению сообществ, ориентированных на создание продукта (а не на взаимный груминг или «поклонение» лидеру, спортклубу и пр).

image

Прием заявок в акселератор для филтех стартапов продолжается


Если у вас есть на примете проекты/стартапы с высокой долей технологий совпадающие с ценностями филтеха, смело подавайте заявку.
До 25 февраля есть еще время!

Чат в Telegram
Сообщество людей, развивающих PhilTech-проекты или просто заинтересованных в теме технологий для социального сектора.

#philtech news
Новости о проектах в идеологии #philtech и ссылки на полезные материалы.

Страница в Facebook
Новости Philtech-стартапов, российские и международные события из мира технологий для филантропии.

Подписаться на рассылку
Еженедельная рассылка новостей из мира технологий и филантропии.
Теги:
Хабы:
+10
Комментарии 4
Комментарии Комментарии 4

Публикации

Информация

Сайт
philtech.global
Дата регистрации
Дата основания
2018
Численность
11–30 человек
Местоположение
Россия

Истории