--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML lang="en">
+<HEAD>
+<TITLE>Debian GNU/Linux -- Debian Constitution</TITLE>
+<LINK REV="made" HREF="mailto:webmaster@debian.org">
+<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<META NAME="Description" CONTENT="Debian GNU/Linux is a free distribution of the GNU/Linux operating system. It is maintained and updated through the work of many users who volunteer their time and effort.">
+<META NAME="Keywords" CONTENT="debian, GNU, linux, unix, open source, free, DFSG]">
+<meta name="Author" content="Debian Webmaster, webmaster@debian.org">
+<meta name="Generator" content="WML 1.6.8 (12-01-1999)">
+<meta name="Modified" content="09-12-1998 22:36:32">
+</HEAD>
+<BODY text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#800080" alink="#FF0000">
+<TABLE border="0" cellpadding="3" cellspacing="0" width="100%">
+<TR>
+<TD>
+<IMG src="../Pics/logo-50.gif" border="0" hspace="0" vspace="0" alt="[Debian Logo]" width="33" height="50">
+<IMG src="../Pics/banner-blue.gif" border="0" hspace="0" vspace="0" alt="Debian GNU/Linux" width="310" height="29">
+</TD>
+</TR>
+<TR>
+<TD BGCOLOR="#DD0000">
+<A href="../"><IMG src="../Pics/home.en.gif" border="0" hspace="2" vspace="3" alt="Home" width="53" height="18"></A>
+<A href="../intro/about"><IMG src="../Pics/about.en.gif" border="0" hspace="2" vspace="3" alt="About Debian" width="107" height="18"></A>
+<A href="../News/"><IMG src="../Pics/news.en.gif" border="0" hspace="2" vspace="3" alt="News" width="50" height="18"></A>
+<A href="../distrib/"><IMG src="../Pics/distrib.en.gif" border="0" hspace="2" vspace="3" alt="Distribution" width="90" height="18"></A>
+<A href="../support"><IMG src="../Pics/support.en.gif" border="0" hspace="2" vspace="3" alt="Support" width="67" height="18"></A>
+<A href="../devel/"><IMG src="../Pics/devel.en.gif" border="0" hspace="2" vspace="3" alt="Developers Corner" width="105" height="18"></A>
+<A href="http://insite.verisim.com/search/debian/simple"><IMG src="../Pics/search.en.gif" border="0" hspace="2" vspace="3" alt="Search" width="61" height="18"></A>
+</TD>
+</TR>
+</TABLE>
+<H1>Debian Constitution</H1>
+ <h1>Constitution for the Debian Project (v1.0)</h1>
+ <h2>1. Introduction</h2>
+ <cite>The Debian Project is an association of individuals who have
+ made common cause to create a free operating system.</cite>
+ <p>
+ 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.
+ <h2>2. Decisionmaking bodies and individuals</h2>
+ Each decision in the Project is made by one or more of the following:
+ <ol>
+ <li>The Developers, by way of General Resolution or an election;
+ <li>The Project Leader;
+ <li>The Technical Committee and/or its Chairman;
+ <li>The individual Developer working on a particular task;
+ <li>Delegates appointed by the Project Leader for specific
+ tasks.
+ <li>The Project Secretary;
+ </ol>
+ 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. <cite>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.</cite>
+ <h3>2.1. General rules</h3>
+ <ol>
+ <li><p>
+ 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.
+ </p><li><p>
+ 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.
+ </p><li><p>
+ A person may leave the Project or resign from a particular
+ post they hold, at any time, by stating so publicly.
+ </ol>
+ <h2>3. Individual Developers</h2>
+ <h3>3.1. Powers</h3>
+ An individual Developer may
+ <ol>
+ <li>make any technical or nontechnical decision with regard to
+ their own work;
+ <li>propose or sponsor draft General Resolutions;
+ <li>propose themselves as a Project Leader candidate in elections;
+ <li>vote on General Resolutions and in Leadership elections.
+ </ol>
+ <h3>3.2. Composition and appointment</h3>
+ <ol><li><p>
+ 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.
+ </p><li><p>
+ The Project Leader's Delegate(s) may choose not to admit new
+ Developers, or expel existing Developers. <cite> 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.</cite>
+ </ol>
+ <h3>3.3. Procedure</h3>
+ Developers may make these decisions as they see fit.
+ <h2>4. The Developers by way of General Resolution or election</h2>
+ <h3>4.1. Powers</h3>
+ Together, the Developers may:
+ <ol>
+ <li><p>Appoint or recall the Project Leader.
+ </p>
+ <li><p>Amend this constitution, provided they agree with a 3:1 majority.
+ </p>
+ <li><p>Override any decision by the Project Leader or a Delegate.
+ </p>
+ <li><p>Override any decision by the Technical Committee,
+ provided they agree with a 2:1 majority.
+ </p>
+ <li><p>Issue nontechnical policy documents and statements.
+ <p>
+ 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.
+ <p>
+ They may also include position statements about issues of the day.
+ </p>
+ <li><p>Together with the Project Leader and SPI, make decisions
+ about property held in trust for purposes related to Debian.
+ (See s.9.1.)
+ </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><p>Delaying a decision by the Project Leader or their Delegate:
+ <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 s4.1(3).
+ <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>
+ 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>
+ 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.
+ <li>
+ If the Project Leader (or the Delegate) withdraws the original
+ decision, the vote becomes moot, and is no longer conducted.
+ </ol>
+ </p><li><p>
+ 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.
+ </p><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><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><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><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.
+ </ol>
+ <h2>5. Project Leader</h2>
+ <h3>5.1. Powers</h3>
+ The Project Leader may:
+ <ol>
+ <li>Appoint Delegates or delegate decisions to the Technical
+ Committee.
+ <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>
+ 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><p>Lend authority to other Developers.
+ <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><p>Make any decision which requires urgent action.
+ <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><p>Make any decision for whom noone else has responsibility.
+ </p>
+ <li><p>Propose draft General Resolutions and amendments.
+ </p>
+ <li><p>Together with the Technical Committee, appoint new members
+ to the Committee. (See s.6.2.)
+ </p>
+ <li>Use a casting vote when Developers vote.
+ <p>
+ The Project Leader also has a normal vote in such ballots.
+ </p>
+ <li><p>Vary the discussion period for Developers' votes (as above).
+ </p>
+ <li><p>Lead discussions amongst Developers.
+ <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><p>Together with SPI, make decisions affecting property
+ held in trust for purposes related to Debian. (See s.9.1.)
+ </ol>
+ <h3>5.2. Appointment</h3>
+ <ol>
+ <li>
+ The Project Leader is elected by the Developers.
+ <li>
+ The election begins nine weeks before the leadership post becomes
+ vacant, or (if it is too late already) immediately.
+ <li>
+ For the following three weeks any Developer may nominate themselves as
+ a candidate Project Leader.
+ <li>
+ 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.
+ <li>
+ 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.
+ <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>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.
+ <li>
+ The Project Leader serves for one year from their election.
+ </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>
+ Where practical the Project Leader should informally solicit the views
+ of the Developers.
+ <p>
+ The Project Leader should avoid overemphasizing their own point
+ of view when making decisions in their capacity as Leader.
+ <h2>6. Technical committee</h2>
+ <h3>6.1. Powers</h3>
+ The Technical Committee may:
+ <ol>
+ <li>Decide on any matter of technical policy.
+ <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>Decide any technical matter where Developers' jurisdictions overlap.
+ <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><p>Make a decision when asked to do so.
+ <p>
+ Any person or body may delegate a decision of their own to
+ the Technical Committee, or seek advice from it.
+ </p>
+ <li><p>Overrule a Developer (requires a 3:1 majority).
+ <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><p>
+ Offer advice.
+ <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><p>Together with the Project Leader, appoint new members to
+ itself or remove existing members. (See s.6.2.)
+ </p>
+ <li><p>Appoint the Chairman of the Technical Committee.
+ <p>
+ 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.
+ </p>
+ <li>The Chairman can stand in for the Leader, together with the Secretary
+ <p>
+ 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.
+ </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><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><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><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><p>
+ If the Technical Committee and the Project Leader agree they may
+ remove or replace an existing member of the Technical Committee.
+ </ol>
+ <h3>6.3. Procedure</h3>
+ <ol>
+ <li>The Technical Committee uses the Standard Resolution Procedure.
+ <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>Details regarding voting
+ <p>
+ 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).
+ </p>
+ <li>Public discussion and decisionmaking.
+ <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>
+ Confidentiality of appointments.
+ <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>
+ No detailed design work.
+ <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>
+ 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>
+ <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>Technical Committee makes decisions only as last resort.
+ <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.
+ </ol>
+ <h2>7. The Project Secretary</h2>
+ <h3>7.1. Powers</h3>
+ The Secretary:
+ <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>
+ <p>
+ Can stand in for the Leader, together with the Chairman of
+ the Technical Committee.
+ <p>
+ 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.
+ </p>
+ <li>
+ <p>
+ Adjudicates any disputes about interpretation of the
+ constitution.
+ </p>
+ <li>
+ <p>
+ May delegate part or all of their authority to someone else,
+ or withdraw such a delegation at any time.
+ </ol>
+ <h3>7.2. Appointment</h3>
+ <p>
+ The Project Secretary is appointed by the Project Leader and the
+ current Project Secretary.
+ <p>
+ 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.
+ <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 Chairman of the
+ Technical Committee, as Acting Secretary.
+ <p>
+ The Project Secretary's term of office is 1 year, at which point
+ they or another Secretary must be (re)appointed.
+ <h3>7.3. Procedure</h3>
+ The Project Secretary should make decisions which are fair and
+ reasonable, and preferably consistent with the consensus of the
+ Developers.
+ <p>
+ 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.
+ <h2>8. The Project Leader's Delegates</h2>
+ <h3>8.1. Powers</h3>
+ The Project Leader's Delegates:
+ <ol>
+ <li>have powers delegated to them by the Project Leader;
+ <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>
+ </ol>
+ <h3>8.2. Appointment</h3>
+ 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.
+ <h3>8.3. Procedure</h3>
+ Delegates may make decisions as they see fit, but should attempt
+ to implement good technical decisions and/or follow consensus
+ opinion.
+ <h2>9. Software in the Public Interest</h2>
+ SPI and Debian are separate organisations who share some goals.
+ Debian is grateful for the legal support framework offered by SPI.
+ <cite>
+ Debian's Developers are currently members of SPI by virtue
+ of their status as Developers.
+ </cite>
+ <h3>9.1. Authority</h3>
+ <ol>
+ <li>
+ 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.
+ <li>
+ 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.
+ <li>
+ 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.
+ </ol>
+ <h3>9.2. Management of property for purposes related to Debian</h3>
+ Since Debian has no authority to hold money or property, any
+ donations for the Debian Project must made to SPI, which
+ manages such affairs.
+ <p>
+ SPI have made the following undertakings:
+ <ol>
+ <li>
+ SPI will hold money, trademarks and other tangible and
+ intangible property and manage other affairs for purposes
+ related to Debian.
+ <li>
+ Such property will be accounted for separately and held in
+ trust for those purposes, decided on by Debian and SPI
+ according to this section.
+ <li>
+ 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.
+ <li>
+ SPI will consider using or disposing of property held in trust
+ for Debian when asked to do so by the Project Leader.
+ <li>
+ 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.
+ <li>
+ 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.
+ </ol>
+ <h2>A. Standard Resolution Procedure</h2>
+ These rules apply to communal decisionmaking by committees and
+ plebiscites, where stated above.
+ <h3>A.1. Proposal</h3>
+ The formal procedure begins when a draft resolution is proposed and
+ sponsored, as required.
+ <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>
+ A formal amendment may be accepted by the resolution's
+ proposer, in which case the formal resolution draft is
+ immediately changed to match.
+ <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>
+ 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>
+ 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.
+ <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 mininum discussion period is not
+ restarted.
+ </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>
+ 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.
+ <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(6).
+ <li>
+ 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.
+ </ol>
+ <h3>A.3. Voting procedure</h3>
+ <ol>
+ <li>
+ 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.
+ <li>
+ 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.
+ <li>
+ 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.
+ <li>
+ 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.
+ <li>
+ The votes are counted according to the Concorde Vote
+ Counting. If a quorum is required then the default option
+ is Further Discussion.
+ <li>
+ In cases of doubt the Project Secretary shall decide on
+ matters of procedure (for example, whether particular
+ amendments should be considered independent or not).
+ </ol>
+ <h3>A.4. Withdrawing resolutions or unaccepted amendments</h3>
+ 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>
+ A sponsor of a resolution or amendment (unless it has been
+ accepted) may withdraw.
+ <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.
+ <h3>A.5. Expiry</h3>
+ 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.
+ <h3>A.6. Concorde Vote Counting</h3>
+ <ol>
+ <li>
+ 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.)
+ <li>
+ Option A is said to Dominate option B if strictly more ballots
+ prefer A to B than prefer B to A.
+ <li>
+ All options which are Dominated by at least one other option
+ are discarded, and references to them in ballot papers will be
+ ignored.
+ <li>
+ If there is any option which Dominates all others then that is
+ the winner.
+ <li>
+ If there is now more than one option remaining Single
+ Transferrable Vote will be applied to choose amongst those
+ remaining:
+ <ul>
+ <li>
+ The number of first preferences for each option is
+ counted, and if any option has more than half it is the
+ winner.
+ <li>
+ Otherwise the option with the lowest number of first
+ preferences is eliminated and its votes redistributed
+ according to the second preferences.
+ <li>
+ 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.
+ </ul>
+ <li>
+ 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.
+ <li>
+ 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.
+ <cite>
+ This means that a 2:1 vote, for example, means twice as many
+ people voted for as against; abstentions are not counted.
+ </cite>
+ <li>
+ 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.
+ </ol>
+ <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>
+ <h2>B. Use of language and typography</h2>
+ 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.
+ <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>
+<HR>
+<P>Back to the <A href="../">Debian GNU/Linux homepage</A>.
+<HR>
+<SMALL>See the Debian <a href="../contact">contact page</a> for information on contacting us.</SMALL><P>
+<SMALL>Last Modified: Thu, Dec 10 03:36:32 UTC 1998<BR>
+Copyright © 1997-1999 <a href="http://www.spi-inc.org/">SPI</a>; See <a href="../license">license terms</A> </SMALL>
+</BODY>
+</HTML>
~ianmdlvl / developers-reference.git / blobdiff