Кратко

  • Опубликованные правила Apache различают квалифицированное вето на изменение кода, формальное голосование за выпуск пакета, проектные полномочия PMC и корпоративный надзор Board.
  • Квитанция полномочий должна связать действие, артефакт, круг с обязательным голосом, правило, возражения, результат и отдельный корпоративный акт, а не называть commit, голосование и внимание Board одним мандатом.

Одно имя Foundation не делает все действия одним решением

Фраза «Apache одобрила» может означать commit, обсуждение в рассылке, голосование за релиз, решение PMC, Board resolution или лишь вопрос о квартальном отчёте. Публичная архитектура ASF не считает это синонимами. Техническое и общественное направление закреплено за PMC каждого проекта; активы, должности, общая политика и надзор находятся на корпоративном уровне Foundation.

Поэтому сначала нужно установить не того, кто участвовал, а действие. Запись в репозиторий — техническое действие. Объявление конкретного артефакта официальным релизом — акт PMC. Назначение officer, resolution или рассмотрение отчёта — иной корпоративный акт. Один человек может занимать несколько ролей, но его биография не расширяет пределы каждой из них.

Доступ committer не равен праву формального релиза

PMC Guide говорит, что committers могут обновлять код, но только PMC как орган вправе голосовать за формальные релизы программного обеспечения. Это не уменьшает значение индивидуального вклада. Это отделяет техническую возможность изменить исходники от институционального акта представления артефакта как официального выпуска Apache.

Поэтому релизу нужна устойчивая идентичность: candidate, source revision, подпись, checksum или окончательный идентификатор. Подсчёт голосов без такого объекта не отвечает, что именно было решено. И голосование PMC не доказывает, что Board проверила каждую строку, все участники согласились или пользователи примут пакет.

Вето на код сильно, но не является общим красным сигналом

Apache Voting Process различает процедурные вопросы, изменения кода и релизы пакетов. Для не-lazy изменения кода требуется три +1 и ни одного -1. -1 квалифицированного голосующего может быть veto: оно должно содержать техническое обоснование и не может быть отменено, пока сам голосующий его не отзовёт.

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

У формального релиза другой тест

Для релиза пакета Apache требует как минимум три обязательных +1 и больше обязательных положительных, чем отрицательных голосов; руководство также говорит, что релизы нельзя veto. Это не смягчённое название правила для кода, а иной тест для иного действия.

Поэтому нельзя писать, что -1 «наложил вето на релиз», не указав действие и применимое правило. Этот голос мог быть veto по изменению кода, консультативным мнением или прежним опасением. И прошедший релиз не стирает технических возражений и не доказывает безопасность, внедрение или коммерческую зрелость. Он устанавливает лишь формальный статус данного артефакта по правилу релиза.

PMC ведёт проект; Board удерживает корпоративную рамку

PMC отвечает за техническое и общественное направление проекта, релизы и надзор. Board создаёт PMC, назначает Vice Presidents/Chairs, распоряжается активами и общей политикой, получает отчёты и может действовать, когда PMC неработоспособен или не соблюдает обязательные правила. Одновременно ASF прямо говорит, что Board не задаёт техническое направление проектам.

Directors не получают автоматически committership, места в PMC или обязательного технического голоса. Чтобы технически влиять на проект, им нужно получить merit в этом проекте, как другим участникам. Members избирают Directors, но Membership сама по себе не даёт технической власти над проектами, где нет проектного merit.

Chair связывает два уровня, не смешивая их. В PMC у него обычный голос, а как officer он отвечает за отчёт и официальный roster. Внутреннее решение PMC о смене Chair всё равно требует Board resolution, чтобы стать официальным корпоративным назначением.

Квитанция полномочий для релиза

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

Это не новая процедура Apache. Это редакционная рекомендация Daniel Kade, чтобы слова «veto», «release», «PMC» и «Board» не заявляли более широкую власть, чем подтверждают документы конкретного действия.

Sources

  1. Apache Corporate Governance — PMCs
  2. Apache Voting Process
  3. Apache Project Management Committee Guide
  4. Apache Corporate Governance — Board of Directors
  5. Apache Corporate Governance — Members
  6. Lu Heng, The Multi-Stakeholder Mirage