diff options
Diffstat (limited to 'includes/etch/common/doc/constitution.txt')
| -rw-r--r-- | includes/etch/common/doc/constitution.txt | 600 |
1 files changed, 0 insertions, 600 deletions
diff --git a/includes/etch/common/doc/constitution.txt b/includes/etch/common/doc/constitution.txt deleted file mode 100644 index 96ed0c7..0000000 --- a/includes/etch/common/doc/constitution.txt +++ /dev/null @@ -1,600 +0,0 @@ - Historical version of the Constitution for the Debian Project (v1.2) - - Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 - ratified on June 21st, 2003, which itself supersedes Version 1.0 - ratified on December 2nd, 1998. Superseded by version 1.3, ratified on - September 24th, 2006. That was superceded by the current version, 1.4 - ratified on October 7th, 2007. - -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 - decision-making 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 decision-making process. - -2. Decision-making 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 - decision-making. 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 §4.1(3), - §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, supersede and withdraw 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. - 1. A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes. - 2. The Foundation Documents are the works entitled "Debian Social - Contract" and "Debian Free Software Guidelines". - 3. 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. - 6. Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See §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 §4.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 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, 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. - 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 §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 §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 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 "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 §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 - 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. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §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 decision-making. - 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 (see §9.1.) 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 be 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 decision-making 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 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. - 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 minimum 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 any sponsor of a resolution may call for a vote on - that resolution and all 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(4). - 4. 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. - - A.3. Voting procedure - - 1. 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). - 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - 3. The votes are counted according to the rules in A.6. The default - option is "Further Discussion", unless specified otherwise. - 4. In cases of doubt the Project Secretary shall decide on matters of - procedure. - - 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 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. - - The secretary may also include suggestions on how to proceed, if - appropriate. - - A.6. Vote Counting - - 1. 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. - 2. 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. - 3. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - 1. Given two options A and B, V(A,B) is the number of voters who - prefer option A over option B. - 2. An option A defeats the default option D by a majority ratio - N, if V(A,D) is strictly greater than N * V(D,A). - 3. If a supermajority of S:1 is required for A, its majority - ratio is S; otherwise, its majority ratio is 1. - 4. From the list of undropped options, we generate a list of pairwise - defeats. - 1. An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - 5. From the list of [undropped] pairwise defeats, we generate a set of - transitive defeats. - 1. 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. - 6. We construct the Schwartz set from the set of transitive defeats. - 1. 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. - 7. 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. - 1. 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). - 2. A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - 8. 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. - - Note: 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. - - 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. "ay" 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. |