Замечание: оригинал этого документа новее, чем перевод.

Конституция Debian

Конституция Проекта Debian (v1.9)

Версия 1.9 принята 26-го марта 2022 года.

Заменила версию 1.8, принятую 28-го января 2022 года, версию 1.7, принятую 14-го августа 2016 года, версию 1.6, принятую 13-го декабря 2015 года, версию 1.5, принятую 9-го января 2015 года, версию 1.4, принятую 7-го октября 2007 года, версию 1.3, принятую 24-го сентября 2006 года, версию 1.2, принятую 29-го октября 2003 года, версию 1.1, принятую 21-го июня 2003 года, и версию 1.0, принятую 2-го декабря 1998 года.

1. Вступление

Проект Debian — сообщество личностей, которые поставили себе целью создать свободную операционную систему.

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

2. Лица и объекты, принимающие решения

Каждое решение в Проекте принимается одним или несколькими из следующих лиц:

  1. Разработчиками, путём Общего Решения или выборов;
  2. Лидером Проекта;
  3. Техническим Комитетом и/или его Председателем;
  4. Одним Разработчиком, работающим над конкретной задачей;
  5. Делегатами, назначенными Лидером Проекта для специальных задач;
  6. Секретарём Проекта.

Большая оставшаяся часть этого документа будет описывать права этих лиц, их расположение и назначение, и процедуру принятия решения. Возможности личности или объекта могут быть подвержены пересмотру и/или ограничению со стороны других; в таком случае пересматривающее лицо или объект записывает это. В предыдущем списке лица и объекты обычно перечислены перед лицами и объектами, чьи решения они могут аннулировать или кого они назначают (помогают назначать) - но не любой, упомянутый раньше, может отклонить предложение любого, упомянутого позже.

2.1. Общие правила

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

  2. Лицо может занимать несколько постов, кроме постов Лидера Проекта, Секретаря Проекта и Председателя Технического Комитета, которые должны быть раздельны, а также Лидер не может назначить себя своим собственным Делегатом.

  3. Лицо может покинуть Проект или уйти с конкретного занимаемого поста в любой момент, просто публично это постановив.

3. Частные Разработчики

3.1. Права

Частный Разработчик может

  1. принять любое техническое или нетехническое решение, относящееся к его собственной работе;
  2. внести предложение или поддерживать начальный план Общего Решения;
  3. предложить себя в качестве кандидата в Лидеры Проекта на выборах;
  4. голосовать по Общим Решениям и на Лидерских выборах.

3.2. Распределение и Назначение

  1. Разработчики и добровольцы, которые согласны с целями Проекта постольку, поскольку они принимают в нем участие, и которые поддерживают пакет(ы) для Проекта или выполняют иную работу, которую Делегаты Лидера Проекта считают стоящей.

  2. Делегаты Лидера Проекта могут решить не признавать новых Разработчиков или исключить существующих. Если Разработчикам кажется, что Делегаты злоупотребляют властью, они, разумеется, могут отвергнуть решение путем Общего Решения - см. §4.1(3), §4.2.

3.3. Процедура

Разработчики могут принимать те решения, которые, как им кажется, верны.

4. Разработчики, путём Общего Решения или выборов

4.1. Права

Совместно Разработчики могут:

  1. Назначить или отозвать Лидера Проекта.

  2. Внести поправки в эту конституцию большинством в отношении 3:1.

  3. Выполнить или отвергнуть любое решение, санкционированные правами Лидера Проекта или Делегата.

  4. Выполнить или отвергнуть любое решение, санкционированное правами Технического Комитета большинством в отношении 2:1.

  5. Издавать, заменять и отзывать нетехнические документы и утверждения о политике.

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

    Они также могут содержать позицию по проблемам дня.

    1. Документом Фонда является документ или утверждение, крайне необходимые для миссии Проекта и её успеха.
    2. Документами Фонда являются работы, озаглавленные Социальный Контракт Debian (Debian Social Contract) и Критерии Debian по определению Свободного ПО (Debian Free Software Guidelines).
    3. Для изменения Документа Фонда необходимо набрать большинство голосов в отношении 3:1. Издание нового Документа Фонда и отзыв существующего производится путём поправок в списке Документов Фонда в этой конституции.

  6. Принимать решения о собственности, которая находится в ведении целей Debian. (см. §9.)

  7. В случае несогласия между Лидером Проекта и текущим секретарём, назначать нового секретаря.

