Историческая версия 1.0 Конституции Debian

Историческая версия Конституции Проекта Debian (v1.0)

Версия 1.0 принята 2-го декабря 1998 года.

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

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

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

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

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

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

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

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

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

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

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

3.1. Права

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

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

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

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

3.3. Процедура

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

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

4.1. Права

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

Назначить или отозвать Лидера Проекта.
Внести поправки в эту конституцию большинством в отношении 3:1.
Отвергнуть любое решение Лидера Проекта или Делегата.
Отвергнуть любое решение Технического Комитета большинством в отношении 2:1.
Издавать нетехнические документы и утверждения о политике.

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

Они также могут содержать позиционные утверждения об изданиях дня.
Вместе с Лидером Проекта и SPI, принимать решения о собственности, которая находится под опекой целей Debian. (см. §9.1.)

4.2. Процедура

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

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

5.1. Права

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

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

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

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

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

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

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

Лидер Проекта должен пытаться участвовать в обсуждениях среди Разработчиков таким образом, чтобы обсуждение сводилось к наиболее важной на данный момент теме. Лидер Проекта не должен использовать свое лидерство чтобы продвигать свои собственные взгляды.
Вместе со SPI, принимать решения, относящиеся к собственности, которая находится под опекой для целей Debian. (см. §9.1.)

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

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

5.3. Процедура

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

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

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

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

6.1. Права

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

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

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

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

Любая личность или объект могут перенаправить свою проблему в Технический Комитет или попросить у них совета.
Отклонить предложение Разработчика (необходимо большинство в отношении 3:1).

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

Технический Комитет может делать формальные заявления о своей точке зрения по любому вопросу. Отдельные члены могут, конечно, делать неформальные утверждения о своих взглядах и близких им взглядах комитета.
Вместе с Лидером Проекта, добирать новых членов и смещать уже существующих. (See §6.2.)
Назначать Председателя Технического Комитета.

Председатель выбирается из членов Комитета. Все члены автоматически выдвигаются; комитет начинает голосовать за одну неделю до того, как должность освободится (или немедленно, если раньше не начали). Члены комитета могут дружно проголосовать за одного из членов комитета, включая себя; не существует возможности не выбрать Никого Из Вышеперечисленных. Голосование закрывается, когда все проголосовали или когда в результатах уже можно не сомневаться. Решение принимается путем Подсчета Всех Голосов.
Председатель может вместе с Секретарем заменять Лидера

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

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

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

6.3. Процедура

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

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

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

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

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

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

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

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

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

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

7.1. Права

Секретарь:

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

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

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

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

Если Лидер Проекта и текущий Секретарь Проекта не могут прийти к согласию о новом назначении, они должны попросить совет SPI (см. §9.1.) назначить Секретаря.

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

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

7.3. Процедура

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

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

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

8.1. Права

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

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

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

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

8.3. Процедура

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

9. Software in the Public Interest (Программное Обеспечение в Общественных Интересах)

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

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

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

9.2. Управление собственностью в целях, относящихся к Debian

Так как у Debian нет возможности содержать деньги или собственность, все пожертвования на Проект Debian должны делаться в SPI, которое управляет такими делами.

SPI создало следующие соглашения:

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

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

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

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

Формальная процедура начинается с того момента, как начальный план решения предложен и поддержан, как это требуется.

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

После того, как его предложили, решение может быть обсуждено. Поправки могут быть внесены формально, будучи предложены и поддержаны в соответствии с потребностями нового решения, или напрямую предложившим изначальное решение.
Формальная поправка может быть принята тем, кто предложил решение, и тогда она немедленно вносится в начальный план решения.
Если формальную поправку не приняли, или один из тех, кто поддерживает решение не согласен с принятием автором решения этой поправки, то поправка остается поправкой и будет поставлена на голосование.
Если поправка, принятая изначальным автором решения не нравится другим, они могут предложить другую поправку для аннулирования более раннего изменения (ей опять-таки придется отвечать требованиям автора и группы поддержки.)
Автор резолюции может предложить изменения в формулировке поправки; это имеет эффект только если автор поправки согласен. В таком случае на голосование будет поставлена измененная поправка.
Автор решения может исправлять в нем мелкие ошибки (например, опечатки и несоответствия) или вносить изменения, которые не меняют смысла, если никто не возразит в течение 24 часов. В этом случае минимальный период обсуждения не начинается сначала.

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

