604 lines
30 KiB
Plaintext
604 lines
30 KiB
Plaintext
Debian Constitution
|
|
|
|
Constitution for the Debian Project (v1.0)
|
|
|
|
1. Introduction
|
|
|
|
The Debian Project is an association of individuals who have made
|
|
common cause to create a free operating system.
|
|
|
|
This document describes the organisational structure for formal
|
|
decisionmaking in the Project. It does not describe the goals of the
|
|
Project or how it achieves them, or contain any policies except those
|
|
directly related to the decisionmaking process.
|
|
|
|
2. Decisionmaking bodies and individuals
|
|
|
|
Each decision in the Project is made by one or more of the following:
|
|
1. The Developers, by way of General Resolution or an election;
|
|
2. The Project Leader;
|
|
3. The Technical Committee and/or its Chairman;
|
|
4. The individual Developer working on a particular task;
|
|
5. Delegates appointed by the Project Leader for specific tasks.
|
|
6. The Project Secretary;
|
|
|
|
Most of the remainder of this document will outline the powers of
|
|
these bodies, their composition and appointment, and the procedure for
|
|
their decisionmaking. The powers of a person or body may be subject to
|
|
review and/or limitation by others; in this case the reviewing body or
|
|
person's entry will state this. In the list above, a person or body is
|
|
usually listed before any people or bodies whose decisions they can
|
|
overrule or who they (help) appoint - but not everyone listed earlier
|
|
can overrule everyone listed later.
|
|
|
|
2.1. General rules
|
|
|
|
1. Nothing in this constitution imposes an obligation on anyone to do
|
|
work for the Project. A person who does not want to do a task
|
|
which has been delegated or assigned to them does not need to do
|
|
it. However, they must not actively work against these rules and
|
|
decisions properly made under them.
|
|
2. A person may hold several posts, except that the Project Leader,
|
|
Project Secretary and the Chairman of the Technical Committee must
|
|
be distinct, and that the Leader cannot appoint themselves as
|
|
their own Delegate.
|
|
3. A person may leave the Project or resign from a particular post
|
|
they hold, at any time, by stating so publicly.
|
|
|
|
3. Individual Developers
|
|
|
|
3.1. Powers
|
|
|
|
An individual Developer may
|
|
1. make any technical or nontechnical decision with regard to their
|
|
own work;
|
|
2. propose or sponsor draft General Resolutions;
|
|
3. propose themselves as a Project Leader candidate in elections;
|
|
4. vote on General Resolutions and in Leadership elections.
|
|
|
|
3.2. Composition and appointment
|
|
|
|
1. Developers are volunteers who agree to further the aims of the
|
|
Project insofar as they participate in it, and who maintain
|
|
package(s) for the Project or do other work which the Project
|
|
Leader's Delegate(s) consider worthwhile.
|
|
2. The Project Leader's Delegate(s) may choose not to admit new
|
|
Developers, or expel existing Developers. If the Developers feel
|
|
that the Delegates are abusing their authority they can of course
|
|
override the decision by way of General Resolution - see s.4.1(3),
|
|
s.4.2.
|
|
|
|
3.3. Procedure
|
|
|
|
Developers may make these decisions as they see fit.
|
|
|
|
4. The Developers by way of General Resolution or election
|
|
|
|
4.1. Powers
|
|
|
|
Together, the Developers may:
|
|
1. Appoint or recall the Project Leader.
|
|
2. Amend this constitution, provided they agree with a 3:1 majority.
|
|
3. Override any decision by the Project Leader or a Delegate.
|
|
4. Override any decision by the Technical Committee, provided they
|
|
agree with a 2:1 majority.
|
|
5. Issue nontechnical policy documents and statements.
|
|
These include documents describing the goals of the project, its
|
|
relationship with other free software entities, and nontechnical
|
|
policies such as the free software licence terms that Debian
|
|
software must meet.
|
|
They may also include position statements about issues of the day.
|
|
6. Together with the Project Leader and SPI, make decisions about
|
|
property held in trust for purposes related to Debian. (See
|
|
s.9.1.)
|
|
|
|
4.2. Procedure
|
|
|
|
1. 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.
|
|
2. Delaying a decision by the Project Leader or their Delegate:
|
|
1. 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 s4.1(3).
|
|
2. 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).
|
|
3. 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.
|
|
4. 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 be delayed until then. There is no
|
|
quorum for this immediate procedural vote.
|
|
5. If the Project Leader (or the Delegate) withdraws the
|
|
original decision, the vote becomes moot, and is no longer
|
|
conducted.
|
|
3. Votes are taken by the Project Secretary. Votes and tallies
|
|
results are not be 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, and may be ended by the Project Secretary when the
|
|
outcome of a vote is no longer in doubt.
|
|
4. 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.
|
|
5. 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.
|
|
6. Votes are cast by email in a manner suitable to the Secretary. The
|
|
Secretary determines for each poll whether voters can change their
|
|
votes.
|
|
7. 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.
|
|
|
|
5. Project Leader
|
|
|
|
5.1. Powers
|
|
|
|
The Project Leader may:
|
|
1. Appoint Delegates or delegate decisions to the Technical
|
|
Committee.
|
|
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.
|
|
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.
|
|
2. Lend authority to other Developers.
|
|
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.
|
|
3. Make any decision which requires urgent action.
|
|
This does not apply to decisions which have only become gradually
|
|
urgent through lack of relevant action, unless there is a fixed
|
|
deadline.
|
|
4. Make any decision for whom noone else has responsibility.
|
|
5. Propose draft General Resolutions and amendments.
|
|
6. Together with the Technical Committee, appoint new members to the
|
|
Committee. (See s.6.2.)
|
|
7. Use a casting vote when Developers vote.
|
|
The Project Leader also has a normal vote in such ballots.
|
|
8. Vary the discussion period for Developers' votes (as above).
|
|
9. Lead discussions amongst Developers.
|
|
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.
|
|
10. Together with SPI, make decisions affecting property held in trust
|
|
for purposes related to Debian. (See s.9.1.)
|
|
|
|
5.2. Appointment
|
|
|
|
1. The Project Leader is elected by the Developers.
|
|
2. The election begins nine weeks before the leadership post becomes
|
|
vacant, or (if it is too late already) immediately.
|
|
3. For the following three weeks any Developer may nominate
|
|
themselves as a candidate Project Leader.
|
|
4. For three weeks after that no more candidates may be nominated;
|
|
candidates should use this time for campaigning (to make their
|
|
identities and positions known). If there are no candidates at the
|
|
end of the nomination period then the nomination period is
|
|
extended for three further weeks, repeatedly if necessary.
|
|
5. The next three 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.
|
|
6. 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.
|
|
7. The decision will be made using Concorde Vote Counting. The quorum
|
|
is the same as for a General Resolution (s.4.2) and the default
|
|
option is None Of The Above.
|
|
8. The Project Leader serves for one year from their election.
|
|
|
|
5.3. Procedure
|
|
|
|
The Project Leader should attempt to make decisions which are
|
|
consistent with the consensus of the opinions of the Developers.
|
|
|
|
Where practical the Project Leader should informally solicit the views
|
|
of the Developers.
|
|
|
|
The Project Leader should avoid overemphasizing their own point of
|
|
view when making decisions in their capacity as Leader.
|
|
|
|
6. Technical committee
|
|
|
|
6.1. Powers
|
|
|
|
The Technical Committee may:
|
|
1. Decide on any matter of technical policy.
|
|
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).)
|
|
2. Decide any technical matter where Developers' jurisdictions
|
|
overlap.
|
|
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.
|
|
3. Make a decision when asked to do so.
|
|
Any person or body may delegate a decision of their own to the
|
|
Technical Committee, or seek advice from it.
|
|
4. Overrule a Developer (requires a 3:1 majority).
|
|
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.
|
|
5. Offer advice.
|
|
The Technical Committee may make formal announcements about its
|
|
views on any matter. Individual members may of course make
|
|
informal statements about their views and about the likely views
|
|
of the committee.
|
|
6. Together with the Project Leader, appoint new members to itself or
|
|
remove existing members. (See s.6.2.)
|
|
7. Appoint the Chairman of the Technical Committee.
|
|
The Chairman is elected by the Committee from its members. All
|
|
members of the committee are automatically nominated; the
|
|
committee vote 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 None Of The Above option. The
|
|
vote finishes when all the members have voted or when the outcome
|
|
is no longer in doubt. The result is determined according to
|
|
Concorde Vote Counting.
|
|
8. The Chairman can stand in for the Leader, together with the
|
|
Secretary
|
|
As detailed in s.7.1(2), the Chairman of the Technical Committee
|
|
and the Project Secretary may together stand in for the Leader if
|
|
there is no Leader.
|
|
|
|
6.2. Composition
|
|
|
|
1. The Technical Committee consists of up to 8 Developers, and should
|
|
usually have at least 4 members.
|
|
2. 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.
|
|
3. When there are 5 members or fewer the Technical Committee may
|
|
appoint new member(s) until the number of members reaches 6.
|
|
4. 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.
|
|
5. If the Technical Committee and the Project Leader agree they may
|
|
remove or replace an existing member of the Technical Committee.
|
|
|
|
6.3. Procedure
|
|
|
|
1. The Technical Committee uses the Standard Resolution Procedure.
|
|
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.
|
|
2. Details regarding voting
|
|
The Chairman 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 Chairman, in which case they may use only their casting vote).
|
|
3. Public discussion and decisionmaking.
|
|
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.
|
|
4. Confidentiality of appointments.
|
|
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.
|
|
5. No detailed design work.
|
|
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.
|
|
The Technical Committee restricts itself to choosing from or
|
|
adopting compromises between solutions and decisions which have
|
|
been proposed and reasonably thoroughly discussed elsewhere.
|
|
Individual members of the technical committee may of course
|
|
participate on their own behalf in any aspect of design and policy
|
|
work.
|
|
6. Technical Committee makes decisions only as last resort.
|
|
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.
|
|
|
|
7. The Project Secretary
|
|
|
|
7.1. Powers
|
|
|
|
The Secretary:
|
|
1. Takes votes amongst the Developers, and determines the number and
|
|
identity of Developers, whenever this is required by the
|
|
constitution.
|
|
2. Can stand in for the Leader, together with the Chairman of the
|
|
Technical Committee.
|
|
If there is no Project Leader then the Chairman of the Technical
|
|
Committee and the Project Secretary may by joint agreement make
|
|
decisions if they consider it imperative to do so.
|
|
3. Adjudicates any disputes about interpretation of the constitution.
|
|
4. May delegate part or all of their authority to someone else, or
|
|
withdraw such a delegation at any time.
|
|
|
|
7.2. Appointment
|
|
|
|
The Project Secretary is appointed by the Project Leader and the
|
|
current Project Secretary.
|
|
|
|
If the Project Leader and the current Project Secretary cannot agree
|
|
on a new appointment they must ask the board of SPI to appoint a
|
|
Secretary.
|
|
|
|
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 Chairman of the Technical
|
|
Committee, as Acting Secretary.
|
|
|
|
The Project Secretary's term of office is 1 year, at which point they
|
|
or another Secretary must be (re)appointed.
|
|
|
|
7.3. Procedure
|
|
|
|
The Project Secretary should make decisions which are fair and
|
|
reasonable, and preferably consistent with the consensus of the
|
|
Developers.
|
|
|
|
When acting together to stand in for an absent Project Leader the
|
|
Chairman 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.
|
|
|
|
8. The Project Leader's Delegates
|
|
|
|
8.1. Powers
|
|
|
|
The Project Leader's Delegates:
|
|
1. have powers delegated to them by the Project Leader;
|
|
2. 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. This is to avoid
|
|
concentration of power, particularly over membership as a
|
|
Developer, in the hands of the Project Leader.
|
|
|
|
8.2. Appointment
|
|
|
|
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.
|
|
|
|
8.3. Procedure
|
|
|
|
Delegates may make decisions as they see fit, but should attempt to
|
|
implement good technical decisions and/or follow consensus opinion.
|
|
|
|
9. Software in the Public Interest
|
|
|
|
SPI and Debian are separate organisations who share some goals. Debian
|
|
is grateful for the legal support framework offered by SPI. Debian's
|
|
Developers are currently members of SPI by virtue of their status as
|
|
Developers.
|
|
|
|
9.1. Authority
|
|
|
|
1. SPI has no authority regarding Debian's technical or nontechnical
|
|
decisions, except that no decision by Debian with respect to any
|
|
property held by SPI shall require SPI to act outside its legal
|
|
authority, and that Debian's constitution may occasionally use SPI
|
|
as a decision body of last resort.
|
|
2. Debian claims no authority over SPI other than that over the use
|
|
of certain of SPI's property, as described below, though Debian
|
|
Developers may be granted authority within SPI by SPI's rules.
|
|
3. Debian Developers are not agents or employees of SPI, or of each
|
|
other or of persons in authority in the Debian Project. A person
|
|
acting as a Developer does so as an individual, on their own
|
|
behalf.
|
|
|
|
9.2. Management of property for purposes related to Debian
|
|
|
|
Since Debian has no authority to hold money or property, any donations
|
|
for the Debian Project must made to SPI, which manages such affairs.
|
|
|
|
SPI have made the following undertakings:
|
|
1. SPI will hold money, trademarks and other tangible and intangible
|
|
property and manage other affairs for purposes related to Debian.
|
|
2. Such property will be accounted for separately and held in trust
|
|
for those purposes, decided on by Debian and SPI according to this
|
|
section.
|
|
3. SPI will not dispose of or use property held in trust for Debian
|
|
without approval from Debian, which may be granted by the Project
|
|
Leader or by General Resolution of the Developers.
|
|
4. SPI will consider using or disposing of property held in trust for
|
|
Debian when asked to do so by the Project Leader.
|
|
5. SPI will use or dispose of property held in trust for Debian when
|
|
asked to do so by a General Resolution of the Developers, provided
|
|
that this is compatible with SPI's legal authority.
|
|
6. SPI will notify the Developers by electronic mail to a Debian
|
|
Project mailing list when it uses or disposes of property held in
|
|
trust for Debian.
|
|
|
|
A. Standard Resolution Procedure
|
|
|
|
These rules apply to communal decisionmaking by committees and
|
|
plebiscites, where stated above.
|
|
|
|
A.1. Proposal
|
|
|
|
The formal procedure begins when a draft resolution is proposed and
|
|
sponsored, as required.
|
|
|
|
A.1. Discussion and Amendment
|
|
|
|
1. 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.
|
|
2. A formal amendment may be accepted by the resolution's proposer,
|
|
in which case the formal resolution draft is immediately changed
|
|
to match.
|
|
3. 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.
|
|
4. 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).)
|
|
5. The proposer or 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.
|
|
6. 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 mininum discussion period is not
|
|
restarted.
|
|
|
|
A.2. Calling for a vote
|
|
|
|
1. 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.
|
|
2. The proposer or a sponsor of a motion may call for a vote on any
|
|
or all of the amendments individually or together; the proposer or
|
|
sponsor of an amendment may call for a vote only on that amendment
|
|
and related amendments.
|
|
3. 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(6).
|
|
4. The minimum discussion period is counted from the time the last
|
|
formal amendment was accepted, or the last related formal
|
|
amendment was accepted if an amendment is being voted on, or since
|
|
the whole resolution was proposed if no amendments have been
|
|
proposed and accepted.
|
|
|
|
A.3. Voting procedure
|
|
|
|
1. Each independent set of related amendments is voted on in a
|
|
separate ballot. Each such ballot has as options all the sensible
|
|
combinations of amendments and options, and an option Further
|
|
Discussion. If Further Discussion wins then the entire resolution
|
|
procedure is set back to the start of the discussion period. No
|
|
quorum is required for an amendment.
|
|
2. When the final form of the resolution has been determined it is
|
|
voted on in a final ballot, in which the options are Yes, No and
|
|
Further Discussion. If Further Discussion wins then the entire
|
|
procedure is set back to the start of the discussion period.
|
|
3. The vote taker (if there is one) or the voters (if voting is done
|
|
by public pronouncement) may arrange for these ballots to be held
|
|
simultaneously, even (for example) using a single voting message.
|
|
If amendment ballot(s) and the final ballot are combined in this
|
|
way then it must be possible for a voter to vote differently in
|
|
the final ballot for each of the possible forms of the final draft
|
|
resolution.
|
|
4. Votes may be cast during the voting period, as specified
|
|
elsewhere. If the voting period can end if the outcome is no
|
|
longer in doubt, the possibility that voters may change their
|
|
votes is not considered.
|
|
5. The votes are counted according to the Concorde Vote Counting. If
|
|
a quorum is required then the default option is Further
|
|
Discussion.
|
|
6. In cases of doubt the Project Secretary shall decide on matters of
|
|
procedure (for example, whether particular amendments should be
|
|
considered independent or not).
|
|
|
|
A.4. Withdrawing resolutions or unaccepted amendments
|
|
|
|
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.
|
|
|
|
A sponsor of a resolution or amendment (unless it has been accepted)
|
|
may withdraw.
|
|
|
|
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.
|
|
|
|
A.5. Expiry
|
|
|
|
If a proposed resolution has not been discussed, amended, voted on or
|
|
otherwise dealt with for 4 weeks then it is considered to have been
|
|
withdrawn.
|
|
|
|
A.6. Concorde Vote Counting
|
|
|
|
1. This is used to determine the winner amongst a list of options.
|
|
Each ballot paper gives a ranking of the voter's preferred
|
|
options. (The ranking need not be complete.)
|
|
2. Option A is said to Dominate option B if strictly more ballots
|
|
prefer A to B than prefer B to A.
|
|
3. All options which are Dominated by at least one other option are
|
|
discarded, and references to them in ballot papers will be
|
|
ignored.
|
|
4. If there is any option which Dominates all others then that is the
|
|
winner.
|
|
5. If there is now more than one option remaining Single
|
|
Transferrable Vote will be applied to choose amongst those
|
|
remaining:
|
|
+ The number of first preferences for each option is counted,
|
|
and if any option has more than half it is the winner.
|
|
+ Otherwise the option with the lowest number of first
|
|
preferences is eliminated and its votes redistributed
|
|
according to the second preferences.
|
|
+ This elimination procedure is repeated, moving down ballot
|
|
papers to 2nd, 3rd, 4th, etc. preferences as required, until
|
|
one option gets more than half of the `first' preferences.
|
|
6. In the case of ties the elector with a casting vote will decide.
|
|
The casting vote does not count as a normal vote; however that
|
|
elector will usually also get a normal vote.
|
|
7. If a supermajority is required the number of Yes votes in the
|
|
final ballot is reduced by an appropriate factor. Strictly
|
|
speaking, for a supermajority of F:A, the number of ballots which
|
|
prefer Yes to X (when considering whether Yes Dominates X or X
|
|
Dominates Yes) or the number of ballots whose first (remaining)
|
|
preference is Yes (when doing STV comparisons for winner and
|
|
elimination purposes) is multiplied by a factor A/F before the
|
|
comparison is done. This means that a 2:1 vote, for example, means
|
|
twice as many people voted for as against; abstentions are not
|
|
counted.
|
|
8. If a quorum is required, there must be at least that many votes
|
|
which prefer the winning option to the default option. If there
|
|
are not then the default option wins after all. For votes
|
|
requiring a supermajority, the actual number of Yes votes is used
|
|
when checking whether the quorum has been reached.
|
|
|
|
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.
|
|
|
|
B. Use of language and typography
|
|
|
|
The present indicative (`is', for example) means that the statement is
|
|
a rule in this constitution. `May' or `can' indicates that the person
|
|
or body has discretion. `Should' means that it would be considered a
|
|
good thing if the sentence were obeyed, but it is not binding. 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.
|