4.2. Процедура

  1. Разработчики следуют Стандартной Процедуре Принятия Решений, см. ниже. Решение или опция бюллетеня, будучи предложенными каким-либо Разработчиком и поддерживаемы, как минимум, K другими Разработчиками, или будучи предложенными Лидером Проекта или Техническим Комитетом.

  2. Откладывание решения Лидером Проекта или его Делегатами:

    1. Если Лидер Проекта или его Делегаты, или Технический Комитет приняли решение, тогда Разработчики могут отвергнуть его, вынеся резолюцию по этому вопросу; см. §4.1(3).
    2. Если такая резолюция поддержана по меньшей мере 2K Разработчиками или если она предложена Техническим Комитетом, резолюция немедленно приостанавливает решение (в том случае, если в ней это сказано).
    3. Если изначальным решением было изменить дискуссионный период или период голосования, или резолюция гласила отвергнуть решение Технического Комитета, тогда достаточно K Разработчиков, чтобы поддержать резолюцию, чтобы можно было немедленно приостановить решение.
    4. Если решение приостановлено, немедленно проводится голосование, чтобы определить, стоит ли оставить решение до того, как по нему пройдет полное голосование, или пока отложить исполнение изначального решения. Для этого немедленного голосования не существует кворума.
    5. Если Лидер Проекта (или Делегат) снимает своё изначальное решение, голосование становится бессмысленным, и далее не продолжается.

  3. Голосования проводятся Секретарем Проекта. Голоса, подсчёт и результаты не открываются до конца голосования; после него Секретарь Проекта перечисляет все поданные голоса с достаточными подробностями, чтобы каждый мог проверить результат голосования на основе списка поданных голосов. Личностью разработчика, подавшего отдельный голос не раскрывается публично, но у разработчиков есть возможность подтвердить, что их голос включён в общий список голосов. Период голосования составляет 2 недели, но может изменяться Лидером Проекта вплоть до 1 недели.

  4. Лидер Проекта имеет решающий голос. Кворум равен 3Q. Опцией по умолчанию является Никто из вышеперечисленных.

  5. Предложения, поддержка, опции бюллетеня, запросы о голосовании и прочие формальные действия делаются путём объявления на всеми читаемом списке рассылки, указанном Делегатом Лидера Проекта; любой Разработчик может туда писать.

  6. Голоса подаются по электронной почте так, как удобно Секретарю. Он определяет для каждого голосования, могут ли голосующие изменить свои голоса.

  7. Q равно половине квадратного корня из числа текущих Разработчиков. K равно Q или 5, смотря что меньше. Q и K не обязаны быть целыми и не округляются.

5. Лидер Проекта

5.1. Права

Лидер Проекта может:

  1. Назначать Делегатов или препоручать решения Техническому Комитету.

    Лидер может определять область переходящей ответственности или принимать специфические решения и передавать их другому Разработчику или Техническому Комитету.

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

  2. Наделять правами других Разработчиков.

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

  3. Принимать решения, требующие срочного действия.

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

  4. Принимать решения, за которые никто больше не отвечает.

  5. Предлагать Общие Решения и опции бюллетеней для Общих Решений. Если они предложены Лидером Проекта, то поддержка для Общего Решения или опции бюллетеня не требуется; см. §4.2.1.

  6. Вместе с Техническим Комитетом принимать новых членов в Комитет. (см. §6.2.)

  7. Использовать решающий голос, когда Разработчики голосуют.

    Лидер Проекта также может просто участвовать в таких голосованиях.

  8. Изменять период обсуждения в голосовании Разработчиков (как сказано выше).

  9. Вести обсуждения среди Разработчиков.

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

  10. Совещаясь с разработчиками, принимать решения по поводу собственности, которая находится в ведении Debian. (См. §9.). Такие решения сообщаются членам Проекта Лидером Проекта или его Делегатом (-ами). Крупные расходы должны предлагаться и обсуждаться в списке рассылки до того, как они будут оплачены.

  11. Добавлять или удалять организации из списка доверенных организаций (см. §9.3), которые уполномочены принимать и хранить активы Debian. Оценка и обсуждение, приводящие к такому решению, происходят в электронном списке рассылки, обозначенном Лидером Проекта или его Делегатом (-ами), в который может писать любой разработчик. Минимальный период обсуждения составляет две недели до того момента, как организация может быть добавлена в список доверенных организаций.