Автор или поддерживающий движения или поправки может попросить поставить их на голосование, если период минимального обсуждения (если таковой есть) истек.
Автор или поддерживающий движения может попросить поставить на голосование любую поправку отдельно или все вместе; Автор или поддерживающий поправки может попросить поставить на голосование только свою или родственную ей поправку.
Человек, просящий о голосовании, поясняет как он понимает формулировку решения и все относящиеся к нему поправки, и, как следствие, какую форму должно принять голосование. Но все равно, окончательное решение о форме голосования(ий) принимает Секретарь - см. 7.1(1), 7.1(3) and A.3(6).
Минимальный период обсуждения отсчитывается с того момента, как последняя формальная поправка была принята, или как последняя, относящаяся к формальной поправка была принята, если за поправку уже голосовали, или как все решение было предложено, если никаких поправок не было предложено и принято.

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

За каждый независимый ряд родственных поправок голосуют в отдельном голосовании. Каждое такое голосование в качестве выбора имеет всевозможные комбинации поправок и вариантов, а также Дальнейшее Обсуждение как вариант. Если выигрывает Дальнейшее Обсуждение, тогда все решение сводится к началу периода обсуждения. Для поправки кворума не нужно.
Когда окончательная форма решения определена, устраивается последнее голосование, в котором есть три варианта: Да, Нет и Дальнейшее Обсуждение. Если выигрывает Дальнейшее Обсуждение, тогда все решение сводится к началу периода обсуждения.
Тот, кто проводит выборы (если таковой есть) или голосующие (если голосование проводится путем публичных заявлений) могут организоваться так, чтобы различные выборы происходили одновременно, даже (например) с использованием одного сообщения об отданных голосах. Если одновременно проходят голосование(я) по поправке и окончательное голосование сочетаются таким способом, тогда у голосующего должна быть возможность голосовать иначе на окончательном голосовании для каждой из возможных форм окончательного плана решения.
Голоса могут быть распределены во время периода голосования, как отмечено везде. В тех случаях, когда голосование заканчивается вследствие отсутствия сомнений в результатах выборов, возможность голосующих перераспределить свои голоса не рассматривается.
Результат подсчитывается в соответствии с Подсчетом Всех Голосов. Если необходим кворум, то по умолчанию ведется Дальнейшее Обсуждение.
В случаях сомнения отвечать на вопрос об образе действий следует Секретарю Проекта (например, считать данную поправку независимой или нет).

A.4. Снятие решений или непринятые поправки

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

Поддерживающий решение или поправку (если она не была принята) может ретироваться.

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

A.5. Истечение срока

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

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

Он используется для определения победителя из списка вариантов. Каждый бюллетень дает распределение вариантов в порядке их предпочтения голосующим (Распределение не должно быть полным.)
Говорят, что вариант A Предпочтительнее, чем B, если количество избирателей, предпочитающих вариант A варианту B строго больше количества тех, кто предпочитает вариант B варианту A.
Все варианты, которым Предпочитают минимум один другой вариант, отбрасываются и ссылки на них в бюллетенях игнорируются.
Если есть вариант, который Предпочтительней всех других, то он побеждает.
Если после этого все еще остается более одного варианта, то применяется голосование Один Передаваемый Голос, чтобы выбрать победителя среди оставшихся:
- Подсчитывается количество первых мест для каждого варианта, и если у какого-то варианта их больше половины, то он победитель.
- Иначе вариант с наименьшим количеством первых мест устраняется и его голоса перераспределяются в соответствии со вторыми местами.
- Эта процедура устранения повторяется, передвигая бюллетени ко второму месту, третьему, и т.д. столько, сколько нужно, пока один из вариантов не наберет больше половины первых мест.
В случае ничьей все определяет избиратель с правом решающего голоса. Решающий голос не считается нормальным правом голоса; но все равно у этого избирателя обычно есть и нормальное право голоса.
Если требуется абсолютное большинство, то число голосов За в окончательном голосовании уменьшается на соответствующий множитель. Собственно говоря, для абсолютного большинства в отношении F:A, число голосов, предпочитающих вариант За варианту X (при определении того, вариант ли За предпочтительнее варианта X или вариант X предпочтительнее варианта За) или число голосов, у которых первое (оставшееся) место занимает За (при проведении сравнений способом Одного Передаваемого Голоса для победителей и проигравших) умножается на множитель A/F перед тем, как сравнение завершено. голоса распределились 2:1 означает, что За проголосовало вдвое больше людей, чем против; неучастие в голосовании не считается.
Если необходим кворум, то должно быть как минимум столько голосов, которые предпочитают выигрышный вариант варианту по умолчанию. Если их столько не набралось, побеждает вариант по умолчанию. Для голосований, требующих абсолютного большинства, фактическое количество голосов За считается в том случае, если достигнут кворум.

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

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

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