]> git.donarmstrong.com Git - debian-ctte.git/commitdiff
Merge GR drafts as our subdirectory
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Thu, 26 Jul 2012 12:04:16 +0000 (13:04 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Thu, 26 Jul 2012 12:04:16 +0000 (13:04 +0100)
1  2 
dir=636783_supermajority/.gitignore
dir=636783_supermajority/amend-propose
dir=636783_supermajority/constitution.html
dir=636783_supermajority/informal-propose
dir=636783_supermajority/numberfix-propose
dir=636783_supermajority/overrule-propose
dir=636783_supermajority/supermajority-propose

index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..b25c15b81fae06e1c55946ac6270bfdb293870e8
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,1 @@@
++*~
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..5682097113268cb2a9dd678a8757766c0fe2a044
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,26 @@@
++
++2. It is not practical for the TC to vote to accept/reject individual
++   amendments to the GR proposal.  The TC would wish to delegate its
++   power to accept amendments, to avoid needing the collection of
++   sponsors for uncontroversial changes.  However the Secretary has
++   advised that this is not constitutionally acceptable.
++
++   Therefore, to achieve roughly the same effect, the TC makes the
++   following promise.  If any TC member gives notice that the TC
++   accepts an amendment, then at least one of the following will
++   happen:
++
++     (a) the TC will use its own power under A.1(1) to arrange that
++         the amendment appears on the GR ballot as an option;
++
++     (b) the TC will use its power under A.1(1) to propose and
++         its power under A.1(2) to accept the amendment, so that
++         the amendment is incorporated in the version voted on; or
++
++     (c) A member of the TC will publicly notify the amendment's
++         proposer that the amendment will not be accepted after all.
++         In this case TC will wait at least 7 more days before calling
++         for a vote, to give time for the amendment's proposer to
++         collect sponsors.
++
++===== TC RESOLUTION ENDS =====
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..a87c74cc37bc0cbc6231f9cb780b49f17782cf9f
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,924 @@@
++<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
++<html lang="en">
++<head>
++  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
++  <title>    Debian Constitution </title>
++  <link rev="made" href="mailto:webmaster@debian.org">
++  <meta name="Generator" content="WML 2.0.11 (19-Aug-2006)">
++  <meta name="Modified" content="2012-04-07 16:04:12">
++  <meta name="viewport" content="width=device-width">
++  <meta name="mobileoptimized" content="300">
++  <meta name="HandheldFriendly" content="true">
++<link href="../debian.css" rel="stylesheet" type="text/css">
++  <link href="../debian-en.css" rel="stylesheet" type="text/css" media="all">
++<link rel="search" type="application/opensearchdescription+xml" title="Debian website search" href="../search.en.xml">
++</head>
++<body>
++<div id="header">
++   <div id="upperheader">
++   <div id="logo">
++  <a href="../" title="Debian Home"><img src="../Pics/openlogo-50.png" alt="Debian" width="50" height="61"></a>
++  </div> <!-- end logo -->
++      <div id="searchbox">
++              <form name="p" method="get" action="http://search.debian.org/cgi-bin/omega">
++              <p>
++<input type="hidden" name="DB" value="en">
++                      <input name="P" value="" size="27">
++                      <input type="submit" value="Search">
++              </p>
++              </form>
++      </div>   <!-- end sitetools -->
++ </div> <!-- end upperheader -->
++<!--UdmComment-->
++<div id="navbar">
++<p class="hidecss"><a href="#content">Skip Quicknav</a></p>
++<ul>
++   <li><a href="../intro/about">About Debian</a></li>
++   <li><a href="../distrib/">Getting Debian</a></li>
++   <li><a href="../support">Support</a></li>
++   <li><a href="../devel/">Developers' Corner</a></li>
++</ul>
++</div> <!-- end navbar -->
++<p id="breadcrumbs"><a href="./">Debian Developers' Corner</a>
++ &#x2F;
++Debian Constitution</p>
++</div> <!-- end header -->
++<!--/UdmComment-->
++<div id="content">
++<h1>Debian Constitution</h1>
++<h1>Constitution for the Debian Project (v1.4)</h1>
++<p>Version 1.4 ratified on October 7th, 2007. Supersedes
++<a href="constitution.1.3">Version 1.3</a> ratified on September 24th,
++2006,
++<a href="constitution.1.2">Version 1.2</a> ratified on October 29th,
++2003 and
++<a href="constitution.1.1">Version 1.1</a> ratified on June 21st,
++2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a>
++ratified on December 2nd, 1998.</p>
++<ul class="toc">
++  <li><a href="#item-1">1. Introduction</a></li>
++  <li><a href="#item-2">2. Decision-making bodies and individuals</a></li>
++  <li><a href="#item-3">3. Individual Developers</a></li>
++  <li><a href="#item-4">4. The Developers by way of General Resolution or election</a></li>
++  <li><a href="#item-5">5. Project Leader</a></li>
++  <li><a href="#item-6">6. Technical committee</a></li>
++  <li><a href="#item-7">7. The Project Secretary</a></li>
++  <li><a href="#item-8">8. The Project Leader's Delegates</a></li>
++  <li><a href="#item-9">9. Assets held in trust for Debian</a></li>
++  <li><a href="#item-A">A. Standard Resolution Procedure</a></li>
++  <li><a href="#item-B">B. Use of language and typography</a></li>
++</ul>
++<h2><a name="item-1" id="item-1">1. Introduction</a></h2>
++<p><cite>The Debian Project is an association of individuals who have
++made common cause to create a free operating system.</cite></p>
++<p>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.</p>
++<h2><a name="item-2" id="item-2">2. Decision-making bodies and individuals</a></h2>
++<p>Each decision in the Project is made by one or more of the
++following:</p>
++<ol>
++  <li>The Developers, by way of General Resolution or an election;</li>
++  <li>The Project Leader;</li>
++  <li>The Technical Committee and/or its Chairman;</li>
++  <li>The individual Developer working on a particular task;</li>
++  <li>Delegates appointed by the Project Leader for specific
++  tasks;</li>
++  <li>The Project Secretary.</li>
++</ol>
++<p>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. <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></p>
++<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>
++  <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>
++  <li>
++    <p>A person may leave the Project or resign from a particular post
++    they hold, at any time, by stating so publicly.</p>
++  </li>
++</ol>
++<h2><a name="item-3" id="item-3">3. Individual Developers</a></h2>
++<h3>3.1. Powers</h3>
++<p>An individual Developer may</p>
++<ol>
++  <li>make any technical or nontechnical decision with regard to their
++  own work;</li>
++  <li>propose or sponsor draft General Resolutions;</li>
++  <li>propose themselves as a Project Leader candidate in
++  elections;</li>
++  <li>vote on General Resolutions and in Leadership elections.</li>
++</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>
++  <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
++    &sect;4.1(3), &sect;4.2.</cite></p>
++  </li>
++</ol>
++<h3>3.3. Procedure</h3>
++<p>Developers may make these decisions as they see fit.</p>
++<h2><a name="item-4" id="item-4">4. The Developers by way of General Resolution or election</a></h2>
++<h3>4.1. Powers</h3>
++<p>Together, the Developers may:</p>
++<ol>
++  <li>
++    <p>Appoint or recall the Project Leader.</p>
++  </li>
++  <li>
++    <p>Amend this constitution, provided they agree with a 3:1
++    majority.</p>
++  </li>
++  <li>
++    <p>Make or override any decision authorised by the powers of the Project
++    Leader or a Delegate.</p>
++  </li>
++  <li>
++    <p>Make or override any decision authorised by the powers of the Technical
++    Committee, provided they agree with a 2:1 majority.</p>
++  </li>
++  <li>
++    <p>Issue, supersede and withdraw nontechnical policy documents and
++       statements.</p>
++    <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>
++    <p>They may also include position statements about issues of the
++    day.</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 &sect;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 &sect;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>
++<h2><a name="item-5" id="item-5">5. Project Leader</a></h2>
++<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 &sect;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
++    &sect;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 &sect;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
++       &sect;A.6 of the Standard Resolution Procedure. The quorum is the
++       same as for a General Resolution (&sect;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>
++<h2><a name="item-6" id="item-6">6. Technical committee</a></h2>
++<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 &sect;6.2.)</p>
++  </li>
++  <li>
++    <p>Appoint the Chairman of the Technical Committee.</p>
++    <p>
++       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.
++   </p>
++  </li>
++  <li>
++    <p>The Chairman can stand in for the Leader, together with the
++    Secretary</p>
++    <p>As detailed in &sect;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.</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>If the Technical Committee and the Project Leader agree they
++    may remove or replace an existing member of the Technical
++    Committee.</p>
++  </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 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>
++  <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>
++<h2><a name="item-7" id="item-7">7. The Project Secretary</a></h2>
++<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 Chairman of the
++    Technical Committee.</p>
++    <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>
++  <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 Chairman 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
++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.</p>
++<h2><a name="item-8" id="item-8">8. The Project Leader's Delegates</a></h2>
++<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>
++<h2><a name="item-9" id="item-9">9. Assets held in trust for Debian</a></h2>
++<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 &sect;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="http://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>
++<h2><a name="item-A" id="item-A">A. Standard Resolution Procedure</a></h2>
++<p>These rules apply to communal decision-making by committees and
++plebiscites, where stated above.</p>
++<h3>A.1. 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 strictly greater than N * V(D,A).
++             </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>
++<h2><a name="item-B" id="item-B">B. Use of language and typography</a></h2>
++<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>
++<div class="clr"></div>
++</div> <!-- end content -->
++<div id="footer">
++<hr class="hidecss">
++<p>Back to the <a href="../">Debian Project homepage</a>.</p>
++<hr>
++<!--UdmComment-->
++<div id="pageLang">
++<div id="langSelector">
++This page is also available in the following languages:
++<div id="langContainer">
++ <a href="constitution.da.html" title="Danish" hreflang="da" lang="da" rel="alternate">dansk</a>
++ <a href="constitution.de.html" title="German" hreflang="de" lang="de" rel="alternate">Deutsch</a>
++ <a href="constitution.fr.html" title="French" hreflang="fr" lang="fr" rel="alternate">fran&ccedil;ais</a>
++ <a href="constitution.it.html" title="Italian" hreflang="it" lang="it" rel="alternate">Italiano</a>
++ <a href="constitution.ja.html" title="Japanese" hreflang="ja" lang="ja" rel="alternate">&#26085;&#26412;&#35486;&nbsp;(Nihongo)</a>
++ <a href="constitution.pl.html" title="Polish" hreflang="pl" lang="pl" rel="alternate">polski</a>
++ <a href="constitution.pt.html" title="Portuguese" hreflang="pt" lang="pt" rel="alternate">Portugu&ecirc;s</a>
++ <a href="constitution.sv.html" title="Swedish" hreflang="sv" lang="sv" rel="alternate">svenska</a>
++</div>
++How to set <a href="../intro/cn">the default document language</a>
++</div></div><!--/UdmComment-->
++<hr>
++<div id="footermap">
++<!--UdmComment-->
++<p><strong><a href="/">Home</a></strong></p>
++    <ul id="footermap-cola">
++              <li><a href="../intro/about">About</a>
++                <ul>
++                <li><a href="../social_contract">Social Contract</a></li>
++                <li><a href="../intro/free">Free Software</a></li>
++                <li><a href="../partners/">Partners</a></li>
++                <li><a href="../donations">Donations</a></li>
++                <li><a href="../contact">Contact Us</a></li>
++                </ul>
++              </li>
++      </ul>
++      <ul id="footermap-colb">
++                      <li><a href="../distrib/">Getting Debian</a>
++                        <ul>
++                        <li><a href="../CD/vendors/">CD vendors</a></li>
++                        <li><a href="../CD/">CD ISO images</a></li>
++                        <li><a href="../distrib/netinst">Network install</a></li>
++                        <li><a href="../distrib/pre-installed">Pre-installed</a></li>
++                        </ul>
++                      </li>
++    <li><a href="../distrib/packages">Debian Packages</a></li>
++      </ul>
++      <ul id="footermap-colc">
++              <li><a href="../News/">News</a>
++                <ul>
++                <li><a href="../News/weekly/">Project News</a></li>
++                <li><a href="../events/">Events</a></li>
++                </ul>
++              </li>
++    <li><a href="../doc/">Documentation</a>
++      <ul>
++      <li><a href="../releases/">Release Info</a></li>
++      <li><a href="../releases/stable/installmanual">Installation manual</a></li>
++      <li><a href="../doc/books">Debian Books</a></li>
++      </ul>
++    </li>
++   </ul>
++   <ul id="footermap-cold">
++    <li><a href="../support">Support</a>
++        <ul>
++                        <li><a href="../international/">Debian International</a></li>
++                        <li><a href="../security/">Security Information</a></li>
++                        <li><a href="../Bugs/">Bug reports</a></li>
++                        <li><a href="../MailingLists/">Mailing Lists</a></li>
++                        <li><a href="http://lists.debian.org/">Mailing List Archives</a></li>
++                        <li><a href="../ports/">Ports/Architectures</a></li>
++      </ul>
++    </li>
++</ul>
++<ul id="footermap-cole">
++    <li><a href="../misc/">Miscellaneous</a></li>
++    <li><a href="../intro/help">Help Debian</a></li>
++    <li><a href="../devel/">Developers' Corner</a></li>
++    <li><a href="../sitemap">Site map</a></li>
++    <li><a href="http://search.debian.org/">Search</a></li>
++</ul>
++<!--/UdmComment-->
++</div> <!-- end footermap -->
++<div id="fineprint">
++  <p>To report a problem with the web site, e-mail <a href="mailto:debian-www@lists.debian.org">debian-www@lists.debian.org</a>. For other contact information, see the Debian <a href="../contact">contact page</a>. Web site source code is <a href="../devel/website/using_cvs">available</a>.</p>
++<p>
++Last Modified: Sun, Oct 2 14:42:25 UTC 2011
++  <br>
++  Copyright &copy; 1997-2011
++ <a href="http://www.spi-inc.org/">SPI</a> and others; See <a href="../license" rel="copyright">license terms</a><br>
++  Debian is a registered <a href="../trademark">trademark</a> of Software in the Public Interest, Inc.
++</p>
++</div>
++</div> <!-- end footer -->
++</body>
++</html>
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..89527f62ba3f008d5bbbe72715ea6e6cb20ae010
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,41 @@@
++===== TC RESOLUTION STARTS =====
++
++1. The Debian Technical Committee hereby exercises its power in
++   4.2(1) of the Debian Constitution to propose the following
++   General Resolution:
++
++   ----- GENERAL RESOLUTION STARTS -----
++
++   Constitutional Amendment: Permit TC to hold informal private conversations
++
++   On a number of occasions recently, enquirers have emailed TC
++   members' personal addreses to informally seek members' views.  This
++   has worked well; however it is not clear that Constitution permits
++   it.  This situation should be regularised.
++
++   On occasion the TC has been asked to decide on maintainership of
++   packages.  It is very difficult to hold the necessary discussions,
++   which inevitably involve discussion of personalities, in public.
++
++   At the moment the TC is unable to take on a mediation role, since
++   mediation necessarily involves each party to a dispute conversing
++   privately with the mediator.  The TC should be able to mediate if
++   the TC, and parties to a dispute, wish it to do so.
++
++   Actual decisionmaking must still place in public of course.
++
++   Therefore, amend the Debian Constitution 6.3 as follows (wdiff -i):
++
++     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.
++
++        [+<cite>The Technical Committee should limit private
++        discussions to situations where holding the conversation in
++        public would be infeasible or counterproductive.</cite>+]
++
++   ----- GENERAL RESOLUTION ENDS -----
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..33979763c11e3130547a630a1331843560470f3c
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,19 @@@
++===== TC RESOLUTION STARTS =====
++
++1. The Debian Technical Committee hereby exercises its power in
++   4.2(1) of the Debian Constitution to propose the following
++   General Resolution:
++
++   ----- GENERAL RESOLUTION STARTS -----
++
++   Constitutional Amendment: Fix duplicate section numbering.
++
++   The current Debian Constitution has two sections numbered A.1.
++   This does not currently give rise to any ambiguity but it is
++   undesirable.
++
++   Fix this with the following semantically neutral amendment:
++
++    - Renumber the first section A.1 to A.0.
++
++   ----- GENERAL RESOLUTION ENDS -----
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..631e10b9ab622b6b150d630f103aaec23ac81f3b
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,33 @@@
++=== TC RESOLUTION STARTS ===
++
++1. The Debian Technical Committee hereby exercises its power in 4.2(1)
++   of the Debian Constitution to propose a General Resolution,
++   and according to A.1(1) the TC also proposes an amendment.
++
++   The proposed texts of the two resulting options for the General
++   Resolution are as follows:
++
++   ----- GENERAL RESOLUTION STARTS, COMMON INTRODUCTORY TEXT -----
++
++   Advice to the TC on overruling maintainers
++
++   In the past the Technical Committee have been reluctant to overrule
++   a maintainer unless all the members are absolutely convinced that
++   the maintainer's decision was wrong.
++
++   The TC has sought the views of the Developers.  Accordingly, the
++   Developers advise, in their (non-binding) opinion, that:
++
++   ----- GENERAL RESOLUTION OPTION A -----
++
++   The Technical Committee's approach so far has been correct.
++
++   ----- GENERAL RESOLUTION OPTION B -----
++
++   Technical Committee members should be willing to vote to overrule if
++   they feel that the maintainer's decision was wrong; the
++   supermajority requirement is sufficient to guard against overruling
++   in questionable cases.
++
++   ----- GENERAL RESOLUTION ENDS -----
++
index 0000000000000000000000000000000000000000,0000000000000000000000000000000000000000..5f765925dfc1709b27d1ca3c33d45f4ac22d922f
new file mode 100644 (file)
--- /dev/null
--- /dev/null
@@@ -1,0 -1,0 +1,71 @@@
++=== TC RESOLUTION STARTS ===
++
++1. The Debian Technical Committee hereby exercises its power in
++   4.2(1) of the Debian Constitution to propose the following
++   General Resolution:
++
++   ----- GENERAL RESOLUTION STARTS -----
++
++   Constitutional Amendment- TC Supermajority Fix
++
++   Prior to the Clone Proof SSD GR in June 2003, the Technical
++   Committee could overrule a Developer with a supermajority of 3:1.
++
++   Unfortunately, the definition of supermajorities in the SSD GR has a
++   fencepost error.  In the new text a supermajority requirement is met
++   only if the ratio of votes in favour to votes against is strictly
++   greater than the supermajority ratio.
++
++   In the context of the Technical Committee voting to overrule a
++   developer that means that it takes 4 votes to overcome a single
++   dissenter.  And with a maximum committee size of 8, previously two
++   dissenters could be overruled by all 6 remaining members; now that
++   is no longer possible.
++
++   This change was unintentional, was contrary to the original intent
++   of the Constitution, and is unhelpful.
++
++   Therefore, amend the Debian Constitution as follows:
++
++   (i) Replace "majority" with "supermajority" everywhere a ratio
++   other than 1:1 is specified.  That is, in
++      4.1(2) -- Developers' power to amend the Constitution
++      4.1(4) -- Developers' power to overrule the TC
++      4.1(5)(3) -- Developers' power to amend Foundation Documents
++      6.1(4) -- TC's power to overrule a Developer (both occurrences)
++   replace the word "majority" with "supermajority".
++
++   (ii) In A.6(3):
++
++       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.
++    +      2. An option A defeats the default option D by its
++    +         required majority ratio if both:
++    +          (a) V(A,D) is strictly greater than V(D,A); and
++    +          (b) if a supermajority of N:M is required for A,
++    +              M * V(A,D) is greater than or equal to N * V(D,A).
++
++   (iii) In A.3(2) "Voting procedure", delete as follows:
++       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.
++
++   The effect is to fix the fencepost bug, and make the wording
++   consistent, by always referring to "supermajorities" where
++   applicable.  A 1:1 vote will need strictly more in favour than
++   against, but an N:1 vote will need only exactly N:1.  This will
++   also have a (negligible) effect on any General Resolutions
++   requiring supermajorities.
++
++   For the avoidance of any doubt, this change does not affect any
++   votes (whether General Resolutions or votes in the Technical
++   Committee) in progress at the time the change is made.
++
++   ----- GENERAL RESOLUTION ENDS -----