5.2. Назначение

  1. Лидер Проекта выбирается Разработчиками.
  2. Выборы начинаются за шесть недель до того, как освободится должность Лидера, или (если раньше не начались) немедленно.
  3. За первую неделю любой Разработчик может предложить себя в кандидаты на Лидера Проекта и кратко изложить свои планы на свой срок.
  4. После этого следуют три недели, в течении которых уже никто не может выдвигаться; кандидаты должны использовать это время для проведение кампании. Если на конец периода выдвижения нет ни одного кандидата, тогда он продлевается еще на одну неделю, и это повторяется в случае необходимости.
  5. Следующие две недели — период голосования, в течение которого Разработчики отдают свои голоса.
  6. Выбирать на голосовании можно тех кандидатов, которые выдвинули себя, и не сняты с голосования, а также Никого Из Вышеперечисленных. Если на выборах побеждает Никто Из Вышеперечисленных, то процедура голосования повторяется столько раз, сколько потребуется.
  7. Решение будет принято методом, описанным в секции §A.5 Стандартной Процедуры Принятия Решений. Кворум тот же, что и для Общего Решения (§4.2) и выбором по умолчанию является Никто Из Вышеперечисленных.
  8. Лидер Проекта занимает свою должность в течение одного года после выборов.

5.3. Процедура

Лидер Проекта должен стараться принимать решения, соответствующие мнению большинства Разработчиков.

Когда это целесообразно, Лидеру Проекта следует неформально опросить взгляды Разработчиков.

Лидеру Проекта следует избегать слишком сильного акцентирования своей точки зрения, когда он принимает решения в качестве Лидера.

6. Технический Комитет

6.1. Права

Технический Комитет может:

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

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

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

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

  3. Принять решение, если об этом попросят.

    Любая личность или объект могут перенаправить свою проблему в Технический Комитет или попросить у них совета.

  4. Отклонить предложение Разработчика (необходимо большинство в отношении 3:1).

    Технический Комитет может попросить Разработчика пойти конкретным техническим путем, даже если Разработчик этого не хочет; для этого необходимо большинство в отношении 3:1. Например, Комитет может решить, что жалоба о найденной ошибке подтверждается и предложенное решение проблемы человеком, который о ней сообщил, должно быть внедрено.

  5. Дать совет.

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

  6. Вместе с Лидером Проекта, добирать новых членов и смещать уже существующих. (See §6.2.)

  7. Назначать Председателя Технического Комитета.

    Председатель выбирается из членов Комитета. Все члены автоматически выдвигаются; комитет начинает голосовать за одну неделю до того, как должность освободится (или немедленно, если раньше не начали). Члены комитета могут дружно проголосовать за одного из членов комитета, включая его самого; выбора по умолчанию не существует. Голосование закрывается, когда все проголосовали или по окончанию периода голосования. Решение принимается методом, описанным в разделе §A.5 Стандартной Процедуры Принятия Решений. Решающего голоса нет. Если имеется несколько вариантов без проигрышей в множестве Шварца, установленных в конце §A.5.8, то победитель случайно выбирается из этих вариантов способом, выбранным Секретарём Проекта.

  8. Председатель может вместе с Секретарем заменять Лидера

    Как подробнее описано в §7.1(2), Председатель Технического Комитета и Секретарь Проекта могут вместе заменять Лидера, когда его нет.

6.2. Распределение

  1. Технический комитет может состоять из не более, чем 8 Разработчиков, и должен состоять как минимум из 4 членов.

  2. Когда в Техническом Комитете меньше 8 членов, он может рекомендовать новых кандидатов Лидеру Проекта, который решает (индивидуально), принять их или нет.

  3. Когда в Техническом Комитете 5 человек или меньше, он может принимать новых членов до тех пор, пока их число не достигнет 6.

  4. Если на протяжении недели было 5 членов или меньше, то Лидер Проекта может с интервалом в одну неделю назначать новых членов до тех пор, пока их число не достигнет 6.

  5. Разработчик не может быть (пере-) назначен в состав Технического Комитета, если он являлся членом Комитета менее 12 месяцев назад.

  6. В случае обоюдного согласия Технический Комитет и Лидер Проекта могут сместить или заменить существующего члена Технического Комитета.

  7. Ограничение срока:

    1. 1-го января каждого года срок любого члена Комитета, который являлся членом Комитета более 42 месяцев (3.5 лет) и который является одним из двух наиболее старших членов Комитета, ограничивается 31-ым декабря этого года.

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

