diff options
author | Sebul <sebuls@gmail.com> | 2022-02-01 15:59:54 +0900 |
---|---|---|
committer | Sebul <sebuls@gmail.com> | 2022-02-01 16:03:23 +0900 |
commit | 0798060868dcdd866b8a4785aecacbe1f5329d4f (patch) | |
tree | d456da7fcf5340669b62af14d1229f4d7b58c21b /korean/devel | |
parent | fb5c6dfbc0362b68aecdd88c20025bf85ecea715 (diff) |
ko. constitution to constitution.1.7
Diffstat (limited to 'korean/devel')
-rw-r--r-- | korean/devel/constitution.1.7.wml | 983 |
1 files changed, 983 insertions, 0 deletions
diff --git a/korean/devel/constitution.1.7.wml b/korean/devel/constitution.1.7.wml new file mode 100644 index 00000000000..ca33ddb56c8 --- /dev/null +++ b/korean/devel/constitution.1.7.wml @@ -0,0 +1,983 @@ +#use wml::debian::template title="데비안 헌법" BARETITLE="true" +#use wml::debian::toc +#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="Sebul" mindelta="-1" +# 주의: 불완전한 번역. 번역을 마친 다음 위의 'mindelta="-1"'을 지우십시오. + +<h1>데비안 프로젝트를 위한 헌법 (v1.7)</h1> + +<p>버전 1.7은 2016.8.14에 비준되었습니다. +<a href="constitution.1.6">버전 1.6</a> 2015.12.13 비준, +<a href="constitution.1.5">버전 1.5</a> 2015.1.9 비준, +<a href="constitution.1.4">버전 1.4</a> 2007.10.7 비준, +<a href="constitution.1.3">버전 1.3</a> 2006.9.24 비준, +<a href="constitution.1.2">버전 1.2</a> 2003.10.29 비준 +및 +<a href="constitution.1.1">버전 1.1</a> 2003.6.21 비준을 대체하며, +이는 <a href="constitution.1.0">버전 1.0</a>1998.12.2 비준을 대체합니다.</p> + +<toc-display /> + +<toc-add-entry name="item-1">1. 소개</toc-add-entry> + +<p><cite>데비안 프로젝트는 자유 운영 체제를 창조하는 공통 원인을 만든 개인의 모임입니다. +</cite></p> + +<p>이 문서는 프로젝트에서 공식적 의사결정을 위한 조직 구조를 설명합니다. +프로젝트의 목표 또는 그것을 어떻게 성취하는지, 또는 의사 결정 절차에 +직접 관련된 정책을 제외한 어떤 정책도 포함하지 않습니다. +</p> + +<toc-add-entry name="item-2">2. 의사결정 기구 및 개인</toc-add-entry> + +<p>프로젝트의 각 결정은 아래의 하나 이상에 의해 만들어진다:</p> + +<ol> + <li>개발자, 일반 결의 또는 선거에 의해;</li> + <li>프로젝트 리더;</li> + <li>기술위원회 그리고/또는 그 의장;</li> + <li>특정 임무를 하는 개인 개발자;</li> + <li>특정 임무를 위해 프로젝트 리더에 의해 지정된 대표;</li> + <li>프로젝트 비서.</li> +</ol> + +<p>이 문서의 나머지의 대부분은 신체 능력, 구성 및 약속, 의사 결정 절차 개요를 설명합니다. +사람 또는 신체의 힘은 다른 사람들의 검토 그리고/또는 제한을 받을 수 있습니다. +이 경우 검토 기관 또는 개인의 등장이 여기 서술됩니다. +<cite>위 목록에서, 사람 또는 단체는 자신이 결정을 기각하거나 그들이 지적을 (도울) 사람들 또는 단체 앞에 대개 열거됩니다 - +그러나 이전에 열거된 모두가 나중에 열거된 모두를 무시할 수는 없습니다. +</cite></p> + +<h3>2.1. 일반 규칙</h3> + +<ol> + <li> + <p>이 헌법의 아무것도 이 프로젝트에서 일하는 누구에게도 의무를 부과하지 않습니다. +위임되거나 할당된 사람은 원치 않으면 그 일을 할 필요가 없습니다. +그러나, 그들사이에서 적절하게 만들어진 규칙과 결정에 반대하는 일을 +적극적으로 하면 안 됩니다. +</p> + </li> + + <li> + <p>프로젝트 리더, 프로젝트 비서와 기술위원회 의장은 다르고, +리더가 그들 자신의 대의원으로 임명할 수 없을을 제외하고, +여러 게시물을 가지고 있을 수 있습니다. +</p> + </li> + + <li> + <p>공개적으로 말함으로써, 프로젝트를 떠나거나 그들이 가진 특정 게시물에서 +사임할 수 있습니다. +</p> + </li> +</ol> + +<toc-add-entry name="item-3">3. 개인 개발자</toc-add-entry> + +<h3>3.1. 권한</h3> + +<p>개인 개발자가 할 수도 있는 것</p> + +<ol> + <li>그들 자신 업무 관련 기술적 또는 비기술적 결정;</li> + <li>일반 의한 초안 제안 또는 후원;</li> + <li>그들 자신을 프로젝트 리더 후보자로 선거에서 제안;</li> + <li>일반 결의 및 리더쉽 선거에 투표.</li> +</ol> + +<h3>3.2. 구성 및 약속</h3> + +<ol> + <li> + <p>개발자는 그들이 참여한 프로젝트의 목적을 진전시키는데 동의하는 자원봉사자이며, +패키지를 프로젝트 패키지를 유지하거나 프로젝트 리더의 대표가 가치있다고 생각하는 +일을 합니다. +</p> + </li> + + <li> + <p>프로젝트 리더의 대표는 새 개발자를 인정하지 않거나, 기존 개발자를 쫓아낼 수 있습니다. +<cite>개발자가 느끼기에 대표가 그의 권력을 잘못 사용하다면 물론 일반 결의를 통해 +결정을 무시할 수 있습니다 - §4.1(3), §4.2를 보십시오</cite></p> + </li> +</ol> + +<h3>3.3. 절차</h3> + +<p>개발자는 그들이 적절하다고 보면 이런 결정을 할 수 있습니다. +</p> + +<toc-add-entry name="item-4">4. 일반 결의 또느 선거에 의한 개발자</toc-add-entry> + +<h3>4.1. 권한</h3> + +<p>함께, 개발자는 할 수 있습니다:</p> + +<ol> + <li> + <p>프로젝트 리더를 선출하거나 소환.</p> + </li> + + <li> + <p>3대1 다수결에 동의하면, 헌법을 개정. +</p> + </li> + + <li> + <p>프로젝트 리더 또는 대의원의 권한으로 승인된 결정을 하거나 무시하기. +</p> + </li> + + <li> + <p>2 : 1 다수결에 동의한다면, 기술위원회의 권한에 의해 승인된 결정을 확인하거나 무시. +</p> + </li> + + <li> + <p>비 기술 정책 문서와 진술을 발행, 대체 및 철회 +</p> + + <p>이것을 프로젝트의 목표, 다른 자유소프트웨어와의 관계, 자유 소프트웨어 라이슨스 조항 같은 +비 기술적 데비안 소프트웨어가 만나는 정치를 포함 +</p> + + <p>그들은 오늘의 이슈에 관한 입장 진술을 포함할 수 있음 +</p> + + <ol style="list-style: decimal;"> + <li>A Foundation Document is a document or statement regarded as + critical to the Project's mission and purposes.</li> + <li>The Foundation Documents are the works entitled <q>Debian + Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> + <li>A Foundation Document requires a 3:1 majority for its + supersession. New Foundation Documents are issued and + existing ones withdrawn by amending the list of Foundation + Documents in this constitution.</li> + </ol> + + </li> + + <li> + <p>Make decisions about property held in trust for purposes + related to Debian. (See §9.).</p> + </li> + + <li> + <p>In case of a disagreement between the project leader and + the incumbent secretary, appoint a new secretary.</p> + </li> +</ol> + +<h3>4.2. Procedure</h3> + +<ol> + <li> + <p>The Developers follow the Standard Resolution Procedure, below. + A resolution or amendment is introduced if proposed by any + Developer and sponsored by at least K other Developers, or if + proposed by the Project Leader or the Technical Committee.</p> + </li> + + <li> + <p>Delaying a decision by the Project Leader or their Delegate:</p> + + <ol> + <li>If the Project Leader or their Delegate, or the Technical + Committee, has made a decision, then Developers can override them + by passing a resolution to do so; see §4.1(3).</li> + + <li>If such a resolution is sponsored by at least 2K Developers, + or if it is proposed by the Technical Committee, the resolution + puts the decision immediately on hold (provided that resolution + itself says so).</li> + + <li>If the original decision was to change a discussion period or + a voting period, or the resolution is to override the Technical + Committee, then only K Developers need to sponsor the resolution + to be able to put the decision immediately on hold.</li> + + <li>If the decision is put on hold, an immediate vote is held to + determine whether the decision will stand until the full vote on + the decision is made or whether the implementation of the + original decision will be delayed until then. There is no + quorum for this immediate procedural vote.</li> + + <li>If the Project Leader (or the Delegate) withdraws the + original decision, the vote becomes moot, and is no longer + conducted.</li> + </ol> + </li> + + <li> + <p> + Votes are taken by the Project Secretary. Votes, tallies, and + results are not revealed during the voting period; after the + vote the Project Secretary lists all the votes cast. The voting + period is 2 weeks, but may be varied by up to 1 week by the + Project Leader. + </p> + </li> + + <li> + <p>The minimum discussion period is 2 weeks, but may be varied by + up to 1 week by the Project Leader. The Project Leader has a + casting vote. There is a quorum of 3Q.</p> + </li> + + <li> + <p>Proposals, sponsors, amendments, calls for votes and other + formal actions are made by announcement on a publicly-readable + electronic mailing list designated by the Project Leader's + Delegate(s); any Developer may post there.</p> + </li> + + <li> + <p>Votes are cast by email in a manner suitable to the Secretary. + The Secretary determines for each poll whether voters can change + their votes.</p> + </li> + + <li> + <p>Q is half of the square root of the number of current + Developers. K is Q or 5, whichever is the smaller. Q and K need not + be integers and are not rounded.</p> + </li> +</ol> + +<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> + +<h3>5.1. Powers</h3> + +<p>The <a href="leader">Project Leader</a> may:</p> + +<ol> + <li> + <p>Appoint Delegates or delegate decisions to the Technical + Committee.</p> + + <p>The Leader may define an area of ongoing responsibility or a + specific decision and hand it over to another Developer or to the + Technical Committee.</p> + + <p>Once a particular decision has been delegated and made the + Project Leader may not withdraw that delegation; however, they may + withdraw an ongoing delegation of particular area of + responsibility.</p> + </li> + + <li> + <p>Lend authority to other Developers.</p> + + <p>The Project Leader may make statements of support for points of + view or for other members of the project, when asked or otherwise; + these statements have force if and only if the Leader would be + empowered to make the decision in question.</p> + </li> + + <li> + <p>Make any decision which requires urgent action.</p> + + <p>This does not apply to decisions which have only become + gradually urgent through lack of relevant action, unless there is a + fixed deadline.</p> + </li> + + <li> + <p>Make any decision for whom noone else has responsibility.</p> + </li> + + <li> + <p>Propose draft General Resolutions and amendments.</p> + </li> + + <li> + <p>Together with the Technical Committee, appoint new members to + the Committee. (See §6.2.)</p> + </li> + + <li> + <p>Use a casting vote when Developers vote.</p> + + <p>The Project Leader also has a normal vote in such ballots.</p> + </li> + + <li> + <p>Vary the discussion period for Developers' votes (as above).</p> + </li> + + <li> + <p>Lead discussions amongst Developers.</p> + + <p>The Project Leader should attempt to participate in discussions + amongst the Developers in a helpful way which seeks to bring the + discussion to bear on the key issues at hand. The Project Leader + should not use the Leadership position to promote their own + personal views.</p> + </li> + + <li> + <p>In consultation with the developers, make decisions affecting + property held in trust for purposes related to Debian. (See + §9.). Such decisions are communicated to the members by the + Project Leader or their Delegate(s). Major expenditures + should be proposed and debated on the mailing list before + funds are disbursed.</p> + </li> + <li> + <p>Add or remove organizations from the list of trusted + organizations (see §9.3) that are authorized to accept and + hold assets for Debian. The evaluation and discussion leading + up to such a decision occurs on an electronic mailing list + designated by the Project Leader or their Delegate(s), on + which any developer may post. There is a minimum discussion + period of two weeks before an organization may be added to + the list of trusted organizations.</p> + </li> +</ol> + +<h3>5.2. Appointment</h3> + +<ol> + <li>The Project Leader is elected by the Developers.</li> + + <li>The election begins six weeks before the leadership post becomes + vacant, or (if it is too late already) immediately.</li> + + <li>For the first week any Developer may nominate + themselves as a candidate Project Leader, and summarize their plans for their term.</li> + + <li>For three weeks after that no more candidates may be nominated; + candidates should use this time for campaigning and discussion. If + there are no candidates at the end of the nomination period then the + nomination period is extended for an additional week, repeatedly if + necessary.</li> + + <li>The next two weeks are the polling period during which + Developers may cast their votes. Votes in leadership elections are + kept secret, even after the election is finished.</li> + + <li>The options on the ballot will be those candidates who have + nominated themselves and have not yet withdrawn, plus None Of The + Above. If None Of The Above wins the election then the election + procedure is repeated, many times if necessary.</li> + + <li> + The decision will be made using the method specified in section + §A.6 of the Standard Resolution Procedure. The quorum is the + same as for a General Resolution (§4.2) and the default + option is <q>None Of The Above</q>. + </li> + + <li>The Project Leader serves for one year from their election.</li> +</ol> + +<h3>5.3. Procedure</h3> + +<p>The Project Leader should attempt to make decisions which are +consistent with the consensus of the opinions of the Developers.</p> + +<p>Where practical the Project Leader should informally solicit the +views of the Developers.</p> + +<p>The Project Leader should avoid overemphasizing their own point of +view when making decisions in their capacity as Leader.</p> + +<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> + +<h3>6.1. Powers</h3> + +<p>The <a href="tech-ctte">Technical Committee</a> may:</p> + +<ol> + <li> + <p>Decide on any matter of technical policy.</p> + + <p>This includes the contents of the technical policy manuals, + developers' reference materials, example packages and the behaviour + of non-experimental package building tools. (In each case the usual + maintainer of the relevant software or documentation makes + decisions initially, however; see 6.3(5).)</p> + </li> + + <li> + <p>Decide any technical matter where Developers' jurisdictions + overlap.</p> + + <p>In cases where Developers need to implement compatible + technical policies or stances (for example, if they disagree about + the priorities of conflicting packages, or about ownership of a + command name, or about which package is responsible for a bug that + both maintainers agree is a bug, or about who should be the + maintainer for a package) the technical committee may decide the + matter.</p> + </li> + + <li> + <p>Make a decision when asked to do so.</p> + + <p>Any person or body may delegate a decision of their own to the + Technical Committee, or seek advice from it.</p> + </li> + + <li> + <p>Overrule a Developer (requires a 3:1 majority).</p> + + <p>The Technical Committee may ask a Developer to take a + particular technical course of action even if the Developer does + not wish to; this requires a 3:1 majority. For example, the + Committee may determine that a complaint made by the submitter of a + bug is justified and that the submitter's proposed solution should + be implemented.</p> + </li> + + <li> + <p>Offer advice.</p> + + <p>The Technical Committee may make formal announcements about its + views on any matter. <cite>Individual members may of course make + informal statements about their views and about the likely views of + the committee.</cite></p> + </li> + + <li> + <p>Together with the Project Leader, appoint new members to itself + or remove existing members. (See §6.2.)</p> + </li> + + <li> + <p>Appoint the Chair of the Technical Committee.</p> + + <p> + The Chair is elected by the Committee from its members. All + members of the committee are automatically nominated; the + committee votes starting one week before the post will become + vacant (or immediately, if it is already too late). The members + may vote by public acclamation for any fellow committee member, + including themselves; there is no default option. The vote + finishes when all the members have voted, or when the voting + period has ended. The result is determined using the method + specified in section A.6 of the Standard Resolution Procedure. + </p> + </li> + + <li> + <p>The Chair can stand in for the Leader, together with the + Secretary</p> + + <p>As detailed in §7.1(2), the Chair of the Technical + Committee and the Project Secretary may together stand in for the + Leader if there is no Leader.</p> + </li> +</ol> + +<h3>6.2. Composition</h3> + +<ol> + <li> + <p>The Technical Committee consists of up to 8 Developers, and + should usually have at least 4 members.</p> + </li> + + <li> + <p>When there are fewer than 8 members the Technical Committee may + recommend new member(s) to the Project Leader, who may choose + (individually) to appoint them or not.</p> + </li> + + <li> + <p>When there are 5 members or fewer the Technical Committee may + appoint new member(s) until the number of members reaches 6.</p> + </li> + + <li> + <p>When there have been 5 members or fewer for at least one week + the Project Leader may appoint new member(s) until the number of + members reaches 6, at intervals of at least one week per + appointment.</p> + </li> + + <li> + <p>A Developer is not eligible to be (re)appointed to the Technical + Committee if they have been a member within the previous 12 + months.</p> + </li> + + <li> + <p>If the Technical Committee and the Project Leader agree they + may remove or replace an existing member of the Technical + Committee.</p> + </li> + + <li> + <p>Term limit:</p> + <ol> + <li> + <p>On January 1st of each year the term of any Committee member + who has served more than 42 months (3.5 years) and who is one + of the two most senior members is set to expire on December + 31st of that year.</p> + </li> + <li> + <p>A member of the Technical Committee is said to be more + senior than another if they were appointed earlier, or were + appointed at the same time and have been a member of the + Debian Project longer. In the event that a member has been + appointed more than once, only the most recent appointment is + relevant.</p> + </li> + </ol> + </li> +</ol> + +<h3>6.3. Procedure</h3> + +<ol> + <li> + <p>The Technical Committee uses the Standard Resolution + Procedure.</p> + + <p>A draft resolution or amendment may be proposed by any member + of the Technical Committee. There is no minimum discussion period; + the voting period lasts for up to one week, or until the outcome is + no longer in doubt. Members may change their votes. There is a + quorum of two.</p> + </li> + + <li> + <p>Details regarding voting</p> + + <p>The Chair has a casting vote. When the Technical Committee + votes whether to override a Developer who also happens to be a + member of the Committee, that member may not vote (unless they are + the Chair, in which case they may use only their casting + vote).</p> + </li> + + <li> + <p>Public discussion and decision-making.</p> + + <p>Discussion, draft resolutions and amendments, and votes by + members of the committee, are made public on the Technical + Committee public discussion list. There is no separate secretary + for the Committee.</p> + </li> + + <li> + <p>Confidentiality of appointments.</p> + + <p>The Technical Committee may hold confidential discussions via + private email or a private mailing list or other means to discuss + appointments to the Committee. However, votes on appointments must + be public.</p> + </li> + + <li> + <p>No detailed design work.</p> + + <p>The Technical Committee does not engage in design of new + proposals and policies. Such design work should be carried out by + individuals privately or together and discussed in ordinary + technical policy and design forums.</p> + + <p>The Technical Committee restricts itself to choosing from or + adopting compromises between solutions and decisions which have + been proposed and reasonably thoroughly discussed elsewhere.</p> + + <p><cite>Individual members of the technical committee may of + course participate on their own behalf in any aspect of design and + policy work.</cite></p> + </li> + + <li> + <p>Technical Committee makes decisions only as last resort.</p> + + <p>The Technical Committee does not make a technical decision + until efforts to resolve it via consensus have been tried and + failed, unless it has been asked to make a decision by the person + or body who would normally be responsible for it.</p> + </li> +</ol> + +<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> + +<h3>7.1. Powers</h3> + +<p>The <a href="secretary">Secretary</a>:</p> + +<ol> + <li> + <p>Takes votes amongst the Developers, and determines the number + and identity of Developers, whenever this is required by the + constitution.</p> + </li> + + <li> + <p>Can stand in for the Leader, together with the Chair of the + Technical Committee.</p> + + <p>If there is no Project Leader then the Chair of the + Technical Committee and the Project Secretary may by joint + agreement make decisions if they consider it imperative to do + so.</p> + </li> + + <li> + <p>Adjudicates any disputes about interpretation of the + constitution.</p> + </li> + + <li> + <p>May delegate part or all of their authority to someone else, or + withdraw such a delegation at any time.</p> + </li> +</ol> + +<h3>7.2. Appointment</h3> + +<p>The Project Secretary is appointed by the Project Leader and the +current Project Secretary.</p> + +<p>If the Project Leader and the current Project Secretary cannot agree +on a new appointment, they must ask the Developers by way of +General Resolution to appoint a Secretary.</p> + +<p>If there is no Project Secretary or the current Secretary is +unavailable and has not delegated authority for a decision then the +decision may be made or delegated by the Chair of the Technical +Committee, as Acting Secretary.</p> + +<p>The Project Secretary's term of office is 1 year, at which point +they or another Secretary must be (re)appointed.</p> + +<h3>7.3. Procedure</h3> + +<p>The Project Secretary should make decisions which are fair and +reasonable, and preferably consistent with the consensus of the +Developers.</p> + +<p>When acting together to stand in for an absent Project Leader the +Chair of the Technical Committee and the Project Secretary should +make decisions only when absolutely necessary and only when consistent +with the consensus of the Developers.</p> + +<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> + +<h3>8.1. Powers</h3> + +<p>The Project Leader's Delegates:</p> + +<ol> + <li>have powers delegated to them by the Project Leader;</li> + + <li>may make certain decisions which the Leader may not make + directly, including approving or expelling Developers or designating + people as Developers who do not maintain packages. <cite>This is to + avoid concentration of power, particularly over membership as a + Developer, in the hands of the Project Leader.</cite></li> +</ol> + +<h3>8.2. Appointment</h3> + +<p>The Delegates are appointed by the Project Leader and may be +replaced by the Leader at the Leader's discretion. The Project Leader +may not make the position as a Delegate conditional on particular +decisions by the Delegate, nor may they override a decision made by a +Delegate once made.</p> + +<h3>8.3. Procedure</h3> + +<p>Delegates may make decisions as they see fit, but should attempt to +implement good technical decisions and/or follow consensus opinion.</p> + +<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> + +<p>In most jurisdictions around the world, the Debian project is not +in a position to directly hold funds or other property. Therefore, +property has to be owned by any of a number of organisations as +detailed in §9.2.</p> + +<p>Traditionally, SPI was the sole organisation authorized to hold +property and monies for the Debian Project. SPI was created in +the U.S. to hold money in trust there.</p> + +<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate +organisations who share some goals. +Debian is grateful for the legal support framework offered by SPI.</p> + +<h3>9.1. Relationship with Associated Organizations</h3> + +<ol> + <li> + <p>Debian Developers do not become agents or employees of + organisations holding assets in trust for Debian, or of + each other, or of persons in authority in the Debian Project, + solely by the virtue of being Debian Developers. A person + acting as a Developer does so as an individual, on their own + behalf. Such organisations may, of their own accord, + establish relationships with individuals who are also Debian + developers.</p> + </li> +</ol> + +<h3>9.2. Authority</h3> + +<ol> + <li> + <p>An organisation holding assets for Debian has no authority + regarding Debian's technical or nontechnical decisions, except + that no decision by Debian with respect to any property held + by the organisation shall require it to act outside its legal + authority.</p> + </li> + <li> + <p>Debian claims no authority over an organisation that holds + assets for Debian other than that over the use of property + held in trust for Debian.</p> + </li> +</ol> + +<h3>9.3. Trusted organisations</h3> + +<p>Any donations for the Debian Project must be made to any one of a +set of organisations designated by the Project leader (or a +delegate) to be authorized to handle assets to be used for the +Debian Project.</p> + +<p>Organisations holding assets in trust for Debian should +undertake reasonable obligations for the handling of such +assets.</p> + +<p>Debian maintains a public List of Trusted Organisations that +accept donations and hold assets in trust for Debian +(including both tangible property and intellectual property) +that includes the commitments those organisations have made as +to how those assets will be handled.</p> + +<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> + +<p>These rules apply to communal decision-making by committees and +plebiscites, where stated above.</p> + +<h3>A.0. Proposal</h3> + +<p>The formal procedure begins when a draft resolution is proposed and +sponsored, as required.</p> + +<h3>A.1. Discussion and Amendment</h3> + +<ol> + <li>Following the proposal, the resolution may be discussed. + Amendments may be made formal by being proposed and sponsored + according to the requirements for a new resolution, or directly by + the proposer of the original resolution.</li> + + <li>A formal amendment may be accepted by the resolution's proposer, + in which case the formal resolution draft is immediately changed to + match.</li> + + <li>If a formal amendment is not accepted, or one of the sponsors of + the resolution does not agree with the acceptance by the proposer of + a formal amendment, the amendment remains as an amendment and will be + voted on.</li> + + <li>If an amendment accepted by the original proposer is not to the + liking of others, they may propose another amendment to reverse the + earlier change (again, they must meet the requirements for proposer + and sponsor(s).)</li> + + <li>The proposer of a resolution may suggest changes to the wordings + of amendments; these take effect if the proposer of the amendment + agrees and none of the sponsors object. In this case the changed + amendments will be voted on instead of the originals.</li> + + <li>The proposer of a resolution may make changes to correct minor + errors (for example, typographical errors or inconsistencies) or + changes which do not alter the meaning, providing noone objects + within 24 hours. In this case the minimum discussion period is not + restarted.</li> +</ol> + +<h3>A.2. Calling for a vote</h3> + +<ol> + <li>The proposer or a sponsor of a motion or an amendment may call + for a vote, providing that the minimum discussion period (if any) has + elapsed.</li> + + <li> + The proposer or any sponsor of a resolution may call for a vote on that + resolution and all related amendments. + </li> + + <li>The person who calls for a vote states what they believe the + wordings of the resolution and any relevant amendments are, and + consequently what form the ballot should take. However, the final + decision on the form of ballot(s) is the Secretary's - see 7.1(1), + 7.1(3) and A.3(4).</li> + + <li> + The minimum discussion period is counted from the time the last + formal amendment was accepted, or since the whole resolution + was proposed if no amendments have been proposed and accepted. + </li> +</ol> + +<h3>A.3. Voting procedure</h3> + +<ol> + <li> + Each resolution and its related amendments is voted on in a + single ballot that includes an option for the original + resolution, each amendment, and the default option (where + applicable). + </li> + + <li> + The default option must not have any supermajority requirements. + Options which do not have an explicit supermajority requirement + have a 1:1 majority requirement. + </li> + + <li> + The votes are counted according to the rules in A.6. The + default option is <q>Further Discussion</q>, unless specified + otherwise. + </li> + + <li>In cases of doubt the Project Secretary shall decide on matters + of procedure.</li> +</ol> + +<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> + +<p>The proposer of a resolution or unaccepted amendment may withdraw +it. In this case new proposers may come forward keep it alive, in which +case the first person to do so becomes the new proposer and any others +become sponsors if they aren't sponsors already.</p> + +<p>A sponsor of a resolution or amendment (unless it has been +accepted) may withdraw.</p> + +<p>If the withdrawal of the proposer and/or sponsors means that a +resolution has no proposer or not enough sponsors it will not be voted +on unless this is rectified before the resolution expires.</p> + +<h3>A.5. Expiry</h3> + +<p> + If a proposed resolution has not been discussed, amended, voted on or + otherwise dealt with for 4 weeks the secretary may issue a statement + that the issue is being withdrawn. If none of the sponsors of any + of the proposals object within a week, the issue is withdrawn. +</p> + +<p> + The secretary may also include suggestions on how to proceed, + if appropriate. +</p> + +<h3>A.6. Vote Counting</h3> + +<ol> + <li> Each voter's ballot ranks the options being voted on. Not all + options need be ranked. Ranked options are considered + preferred to all unranked options. Voters may rank options + equally. Unranked options are considered to be ranked equally + with one another. Details of how ballots may be filled out + will be included in the Call For Votes. + </li> + <li> If the ballot has a quorum requirement R any options other + than the default option which do not receive at least R votes + ranking that option above the default option are dropped from + consideration. + </li> + <li> Any (non-default) option which does not defeat the default option + by its required majority ratio is dropped from consideration. + <ol> + <li> + Given two options A and B, V(A,B) is the number of voters + who prefer option A over option B. + </li> + <li> + An option A defeats the default option D by a majority + ratio N, if V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly great + </li> + <li> + If a supermajority of S:1 is required for A, its majority ratio + is S; otherwise, its majority ratio is 1. + </li> + </ol> + </li> + <li> From the list of undropped options, we generate a list of + pairwise defeats. + <ol> + <li> + An option A defeats an option B, if V(A,B) is strictly greater + than V(B,A). + </li> + </ol> + </li> + <li> From the list of [undropped] pairwise defeats, we generate a + set of transitive defeats. + <ol> + <li> + An option A transitively defeats an option C if A defeats + C or if there is some other option B where A defeats B AND + B transitively defeats C. + </li> + </ol> + </li> + <li> We construct the Schwartz set from the set of transitive defeats. + <ol> + <li> + An option A is in the Schwartz set if for all options B, + either A transitively defeats B, or B does not transitively + defeat A. + </li> + </ol> + </li> + <li> If there are defeats between options in the Schwartz set, + we drop the weakest such defeats from the list of pairwise + defeats, and return to step 5. + <ol> + <li> + A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) + is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if + V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). + </li> + <li> + A weakest defeat is a defeat that has no other defeat weaker + than it. There may be more than one such defeat. + </li> + </ol> + </li> + <li> If there are no defeats within the Schwartz set, then the winner + is chosen from the options in the Schwartz set. If there is + only one such option, it is the winner. If there are multiple + options, the elector with the casting vote chooses which of those + options wins. + </li> +</ol> + +<p> + <strong>Note:</strong> Options which the voters rank above the default option + are options they find acceptable. Options ranked below the default + options are options they find unacceptable. +</p> + +<p><cite>When the Standard Resolution Procedure is to be used, the text +which refers to it must specify what is sufficient to have a draft +resolution proposed and/or sponsored, what the minimum discussion +period is, and what the voting period is. It must also specify any +supermajority and/or the quorum (and default option) to be +used.</cite></p> + +<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> + +<p>The present indicative (<q>is</q>, for example) means that the statement +is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the +person or body has discretion. <q>Should</q> means that it would be +considered a good thing if the sentence were obeyed, but it is not +binding. <cite>Text marked as a citation, such as this, is rationale +and does not form part of the constitution. It may be used only to aid +interpretation in cases of doubt.</cite></p> |