6.3. Процедура

  1. Процесс принятия решения.

    Технический Комитет использует следующий процесс для подготовки решения для голосования.

    1. Любой член Технического Комитета может предложить решение. Это предполагает начальный бюллетень с двуями опциями, второй опцией является опция по умолчанию, Ничто из вышеперечисленного. Предлагающий решение становится тем, кто предлагает опцию бюллетеня.
    2. Любой член Технического Комитета может предложить дополнительные опции бюллетеня, изменить или аннулировать предложенную им опцию бюллетеня.
    3. Если все опции бюллетеня за исключением опции по умолчанию аннулированы, то процесс прекращается.
    4. Любой член Технического Комитета может объявить голосование по текущему бюллетеню. Это голосование начинается немедленно, но если любой другой член Технического Комитета высказывает возражение по отношению к объявлению о голосовании до завершения голосования, голосование отменяется и не имеет силы.
    5. По прошествии двух недель с изначального предложения бюллетень закрывается для каких-либо изменений, а голосование начинается автоматически. Это голосование не может быть отменено.
    6. Если голосование отменено в соответствии с §6.3.1.4 позднее, чем через 13 дней после изначального предложения решения, то голосование, определённое в §6.3.1.5, начинается через 24 часа после времени отмены. Во время 24-х часового периода никто не может объявить о голосовании, но члены Технического Комитета могут вносить изменения в бюллетень в соответствии с §6.3.1.2.

  2. Детали, относящиеся к голосованию

    Результаты голосования определяются с помощью механизма, описанного в §A.5. Период голосования продолжается одну неделю или до тех пор, пока результат не перестанет быть неопределённым пр допущении, что члены не изменят свои голоса, в зависимости от того, какой период короче. Члены могут изменять свои голоса до окончания периода голосования. Кворум равен двум. У Председателя есть решающий голос. Вариантом по умолчанию является Ничто из вышеперечисленного.

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

  3. Публичные обсуждения и принятие решений.

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

  4. Конфиденциальность назначений.

    Технический Комитет могут проводить закрытые обсуждения назначений в Комитет использую личную почту, закрытый список рассылки, или иной способ. Но голосования по назначениям должны быть открытыми.

  5. Отсутствие подробного описания работы по планированию.

    Технический Комитет не участвует в планировании новых предложений и линий поведения. Эта работу людям следует выполнять по отдельности, или вместе, и обсуждать в обыкновенных форумах по технической политике и планированию.

    Технический Комитет ограничивает себя от участия в выборе или принятии компромиссов между различными решениями, которые были предложены и разумно и полно обсуждены.

    Отдельные члены Технического Комитета могут, конечно, принимать любую сторону в разработке линии поведения или планирования в своих интересах.

  6. Технический Комитет принимает решения только в крайнем случае.

    Технический Комитет не принимает технических решений пока попытки принять его согласованно не будут сделаны и не провалятся, если только просьба о принятии решения не придёт от лица, ответственного за это решение.

  7. Предложение Общего Решения.

    Когда Технический Комитет предлагает Общее Решение или опцию бюллетеня для Общего Решения в соответствии с §4.2.1, он может делегировать (через решение или другими допустимых Техническим Комитетом способами) право аннулировать, дополнить или внести небольшие изменения в опцию бюллетеня одному из своих членов. Если это не было принято, то эти решения должны быть приняты путём решения Технического Комитета.

7. Секретарь Проекта

7.1. Права

Секретарь:

  1. Проводит голосования среди Разработчиков, и определяет количество и личности Разработчиков, когда бы это не потребовалось по конституции.

  2. Может вместе с Председателем Технического Комитета заменять Лидера.

    Если у Проекта нет Лидера, тогда Председатель Технического Комитета и Секретарь Проекта могут объединенным соглашением принимать решения, если сочтут это необходимым.

  3. Выносит решения по любому вопросу, касающемуся толкования конституции.

  4. Может передавать свои полномочия частично или полностью другому лицу, или аннулировать это перепоручение в любой момент.

7.2. Назначение

Секретарь Проекта назначается Лидером Проекта и текущим Секретарем Проекта.

Если Лидер Проекта и текущий Секретарь Проекта не могут прийти к согласию о новом назначении, они должны попросить разработчиков назначить Секретаря путём Общего Решения.

Если у Проекта нет Секретаря или текущий Секретарь недоступен и не передал полномочия по решению, тогда решение может быть принято или поручено Председателю Технического Комитета, как Действительному Секретарю.

Срок нахождения на должности Секретаря Проекта — 1 год, по истечении которого этот или новый Секретарь должен быть (пере)назначен.

7.3. Процедура

Секретарю Проекта следует принимать решения, которые справедливы и разумны, и предпочтительно соответствующие мнению большинства Разработчиков.

Когда Председатель Технического Комитета и Секретарь Проекта действуют вместе, заменяя отсутствующего Лидера Проекта, им следует принимать решения только в случае крайней необходимости и только соответствующее мнению большинства Разработчиков.

8. Делегаты Лидера Проекта

8.1. Права

Делегаты Лидера Проекта:

  1. обладают правами, переданными им Лидером Проекта;
  2. могут принимать конкретные решения, которые Лидер не может принять напрямую, включая утверждение или исключение Разработчиков или назначение людей Разработчиками, которые не сопровождают пакетов. Это сделано во избежание сосредоточения власти, особенно той, которая относится к членству в рядах Разработчиков, в руках Лидера Проекта.

8.2. Назначение

Делегаты назначаются Лидером Проекта и могут быть смещены им на его усмотрение. Лидер Проекта не может ни выступать в роли Делегата при принятии определённого решения Делегатом, ни отменить решение, уже принятое Делегатом.

8.3. Процедура

Делегаты могут принимать решения так, как они считают верным, но им следует стараться внедрять хорошие технические решения и/или придерживаться общественного мнения.

9. Имущество Debian, находящееся в доверительном управлении

Согласно большинству юрисдикций по всему миру, Проект Debian не может напрямую владеть фондами или другой собственностью. Следовательно, собственность должна принадлежать некоторому числу организаций, как это обозначено в §9.2.

Традиционно, SPI была единственной организацией, которой было доверено хранить собственность и деньги Проекта Debian. SPI была создана в США для того, чтобы хранить там деньги.

SPI и Debian — отдельные организации, у которых есть несколько общих целей. Debian благодарен за юридическую поддержку, предложенную SPI.

9.1. Отношения с ассоциированными организациями

  1. Разработчики Debian не становятся агентами или служащими организаций, осуществляющих доверительное хранение активов для Debian, или друг друга, или людей, имеющих отношение к Проекту Debian, исключительно в силу того, что они являются разработчиками Debian. Человек, действующий как Разработчик, делает это как индивид, от своего собственного лица. Такие организации могут, по своему собственному согласию, устанавливать отношения с индивидами, являющимися также разработчиками Debian.

  2. Разработчики Debian не являются агентами или служащими SPI, или друг друга или людей, имеющих отношение к Проекту Debian. Человек, действующий как Разработчик, делает это как отдельная личность в своих собственных интересах.

9.2. Полномочия

  1. Организация, осуществляющая для Debian доверительное хранение активов, не имеет полномочий относительно технических или нетехнических решений Debian за исключением того, что ни одно решение Debian касательно какого-либо имущества, хранящегося этой организацией, не потребует её действовать за пределами её юридических полномочий.

  2. Debian не имеет полномочий над организацией, осуществляющей для Debian доверительное хранение активов, кроме тех, которые касаются использования имущества, находящегося в доверительном хранении для Debian.

9.3. Доверенные организации

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

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

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

A. Стандартная Процедура Принятия Решений

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

A.0. Предложение

  1. Формальная процедура начинается с того момента, как начальный план решения предложен и поддержан, как это определено §4.2.1.
  2. Это предварительное решение становится опцией бюллетеня в начальном бюллетене из двух опций, второй опцией является опция по умолчанию, а предлагающий изначальное решение становится предлагающим эту опцию бюллетеня.

.

A.1. Обсуждение и Поправка

  1. Период обсуждения начинается, когда предлагается и получает поддержку изначальное решение. Минимальный период обсуждения составляет 2 недели. Максимальный период обсуждения составляет 3 недели.
  2. Новая опция бюллетеня может быть предложена и поддержана в соответствии с требованиями для нового решения.
  3. Предлагающий опцию бюллетеня может дополнить эту опцию при условии, что на момент предложения дополнения никто из поддержавших эту опцию не выражает своё несогласие с дополнением в течение 24 часов. Если кто-либо из них выражает несогласие, то опция бюллетеня остаётся без изменений.
  4. Дополнение другой опции бюллетеня или изменение через дополнение опции бюллетеня изменяет время окончения, продляя его на одну неделю с момента дополнения или изменения, если только это изменение не сделает общую продолжительность обсуждения короче минимального периода или длиннее максимального периода обсуждения. В последнем случае продолжительность периода обсуждения устанавливается равно максимальному периоду обсуждения.
  5. Предложивший опцию бюллетеня может внести небольшие изменения в эту опцию (например, типографские исправления, исправления несогласованности или другие изменения, которые не изменяют значения), при условии, что ни один Разработчик не возражает по этому поводу в течении 24 часов. В этом случае продолжительность периода обсуждения не изменяется. Если же какой-то Разработчик возражает против изменений, то изменения должны быть сделаны в виде дополнения в соответствии с §A.1.3.
  6. Лидер Проекта может в любой момент в процессе обсуждения увеличить или уменьшить минимальный и максимальный период обсуждения на продолжительность вплоть до 1 недели по отношению к изначальным значениями в соответствии с §A.1.1 за исключением того, чтобы период обсуждения завершился в не более, чем через 48 часов от того момента, когда делается это изменение. Продолжительность периода обсуждения в этом случае пересчитывается так, как если бы новые минимальная и максимальная продолжительности имели место в ходе предыдущих изменений бюллетеня в соответствии с §A.1.1 и §A.1.4.
  7. Опция по умолчанию не имеет предлагающего или поддерживающего, не может быть дополнена или аннулирована.

A.2. Аннулирование опций бюллетеня

  1. Предложивший опцию бюллетеня может её аннулировать. Если он это делает, то новые предлагающие могут занять его место и сохранить данную опцию бюллетеня, в этом случае первый, кто это сделает, становится новым предлагающим, а остальные становятся поддерживающими, если они уже не являются поддерживающими. Любой новый предлагающий или поддерживающие должны удовлетворять требованиям для предложения или поддержки нового решения.
  2. Поддерживающий опцию бюллетеня может отказаться от поддержки.
  3. Если аннулирование предлагающим и/или поддерживающими означает, что опцию бюллетеня не имеет предлагающего или не имеет достаточное количество поддерживающих, чтобы удовлетворять требованиям для нового решения, и по прошествии 24 часов это не будет исправлено другим предлагающим и/или поддерживающими, опция удаляется из чернового бюллетеня. Это не изменяет продолжительность периода обсуждения.
  4. Если все опции бюллетеня за исключением опции по умолчанию аннулированы, то решение отменяется, а голосование по нему не проводится.

A.3. Просьба о голосовании

  1. После завершения периода обсуждения Секретарь Проекта публикует бюллетень и просьбу о голосовании. Секретарь Проекта может сделать это немедленно после завершения периода обсуждения и должен сделать это не позже семи дней после завершения периода обсуждения.
  2. Секретарь Проекта определяет порядок опций бюллетеня и формулировки их резюме, используемые для бюллетеня. Секретарь Проекта может попросить предложивших опции бюллетеня подготовить черновые варианты резюме и может изменить их с целью обеспечения их ясности по своему усмотрению.
  3. Небольшие изменения опций бюллетеня в соответствии с §A.1.5 могут быть сделаны только в том случае, если до конца периода обсуждения остётся не менее 24 часов, или если Секретарь Проекта согласен с тем, что изменение не меняет значения опции бюллетеня и (если оно изменяет) обосновывает задержку голосования. Секретарь Проекта выделяет 24 часа для возражений после любого такого изменения до того, как он отправяет просьбу о голосовании.
  4. Никакие новые опции бюллетеня не могут быть предложены, никакие опции бюллетеня не могут быть дополнены, а предложившие их или поддержавшие их не могут аннулировать свои действия в случае, если от периода обсуждения остаётся менее 24 часов, если только это действие не продляет период обсуждения в соответствии в §A.1.4 по меньшей мере на 24 дополнительных часа.
  5. Действия по сохранению существующего бюллетеня могут быть произведены в течение последних 24 часов периода обсуждения, а именно: спонсор возражает дополнению в соответствии с §A.1.3, Разработчик возражает небольшому изменению в соотвтствии с §A.1.5, поддержка в виде предложившего для существующей опции бюллетеня, предложивший которую отказался от неё в соответствии с §A.2.1, или поддержка существующей опции бюллетеня, имеющей меньшее количество поддержавших, чем требуется, из-за отказа от поддержки в соответствии с §A.2.2.
  6. Секретарь Проекта может сделать исключение к §A.3.4 и принять изменения в бюллетень после того времени, когда они разрешены, при условии, что это сделано не менее, чем за 24 часа до отправки просьбы о голосовании. Все другие требования сделать изменения в бюллетене должны быть удовлетворены. Ожидается, что это является редкой практикой и должно делаться только в том случае, если Секретарь Проекта убеждён, что если данное изменение не будет внесено, то пострадают интересы Проекта.

A.4. Процедура голосования

  1. Для опций, не требующих явного квалифицированного большинства, необходимо большинство голосов 1:1. Для опций по умолчанию квалифицированное большинство не требуется.
  2. Голоса подсчитываются в соответствии с правилами, изложенными в §A.5.
  3. В случаях сомнения отвечать на вопрос об образе действий следует Секретарю Проекта.

A.6. Подсчет всех голосов

  1. Каждый бюллетень голосующего устанавливает оценку варианта выбора. Не все варианты обязаны быть оценены. Оценённые варианты считаются более предпочтительными, чем все неоценённые варианты. Голосующие могут оценить варианты одинаково. Неоценённые варианты считаются оценёнными одинаково с другими неоценёнными вариантами. Детали о том, как бюллетени могут быть заполнены, будут включены в Центре Голосований.
  2. Если бюллетень имеет требование кворума R, любые варианты, отличные от варианта по умолчанию, которые не получили минимум R голосов, чем вариант выше варианта по умолчанию, отбрасываются из рассмотрения.
  3. Любой выбор (не по умолчанию), который не аннулирует выбор по умолчанию своим требованием большинства, отбрасывается из рассмотрения.
    1. Даны два варианта выбора A и B, V(A,B) — это количество голосующих, которые предпочли выбор A выбору B.
    2. Вариант выбора A аннулирует выбор по умолчанию D требованием большинства N, если V(A,D) больше или равно N * V(D,A), а V(A,D) строго больше V(D,A).
    3. Если сверх-большинство S:1 необходимо для выбора A, его большинство выбора является S; иначе, его большинство выбора является 1.
  4. Из списка оставшихся после отбрасываний вариантов, мы составляем список парных аннулирований.
    1. Вариант выбора A аннулирует вариант B, если V(A,B) строго больше, чем V(B,A).
  5. Из списка [оставшихся после отбрасываний вариантов] парных аннулирований, мы составляем набор переходных аннулирований.
    1. Вариант выбора A переходно аннулирует вариант C, если A аннулирует C, или если существует некоторый другой вариант B, причём A аннулирует B И B переходно аннулирует C.
  6. Из набора переходных аннулирований мы строим набор Шварца (Schwartz set).
    1. Вариант выбора A входит в набор Шварца, если для всех вариантов B или A переходно аннулирует B, или B не аннулирует переходно A.
  7. Если существуют аннулирования между вариантами выбора в наборе Шварца, мы откидываем слабые аннулирования из списка парных аннулирований, и возвращаемся к шагу 5.
    1. Аннулирование (A,X) слабее, чем аннулирование (B,Y), если V(A,X) меньше, чем V(B,Y). Также, (A,X) слабее, чем (B,Y) если V(A,X) равно V(B,Y) и V(X,A) больше, чем V(Y,B).
    2. Слабое аннулирование — это аннулирование, которое не имеет других, более слабых аннулирований. Возможно существование более одного такого аннулирования.
  8. Если не существует ни одного аннулирования в наборе Шварца, тогда победитель выбирается из вариантов в наборе Шварца. Если есть только один такой вариант, он и есть победитель. Если вариантов много, избиратель с решающим голосом выбирает, какой из этих вариантов победил.

Замечание: Варианты, которые голосующие оценили выше варианта по умолчанию, являются вариантами, которые они нашли приемлемыми. Варианты, оценённые ниже варианта по умолчанию, являются вариантами, которые они нашли неприемлемыми.

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

B. Использование языка и оформления

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