+++ /dev/null
-<!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>
- /
-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
- §4.1(3), §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 §9.).</p>
- </li>
- <li>
- <p>In case of a disagreement between the project leader and
- the incumbent secretary, appoint a new secretary.</p>
- </li>
-</ol>
-<h3>4.2. Procedure</h3>
-<ol>
- <li>
- <p>The Developers follow the Standard Resolution Procedure, below.
- A resolution or amendment is introduced if proposed by any
- Developer and sponsored by at least K other Developers, or if
- proposed by the Project Leader or the Technical Committee.</p>
- </li>
- <li>
- <p>Delaying a decision by the Project Leader or their Delegate:</p>
- <ol>
- <li>If the Project Leader or their Delegate, or the Technical
- Committee, has made a decision, then Developers can override them
- by passing a resolution to do so; see §4.1(3).</li>
- <li>If such a resolution is sponsored by at least 2K Developers,
- or if it is proposed by the Technical Committee, the resolution
- puts the decision immediately on hold (provided that resolution
- itself says so).</li>
- <li>If the original decision was to change a discussion period or
- a voting period, or the resolution is to override the Technical
- Committee, then only K Developers need to sponsor the resolution
- to be able to put the decision immediately on hold.</li>
- <li>If the decision is put on hold, an immediate vote is held to
- determine whether the decision will stand until the full vote on
- the decision is made or whether the implementation of the
- original decision will be delayed until then. There is no
- quorum for this immediate procedural vote.</li>
- <li>If the Project Leader (or the Delegate) withdraws the
- original decision, the vote becomes moot, and is no longer
- conducted.</li>
- </ol>
- </li>
- <li>
- <p>
- Votes are taken by the Project Secretary. Votes, tallies, and
- results are not revealed during the voting period; after the
- vote the Project Secretary lists all the votes cast. The voting
- period is 2 weeks, but may be varied by up to 1 week by the
- Project Leader.
- </p>
- </li>
- <li>
- <p>The minimum discussion period is 2 weeks, but may be varied by
- up to 1 week by the Project Leader. The Project Leader has a
- casting vote. There is a quorum of 3Q.</p>
- </li>
- <li>
- <p>Proposals, sponsors, amendments, calls for votes and other
- formal actions are made by announcement on a publicly-readable
- electronic mailing list designated by the Project Leader's
- Delegate(s); any Developer may post there.</p>
- </li>
- <li>
- <p>Votes are cast by email in a manner suitable to the Secretary.
- The Secretary determines for each poll whether voters can change
- their votes.</p>
- </li>
- <li>
- <p>Q is half of the square root of the number of current
- Developers. K is Q or 5, whichever is the smaller. Q and K need not
- be integers and are not rounded.</p>
- </li>
-</ol>
-<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 §6.2.)</p>
- </li>
- <li>
- <p>Use a casting vote when Developers vote.</p>
- <p>The Project Leader also has a normal vote in such ballots.</p>
- </li>
- <li>
- <p>Vary the discussion period for Developers' votes (as above).</p>
- </li>
- <li>
- <p>Lead discussions amongst Developers.</p>
- <p>The Project Leader should attempt to participate in discussions
- amongst the Developers in a helpful way which seeks to bring the
- discussion to bear on the key issues at hand. The Project Leader
- should not use the Leadership position to promote their own
- personal views.</p>
- </li>
- <li>
- <p>In consultation with the developers, make decisions affecting
- property held in trust for purposes related to Debian. (See
- §9.). Such decisions are communicated to the members by the
- Project Leader or their Delegate(s). Major expenditures
- should be proposed and debated on the mailing list before
- funds are disbursed.</p>
- </li>
- <li>
- <p>Add or remove organizations from the list of trusted
- organizations (see §9.3) that are authorized to accept and
- hold assets for Debian. The evaluation and discussion leading
- up to such a decision occurs on an electronic mailing list
- designated by the Project Leader or their Delegate(s), on
- which any developer may post. There is a minimum discussion
- period of two weeks before an organization may be added to
- the list of trusted organizations.</p>
- </li>
-</ol>
-<h3>5.2. Appointment</h3>
-<ol>
- <li>The Project Leader is elected by the Developers.</li>
- <li>The election begins six weeks before the leadership post becomes
- vacant, or (if it is too late already) immediately.</li>
- <li>For the first week any Developer may nominate
- themselves as a candidate Project Leader, and summarize their plans for their term.</li>
- <li>For three weeks after that no more candidates may be nominated;
- candidates should use this time for campaigning and discussion. If
- there are no candidates at the end of the nomination period then the
- nomination period is extended for an additional week, repeatedly if
- necessary.</li>
- <li>The next two weeks are the polling period during which
- Developers may cast their votes. Votes in leadership elections are
- kept secret, even after the election is finished.</li>
- <li>The options on the ballot will be those candidates who have
- nominated themselves and have not yet withdrawn, plus None Of The
- Above. If None Of The Above wins the election then the election
- procedure is repeated, many times if necessary.</li>
- <li>
- The decision will be made using the method specified in section
- §A.6 of the Standard Resolution Procedure. The quorum is the
- same as for a General Resolution (§4.2) and the default
- option is <q>None Of The Above</q>.
- </li>
- <li>The Project Leader serves for one year from their election.</li>
-</ol>
-<h3>5.3. Procedure</h3>
-<p>The Project Leader should attempt to make decisions which are
-consistent with the consensus of the opinions of the Developers.</p>
-<p>Where practical the Project Leader should informally solicit the
-views of the Developers.</p>
-<p>The Project Leader should avoid overemphasizing their own point of
-view when making decisions in their capacity as Leader.</p>
-<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 §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 §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 §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ç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">日本語 (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ê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 © 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>
+++ /dev/null
-Subject: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
-To: debian-vote@lists.debian.org
-
-Hi together,
-
-we (as the Technical Committee) have encountered two bugs in the
-constitution which we like to fix. For this reason, I propose the following
-General Resolution to change the constitution.
-
-Please note that we put both issues into one GR proposal; however, if we
-notice one of the issues generates too much discussion, we will separate
-the proposals.
-
-
-
-Regards,
-Andi
-
-
-[ include text from both proposals as one GR here ]
+++ /dev/null
- ----- 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 -----
+++ /dev/null
- ----- 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 -----
+++ /dev/null
- ----- 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 outvoted 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.
-
- Additionally, following discussion of the supermajority mechanism
- within the project, it was realised that certain situations could
- cause anomalous results:
-
- * The existing rules might result in a GR or TC resolution passing
- which was actually the diametric opposite of the majority view.
-
- * The existing rules unintentionally privilege the default option
- in evenly contested TC votes where no supermajority is required,
- possibly encouraging tactical voting.
-
- Therefore, amend the Debian Constitution as follows:
-
- (i) Delete most of A.6(3) (which implemented the supermajority
- by dropping options at an early stage). Specifically:
- - Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
- A.6(3)(0) before A.6(3)(1).
- - Remove the rest of A.6(3) entirely, leaving A.6(2) to be
- followed by A.6(4).
-
- (ii) In A.6(8) replace all occurrences of "winner" with
- "prospective winner". Replace "wins" in "which of those options
- wins" with "is the prospective winner".
-
- (iii) In A.6(8) add a new sentence at the end:
- + If there is no elector with a casting vote, the default option
- + wins.
-
- (iv) Add a new section A.6(9) after A.6(8):
- + 9. 1. If the prospective winner W has no majority requirement,
- + or defeats the default option D by its majority
- + requirement, the prospective winner is the actual winner.
- + 2. Otherwise, the motion has failed its supermajority with
- + the consequences set out alongside the majority
- + requirement (or, if unspecified, the default option
- + wins).
- + 3. An option A defeats the default option D by a
- + majority of N:M if M * V(A,D) is greater than or equal to
- + N * V(D,A).
-
- (v) In
- * 6.1(4) (Technical Commitee power to overrule a Developer)
- * 4.1(4) (Developers' use of TC powers by GR) (if another
- constitutional amendment has not abolished that
- supermajority requirement)
- in each case after the "N:M majority" add
- + ; failing that, the prospective winning resolution text becomes
- + a non-binding statement of opinion.
-
- (vi) In A.3(2) 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.
-
- 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.
-
- The effect is to fix the fencepost bug, and arrange that failing a
- supermajority voids the whole decision (or makes it advisory),
- rather than promoting another option. The fencepost bugfix will
- also have a (negligible) effect on any General Resolutions
- requiring supermajorities. And after this change the TC chair can
- choose a non-default option even if it is tied with a default
- option.
-
- ----- GENERAL RESOLUTION ENDS -----
+++ /dev/null
-===== TITLE
-
-Debian Menu System
-
-===== WEB SUMMARY
-
-The technical committee adopts the changes to policy regarding menu
-entries proposed by Charles Plessy, and additionally resolves that
-packages providing desktop files shall not also provide a menu file.
-
-===== EMAIL INTRO
-
-The technical committee was asked in #741573 to decide an issue of
-Debian technical policy regarding menu regarding the menu system.
-
-===== EMAIL EPILOGUE
-
-The technical committee would like to thank everyone who participated
-in the discussion of #741573 and the patience of the Policy Editors as
-the technical committee worked through this issue very slowly.
-
-===== DECISION
-
-Whereas:
-
- 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
- package provides a standard interface between packages providing
- applications and "menu programs"'. It further states that 'All
- packages that provide applications that need not be passed any
- special command line arguments for normal operations should
- register a menu entry for those applications'.
-
- 2. All details about menu system requirement are delegated to the
- Debian Menu sub-policy and Debian Menu System manuals (the
- "Debian menu system").
-
- 3. An external specification, the Freedesktop Desktop Entry
- Specification (the ".desktop spec"), with native support in many
- X desktop environments, has appeared since the Debian Menu
- system was developed. The .desktop spec offers a fairly strict
- super-set of Debian Menu system functionality.
-
- 4. The .desktop specification has significant technical benefits
- for users over the Debian menu system. The .desktop
- specification works together with the freedesktop.org mime type
- and icon specifications to provide operations expected by
- desktop users from other environments, such as Mac OS X or
- Windows. As such, applications must provide a .desktop file to
- operate well in most desktop environments.
-
- 5. The Debian Technical Committee has been asked to resolve a
- dispute between maintainers of Debian Policy over a change that
-
- i. incorporates the description of the FreeDesktop menu system
- and its use in Debian for listing program in desktop menus
- and associating them with media types
-
- ii. softens the wording on the Debian Menu system to reflect that
- in Jessie it will be neither displayed nor installed by
- default on standard Debian installations.
-
- Therefore:
-
- The Technical Committee has reviewed the underlying technical
- issues around this question and has resolved that Debian will be
- best served by migrating away from our own Debian Menu System and
- towards the common Freedesktop Desktop Entry Specification, and
- that menu information for applications should not be duplicated in
- two different formats.
-
- To encourage this change, we make menu files optional, ask that
- packages include .desktop files as appropriate and prohibit
- packages from providing both menu and .desktop files for the same
- application.
-
-Using its power under §6.1.1 to decide on any matter of technical
-policy, and its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee adopts the changes proposed by Charles
- Plessy in ba679bff[1].
-
- 2. In addition to those changes, the Technical Committee resolves
- that packages providing a .desktop file shall not also provide a
- menu file for the same application.
-
- 3. We further resolve that "menu programs" should not depend on the
- Debian Menu System and should instead rely on .desktop file
- contents for constructing a list of applications to present to
- the user.
-
- 4. We advise the maintainers of the 'menu' package to update that
- package to reflect this increased focus on .desktop files by
- modifying the 'menu' package to use .desktop files for the
- source of menu information in addition to menu files.
-
- 5. Discussion of the precise relationship between menu file
- section/hints values and .desktop file Categories values may be
- defined within the Debian Menu sub-policy and Debian Menu
- System.
-
- 6. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+++ /dev/null
-Whereas:
-
- 1. The Debian Technical Committee has been asked to resolve a
- dispute between maintainers of Debian Policy over a change that
-
- i. incorporates the description of the FreeDesktop menu system
- and its use in Debian for listing program in desktop menus
- and associating them with media types
-
- ii. softens the wording on the Debian Menu system to reflect that
- in Jessie it will be neither displayed nor installed by
- default on standard Debian installations.
-
- Using its power under §6.1.1 to decide matters of technical policy:
-
-OPTION A:
-
- 1. The Technical Committee adopts the changes proposed by Charles
- Plessy in ba679bff[1].
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
-
-Using its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee suggests that the maintainers of the
- Debian menu package support translating .desktop files of
- packages which do not provide menu files.
-
-
-OPTION B:
- 1. Considers that the policy procedure resulted in consensus, and
- adopts the changes proposed by Charles Plessy in ba67bff.[1]
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
-
-Using its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee suggests that the maintainers of the
- Debian menu package support translating .desktop files of
- packages which do not provide menu files.
-
-OPTION C:
-
- 1. The Technical Committee adopts the changes proposed by Bill
- Allombert.[1]
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446
-
-OPTION Z:
-
-Further discussion
+++ /dev/null
-
- Context
-
- 1. A dispute about the status of menu systems in Debian, and the
- contents of policy, has been referred to the Committee.
-
- 2. There are currently two menu systems in Debian: the
- freedesktop.org (.desktop file based) system, and the traditional
- Debian menu system.
-
- 3. These two systems have, in general: different maintainers and
- proponents; often different users; different intended scopes (in
- the sense of what subset of packages in Debian should provide
- menu entries); a different emphasis.
-
- 4. The two systems make different choices in response to the need
- for various technical tradeoffs. The traditional Debian menu is
- less feature rich, but is easier for a menu consumer.
-
- Philosophy
-
- 5. Where feasible, there should be room in Debian for competing
- implementations of similar functionality; especially when they
- have different but overlapping sets of goals. The contributors
- to each should be enabled to do their work, so long as the cost
- for the project as a whole is reasonable.
-
- Conclusions
-
- 6. Both menu systems should be documented in policy.
-
- 7. The documentation for each menu system (specifying file formats,
- when to include a menu entry, etc.) should follow the views of
- Debian's experts on, and contributors to, each system.
-
- 8. Lack of an entry in one or other menu system, where that system's
- scope calls for an entry to be provided, is a bug. But it is not
- a release critical bug.
-
- 9. A maintainer should not be criticised for providing a package
- without doing the work to provide all the applicable menu
- entries. However, a maintainer who is offered a reasonable patch
- should accept it.
-
- 10. We request that the policy team implement this decision. We
- leave the specific details of the wording to the policy team.
-
+++ /dev/null
-In an effort to make progress in the discussion, I thought I'd start
-by listing as many of the potential ballot items as I could think of
-and get concensus on which should be removed, so that we could bring
-the remaining list to a vote.
-
-A suitable edit to §9.6 of the policy manual for each option would be
-generated before ballot was written, but I think the wording is
-"obvious" from the contents below:
-
-1)
- Require menu
- Disallow desktop
-2)
- Require menu
- Allow desktop files
-3)
- Require none
- Allow either
-4)
- Require one of menu/desktop
- Allow other
-5)
- Allow menu
- Require desktop
-6)
- Disallow menu
- Require desktop
-7)
- Refuse to rule
-8)
- FD
+++ /dev/null
- Whereas:
-
- 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
- package provides a standard interface between packages providing
- applications and "menu programs"'. It further states that 'All
- packages that provide applications that need not be passed any
- special command line arguments for normal operations should
- register a menu entry for those applications'.
-
- 2. All details about menu system requirement are delegated to the
- Debian Menu sub-policy and Debian Menu System manuals (the
- "Debian menu system").
-
- 3. An external specification, the Freedesktop Desktop Entry
- Specification (the ".desktop spec"), with native support in many
- X desktop environments, has appeared since the Debian Menu
- system was developed. The .desktop spec offers a fairly strict
- super-set of Debian Menu system functionality.
-
- 4. The .desktop specification has significant technical benefits
- for users over the Debian menu system. The .desktop
- specification works together with the freedesktop.org mime type
- and icon specifications to provide operations expected by
- desktop users from other environments, such as Mac OS X or
- Windows. As such, applications must provide a .desktop file to
- operate well in most desktop environments.
-
- 5. The Debian Technical Committee has been asked to resolve a
- dispute between maintainers of Debian Policy over a change that
-
- i. incorporates the description of the FreeDesktop menu system
- and its use in Debian for listing program in desktop menus
- and associating them with media types
-
- ii. softens the wording on the Debian Menu system to reflect that
- in Jessie it will be neither displayed nor installed by
- default on standard Debian installations.
-
- Therefore:
-
- 1. The Technical Committee resolves that packages which provide
- applications customarily designed for use within a desktop
- environment should provide a .desktop file conforming to the
- Freedesktop Desktop Entry Specification.
-
- 2. Packages may provide menu files at the pleasure of the
- maintainer, but packages providing a .desktop file shall not
- also provide a menu file.
-
- 2. We further resolve that "menu programs" should not depend on the
- Debian Menu System and should instead rely on .desktop file
- contents for constructing a list of applications to present to
- the user.
-
- 3. We recommend that the maintainers of the 'menu' package update
- that package to reflect this increased focus on .desktop files
- by modifying the 'menu' package to use .desktop files for the
- source of menu information in addition to menu files.
-
- 4. Discussion of the precise relationship between menu file
- section/hints values and .desktop file Categories values may be
- defined within the Debian Menu sub-policy and Debian Menu
- System.
-
-The following information is an informative addition to help describe
-the motivation for this policy change.
-
- A. The .desktop spec provides more functionality:
-
- a) Associating mime types with applications
- b) Support for more icon image formats
- c) Translation of menu items
- d) D-Bus application activation
- e) StartupNotify support
-
- B. Support for the .desktop spec is widely provided as part of
- upstream packaging for desktop applications.
-
- C. A .desktop file describe in the .desktop spec captures
- essentially the same information as that present in the Debian
- menu system:
-
- menu .desktop Notes
- ?package TryExec [0]
- title Name / GenericName [1]
- needs Terminal [2]
- section Catagories [3]
- command Exec
- icon Icon [4]
- hints Catagories [5]
-
- Notes
-
- [0] ?package uses Debian package names, TryExec offers a
- system-independent mechanism using a special program or
- mode of the existing program to query whether the
- dependencies to run the application are satisfied
-
- [1] GenericName can offer a brief functional description of a
- program, much like the Debian alternatives for things like
- www-browser
-
- [2] needs adds 'vc' and 'wm' classifications, a .desktop file
- does not anticipate running applications on virtual consoles
- as a separate notion from within an X. I'll note that the
- only package on my system with needs="vc" is psmisc for the
- pstree application, which runs just fine in any X terminal
- emulator. Also .desktop files do not expect people to switch
- window managers during a session.
-
- [3] The menu file requires that the package define the entire
- menu path to the entry, while the .desktop file defines only
- the Catagories within the menu, which allows the user
- environment to construct its own presentation method
-
- [4] Menu files allow only for xpm format icons while
- .desktop files support a wide variety of image formats,
- including png jpg and svg. Menu files also limit the size of
- icons to 32x32, which can be painfully small on higher
- resolution monitors, or less detailed when scaled to large
- sizes.
-
- [5] Because the .desktop specification does not enforce a
- particular layout of menu entries, applications are
- encouraged to specify as many 'categories' as they like and
- have the menu system pick where to include them. This can
- easily include policies like that described for the hints
- field in the Debian menu.
-
- D. .desktop files also provide additional fields not present in
- the Debian menu system:
-
- Type Application, Link or Directory. The latter two
- provide a common format for storing references
- to non-application objects within the desktop
- environment.
-
- NoDisplay An artifact of the ability to handle
- content-based application launching; a
- NoDisplay entry isn't shown in the menu
- system, but is available for handling Mime types.
-
- Comment Offered as a tooltip to the user, providing
- additional details about the application.
-
- Hidden An artifact of the implementation allowing
- users to selectively disable system menu entries
-
- OnlyShowIn/ Allows desktop-system specific applications to not
- NotShowIn appear in other desktop environments, such as
- desktop system preferences systems.
-
- DBusActivatable Whether the application supports standard
- D-Bus messages to control the application, including
- the ability to direct applications to open
- additional files or perform other operations
-
- Path The starting directory for the application. I
- haven't found any .desktop file using this
- feature, but it is replicates functionality
- present in Mac OSX and Windows.
-
- Actions Similar to a mechanism provided on Windows
- where you can list many different operations
- available from a single application, such as
- "open", "print", "play", "frobnicate" and
- Windows automatically adds these to the
- right-click menu from within explorer.
-
- MimeType The mime types supported by the
- application. This allows the wider system to
- find a application suitable for
- viewing/modifying specific content, such as a
- file browser.
-
- KeyWords Provides tags to allow for some degree of
- search-ability/categorization of menu
- entries. I'd be able to explain this in more
- detail if I could find any examples of it in use.
-
- StartupNotify/ Announces that the application supports the Startup
- StartupWMClass Notification Protocol Specification, which
- allows the desktop environment to detect when
- the application has successfully launched so
- that it can disable the waiting cursor.
-
- URL Used in 'Link' .desktop files to reference an object.
-
- E. .desktop files cede significant authority over menu
- organization to the user agent presenting the overall
- application menu. This is already a reality as many desktop
- environments show *none* of the menu file data at all; having
- applications which currently ship a menu file change to
- shipping a .desktop file will bring them into uniformity with
- other pieces of the desktop environment by incorporating them
- into the existing desktop menu system
-
- F. The .desktop specification and other Freedesktop.org
- specifications relating to mime types and icons are all interrelated
- and work together to provide a system capable of implementing
- common desktop operations. Not providing a .desktop file
- significantly reduces the functionality of the overall
- environment, and so any desktop application must provide the
- full suite. Also delivering a Debian menu file would end up
- duplicating information in potentially conflicting ways.
-
+++ /dev/null
-Whereas:
-
- 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
- package provides a standard interface between packages providing
- applications and "menu programs"'. It further states that 'All
- packages that provide applications that need not be passed any
- special command line arguments for normal operations should
- register a menu entry for those applications'.
-
- 2. All details about menu system requirement are delegated to the
- Debian Menu sub-policy and Debian Menu System manuals (the
- "Debian menu system").
-
- 3. An external specification, the Freedesktop Desktop Entry
- Specification (the ".desktop spec"), with native support in many
- X desktop environments, has appeared since the Debian Menu
- system was developed. The .desktop spec offers a fairly strict
- super-set of Debian Menu system functionality.
-
- 4. The .desktop specification has significant technical benefits
- for users over the Debian menu system. The .desktop
- specification works together with the freedesktop.org mime type
- and icon specifications to provide operations expected by
- desktop users from other environments, such as Mac OS X or
- Windows. As such, applications must provide a .desktop file to
- operate well in most desktop environments.
-
- 5. The Debian Technical Committee has been asked to resolve a
- dispute between maintainers of Debian Policy over a change that
-
- i. incorporates the description of the FreeDesktop menu system
- and its use in Debian for listing program in desktop menus
- and associating them with media types
-
- ii. softens the wording on the Debian Menu system to reflect that
- in Jessie it will be neither displayed nor installed by
- default on standard Debian installations.
-
- Therefore:
-
-
-OPTION A:
-
- 1. The Technical Committee adopts the changes proposed by Charles
- Plessy in ba679bff[1].
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
-
-Using its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee suggests that the maintainers of the
- Debian menu package support translating .desktop files of
- packages which do not provide menu files.
-
-
-OPTION B:
-
- 1. Considers that the policy procedure resulted in consensus, and
- adopts the changes proposed by Charles Plessy in ba67bff.[1]
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
-
-Using its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee suggests that the maintainers of the
- Debian menu package support translating .desktop files of
- packages which do not provide menu files.
-
-
-OPTION C:
-
- 1. The Technical Committee adopts the changes proposed by Bill
- Allombert.[1]
-
- 2. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446
-
-
-OPTION D:
-
- The Technical Committee has reviewed the underlying technical
- issues around this question and has resolved that Debian will be
- best served by migrating away from our own Debian Menu System and
- towards the common Freedesktop Desktop Entry Specification, and
- that menu information for applications should not be duplicated in
- two different formats.
-
- To encourage this change, we make menu files optional, ask that
- packages include .desktop files as appropriate and prohibit
- packages from providing both menu and .desktop files for the same
- application.
-
-Using its power under §6.1.1 to decide on any matter of technical
-policy, and its power under §6.1.5 to offer advice:
-
- 1. The Technical Committee adopts the changes proposed by Charles
- Plessy in ba679bff[1].
-
- 2. In addition to those changes, the Technical Committee resolves
- that packages providing a .desktop file shall not also provide a
- menu file for the same application.
-
- 3. We further resolve that "menu programs" should not depend on the
- Debian Menu System and should instead rely on .desktop file
- contents for constructing a list of applications to present to
- the user.
-
- 4. We advise the maintainers of the 'menu' package to update that
- package to reflect this increased focus on .desktop files by
- modifying the 'menu' package to use .desktop files for the
- source of menu information in addition to menu files.
-
- 5. Discussion of the precise relationship between menu file
- section/hints values and .desktop file Categories values may be
- defined within the Debian Menu sub-policy and Debian Menu
- System.
-
- 6. Further modifications to the menu policy are allowed using the
- normal policy modification process.
-
-[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
-
-OPTION Z:
-
-Further discussion
+++ /dev/null
-digraph Results {
- ranksep=0.25;
- "Option A" [ style="filled" , fontname="Helvetica", fontsize=10 ];
- "Option B" [ style="filled" , fontname="Helvetica", fontsize=10 ];
- "Option C" [ style="filled" , color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
- "Option D" [ style="filled" , color="powderblue", shape=egg, fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
- "Z\nFurther Discussion" [ style="filled" , shape=diamond, fontcolor="Red", fontname="Helvetica", fontsize=10 ];
- "Option B" -> "Option A" [ label="2" ];
- "Option D" -> "Option A" [ label="7" ];
- "Option A" -> "Z\nFurther Discussion" [ label="7" ];
- "Option D" -> "Option B" [ label="7" ];
- "Option B" -> "Z\nFurther Discussion" [ label="5" ];
- "Z\nFurther Discussion" -> "Option C" [ label="5" ];
- "Option D" -> "Z\nFurther Discussion" [ label="7" ];
-}
+++ /dev/null
-#!/bin/sh
-echo "Debian Menu systems"
-../scripts/pocket-devotee \
- --option 'A: adopt changes proposed by Charles Plessy (…)' \
- --option 'B: consider that the procedure resulted in consensus, and adopt changes proposed by Charles Plessy (…)' \
- --option 'C: adopt changes proposed by Bill Allombert (…)' \
- --option 'D: adopt changes proposed by Charles Plessy, additionally resolve that packages providing a .desktop file shall not also provide a menu file (…)' \
- --option 'Z: Further Discussion' \
- --default-option 'Z' \
- --quorum 2 \
- << EOF
-hartmans: D > B > A > Z > C
-don: D > A = B > C > Z
-tfheen: D > A = B > Z > C
-odyx: D > B > A > Z > C
-keithp: D > B > A > Z > C
-bdale: D > A = B > Z > C
-aba: D > A > Z > B > C
-EOF
+++ /dev/null
-To: debian-devel-announce@lists.debian.org
-Subject: Call for (self-)nominations for technical committee seats
-
-First and foremost, the technical committee would like to thank Bdale
-Garbee and Steve Langasek for serving on the committee in addition to
-their many other services to Debian. Given the newly introduced §6.2.7
-"Term limit", both their terms will expire on December 31st 2015, and
-there will be two empty seats which can be filled.
-
-To fill these seats, we are soliciting nominations, including
-self-nominations. To nominate yourself or someone else, please send
-e-mail to debian-ctte-private@debian.org with the subject "CTTE
-Nomination of loginname", where loginname is the nominee's Debian
-account login.[1] Please let us know in the body of the e-mail why the
-nominee would be a good fit for the committee, specifically instances
-where the nominee was able to help resolve disagreements, both
-technical and non-technical.
-
-Being a member of the committee does require a time commitment.
-Members should be able to follow e-mail discussions on an ongoing
-basis and respond within a couple of days so that discussions
-progress. Members should ideally be able to spend 10 hours a month
-for relatively busy months, but typical time requirements will be
-less.
-
-We anticipate starting our selection process on or about the first of
-December. After the selection, the committee will then recommend
-nominees to the project leader, who may appoint the nominees (§6.2).
-
-1: See http://db.debian.org/ if you need to look the login up
+++ /dev/null
-From: Don Armstrong <don@debian.org>
-To:
-Cc: debian-ctte-private@debian.org
-Reply-To: debian-ctte-private@debian.org
-Subject: CTTE Nomination accept/decline
-
-You have been nominated by someone other than yourself to be
-considered for appointment to the Debian Technical Committee.
-
-Please reply to this e-mail indicating if you are (or are not) willing
-to be considered for appointment. Names of accepted nominees will be
-made public.
-
---
-Don Armstrong
+++ /dev/null
-From: Don Armstrong <don@debian.org>
-To: debian-devel-announce@lists.debian.org
-Subject: CTTE Nominations closed; thanks to all nominees for agreeing to serve
-Reply-to: debian-ctte-private@debian.org
-Mail-Followup-To: debian-ctte-private@debian.org
-
-The Technical Committee would like to thank all of the nominees,
-especially those who agreed to serve Debian on the Technical
-Committee. In addition, we also appreciate the effort of everyone who
-nominated someone else and provided information about positive
-interactions with those nominees to the Committee.
-
-The Technical Committee has begun private deliberations, and will
-recommend a nominee to the Project Leader for approval under §6.2.2.
+++ /dev/null
-===== TITLE
-
-Chair of CTTE
-
-===== WEB SUMMARY
-
-Didier Raboud is elected CTTE Chair.
-
-===== EMAIL INTRO
-
-===== EMAIL EPILOGUE
-
-===== DECISION
-
-In 821361, the CTTE held an election for the CTTE Chair after the
-appointment of a new member.[1] Didier Raboud (odyx) was selected as
-the new CTTE Chair.
-
-1: This is not in the constitution, but was discussed and agreed upon
-in #795857 and is documented in procedures.md in the CTTE git
-repository.
+++ /dev/null
-../scripts/pocket-devotee \
- --option 'A: Don Armstrong' \
- --option 'B: Andreas Barth' \
- --option 'C: Phil Hands' \
- --option 'D: Sam Hartman' \
- --option 'E: Tollef Fog Heen' \
- --option 'F: Keith Packard' \
- --option 'G: Didier Raboud' <<EOF
-hartmans: G>B=E>F=D=C>A
-odyx: G>D>A>B=C=E=F
-don: G>A=B=C=D=E=F
-philh: G>A=B=C=E=F
-EOF
--- /dev/null
+<!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>
+ /
+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
+ §4.1(3), §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 §9.).</p>
+ </li>
+ <li>
+ <p>In case of a disagreement between the project leader and
+ the incumbent secretary, appoint a new secretary.</p>
+ </li>
+</ol>
+<h3>4.2. Procedure</h3>
+<ol>
+ <li>
+ <p>The Developers follow the Standard Resolution Procedure, below.
+ A resolution or amendment is introduced if proposed by any
+ Developer and sponsored by at least K other Developers, or if
+ proposed by the Project Leader or the Technical Committee.</p>
+ </li>
+ <li>
+ <p>Delaying a decision by the Project Leader or their Delegate:</p>
+ <ol>
+ <li>If the Project Leader or their Delegate, or the Technical
+ Committee, has made a decision, then Developers can override them
+ by passing a resolution to do so; see §4.1(3).</li>
+ <li>If such a resolution is sponsored by at least 2K Developers,
+ or if it is proposed by the Technical Committee, the resolution
+ puts the decision immediately on hold (provided that resolution
+ itself says so).</li>
+ <li>If the original decision was to change a discussion period or
+ a voting period, or the resolution is to override the Technical
+ Committee, then only K Developers need to sponsor the resolution
+ to be able to put the decision immediately on hold.</li>
+ <li>If the decision is put on hold, an immediate vote is held to
+ determine whether the decision will stand until the full vote on
+ the decision is made or whether the implementation of the
+ original decision will be delayed until then. There is no
+ quorum for this immediate procedural vote.</li>
+ <li>If the Project Leader (or the Delegate) withdraws the
+ original decision, the vote becomes moot, and is no longer
+ conducted.</li>
+ </ol>
+ </li>
+ <li>
+ <p>
+ Votes are taken by the Project Secretary. Votes, tallies, and
+ results are not revealed during the voting period; after the
+ vote the Project Secretary lists all the votes cast. The voting
+ period is 2 weeks, but may be varied by up to 1 week by the
+ Project Leader.
+ </p>
+ </li>
+ <li>
+ <p>The minimum discussion period is 2 weeks, but may be varied by
+ up to 1 week by the Project Leader. The Project Leader has a
+ casting vote. There is a quorum of 3Q.</p>
+ </li>
+ <li>
+ <p>Proposals, sponsors, amendments, calls for votes and other
+ formal actions are made by announcement on a publicly-readable
+ electronic mailing list designated by the Project Leader's
+ Delegate(s); any Developer may post there.</p>
+ </li>
+ <li>
+ <p>Votes are cast by email in a manner suitable to the Secretary.
+ The Secretary determines for each poll whether voters can change
+ their votes.</p>
+ </li>
+ <li>
+ <p>Q is half of the square root of the number of current
+ Developers. K is Q or 5, whichever is the smaller. Q and K need not
+ be integers and are not rounded.</p>
+ </li>
+</ol>
+<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 §6.2.)</p>
+ </li>
+ <li>
+ <p>Use a casting vote when Developers vote.</p>
+ <p>The Project Leader also has a normal vote in such ballots.</p>
+ </li>
+ <li>
+ <p>Vary the discussion period for Developers' votes (as above).</p>
+ </li>
+ <li>
+ <p>Lead discussions amongst Developers.</p>
+ <p>The Project Leader should attempt to participate in discussions
+ amongst the Developers in a helpful way which seeks to bring the
+ discussion to bear on the key issues at hand. The Project Leader
+ should not use the Leadership position to promote their own
+ personal views.</p>
+ </li>
+ <li>
+ <p>In consultation with the developers, make decisions affecting
+ property held in trust for purposes related to Debian. (See
+ §9.). Such decisions are communicated to the members by the
+ Project Leader or their Delegate(s). Major expenditures
+ should be proposed and debated on the mailing list before
+ funds are disbursed.</p>
+ </li>
+ <li>
+ <p>Add or remove organizations from the list of trusted
+ organizations (see §9.3) that are authorized to accept and
+ hold assets for Debian. The evaluation and discussion leading
+ up to such a decision occurs on an electronic mailing list
+ designated by the Project Leader or their Delegate(s), on
+ which any developer may post. There is a minimum discussion
+ period of two weeks before an organization may be added to
+ the list of trusted organizations.</p>
+ </li>
+</ol>
+<h3>5.2. Appointment</h3>
+<ol>
+ <li>The Project Leader is elected by the Developers.</li>
+ <li>The election begins six weeks before the leadership post becomes
+ vacant, or (if it is too late already) immediately.</li>
+ <li>For the first week any Developer may nominate
+ themselves as a candidate Project Leader, and summarize their plans for their term.</li>
+ <li>For three weeks after that no more candidates may be nominated;
+ candidates should use this time for campaigning and discussion. If
+ there are no candidates at the end of the nomination period then the
+ nomination period is extended for an additional week, repeatedly if
+ necessary.</li>
+ <li>The next two weeks are the polling period during which
+ Developers may cast their votes. Votes in leadership elections are
+ kept secret, even after the election is finished.</li>
+ <li>The options on the ballot will be those candidates who have
+ nominated themselves and have not yet withdrawn, plus None Of The
+ Above. If None Of The Above wins the election then the election
+ procedure is repeated, many times if necessary.</li>
+ <li>
+ The decision will be made using the method specified in section
+ §A.6 of the Standard Resolution Procedure. The quorum is the
+ same as for a General Resolution (§4.2) and the default
+ option is <q>None Of The Above</q>.
+ </li>
+ <li>The Project Leader serves for one year from their election.</li>
+</ol>
+<h3>5.3. Procedure</h3>
+<p>The Project Leader should attempt to make decisions which are
+consistent with the consensus of the opinions of the Developers.</p>
+<p>Where practical the Project Leader should informally solicit the
+views of the Developers.</p>
+<p>The Project Leader should avoid overemphasizing their own point of
+view when making decisions in their capacity as Leader.</p>
+<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 §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 §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 §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ç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">日本語 (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ê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 © 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>
--- /dev/null
+Subject: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
+To: debian-vote@lists.debian.org
+
+Hi together,
+
+we (as the Technical Committee) have encountered two bugs in the
+constitution which we like to fix. For this reason, I propose the following
+General Resolution to change the constitution.
+
+Please note that we put both issues into one GR proposal; however, if we
+notice one of the issues generates too much discussion, we will separate
+the proposals.
+
+
+
+Regards,
+Andi
+
+
+[ include text from both proposals as one GR here ]
--- /dev/null
+ ----- 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 -----
--- /dev/null
+ ----- 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 -----
--- /dev/null
+ ----- 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 outvoted 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.
+
+ Additionally, following discussion of the supermajority mechanism
+ within the project, it was realised that certain situations could
+ cause anomalous results:
+
+ * The existing rules might result in a GR or TC resolution passing
+ which was actually the diametric opposite of the majority view.
+
+ * The existing rules unintentionally privilege the default option
+ in evenly contested TC votes where no supermajority is required,
+ possibly encouraging tactical voting.
+
+ Therefore, amend the Debian Constitution as follows:
+
+ (i) Delete most of A.6(3) (which implemented the supermajority
+ by dropping options at an early stage). Specifically:
+ - Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
+ A.6(3)(0) before A.6(3)(1).
+ - Remove the rest of A.6(3) entirely, leaving A.6(2) to be
+ followed by A.6(4).
+
+ (ii) In A.6(8) replace all occurrences of "winner" with
+ "prospective winner". Replace "wins" in "which of those options
+ wins" with "is the prospective winner".
+
+ (iii) In A.6(8) add a new sentence at the end:
+ + If there is no elector with a casting vote, the default option
+ + wins.
+
+ (iv) Add a new section A.6(9) after A.6(8):
+ + 9. 1. If the prospective winner W has no majority requirement,
+ + or defeats the default option D by its majority
+ + requirement, the prospective winner is the actual winner.
+ + 2. Otherwise, the motion has failed its supermajority with
+ + the consequences set out alongside the majority
+ + requirement (or, if unspecified, the default option
+ + wins).
+ + 3. An option A defeats the default option D by a
+ + majority of N:M if M * V(A,D) is greater than or equal to
+ + N * V(D,A).
+
+ (v) In
+ * 6.1(4) (Technical Commitee power to overrule a Developer)
+ * 4.1(4) (Developers' use of TC powers by GR) (if another
+ constitutional amendment has not abolished that
+ supermajority requirement)
+ in each case after the "N:M majority" add
+ + ; failing that, the prospective winning resolution text becomes
+ + a non-binding statement of opinion.
+
+ (vi) In A.3(2) 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.
+
+ 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.
+
+ The effect is to fix the fencepost bug, and arrange that failing a
+ supermajority voids the whole decision (or makes it advisory),
+ rather than promoting another option. The fencepost bugfix will
+ also have a (negligible) effect on any General Resolutions
+ requiring supermajorities. And after this change the TC chair can
+ choose a non-default option even if it is tied with a default
+ option.
+
+ ----- GENERAL RESOLUTION ENDS -----
--- /dev/null
+===== TITLE
+
+Debian Menu System
+
+===== WEB SUMMARY
+
+The technical committee adopts the changes to policy regarding menu
+entries proposed by Charles Plessy, and additionally resolves that
+packages providing desktop files shall not also provide a menu file.
+
+===== EMAIL INTRO
+
+The technical committee was asked in #741573 to decide an issue of
+Debian technical policy regarding menu regarding the menu system.
+
+===== EMAIL EPILOGUE
+
+The technical committee would like to thank everyone who participated
+in the discussion of #741573 and the patience of the Policy Editors as
+the technical committee worked through this issue very slowly.
+
+===== DECISION
+
+Whereas:
+
+ 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
+ package provides a standard interface between packages providing
+ applications and "menu programs"'. It further states that 'All
+ packages that provide applications that need not be passed any
+ special command line arguments for normal operations should
+ register a menu entry for those applications'.
+
+ 2. All details about menu system requirement are delegated to the
+ Debian Menu sub-policy and Debian Menu System manuals (the
+ "Debian menu system").
+
+ 3. An external specification, the Freedesktop Desktop Entry
+ Specification (the ".desktop spec"), with native support in many
+ X desktop environments, has appeared since the Debian Menu
+ system was developed. The .desktop spec offers a fairly strict
+ super-set of Debian Menu system functionality.
+
+ 4. The .desktop specification has significant technical benefits
+ for users over the Debian menu system. The .desktop
+ specification works together with the freedesktop.org mime type
+ and icon specifications to provide operations expected by
+ desktop users from other environments, such as Mac OS X or
+ Windows. As such, applications must provide a .desktop file to
+ operate well in most desktop environments.
+
+ 5. The Debian Technical Committee has been asked to resolve a
+ dispute between maintainers of Debian Policy over a change that
+
+ i. incorporates the description of the FreeDesktop menu system
+ and its use in Debian for listing program in desktop menus
+ and associating them with media types
+
+ ii. softens the wording on the Debian Menu system to reflect that
+ in Jessie it will be neither displayed nor installed by
+ default on standard Debian installations.
+
+ Therefore:
+
+ The Technical Committee has reviewed the underlying technical
+ issues around this question and has resolved that Debian will be
+ best served by migrating away from our own Debian Menu System and
+ towards the common Freedesktop Desktop Entry Specification, and
+ that menu information for applications should not be duplicated in
+ two different formats.
+
+ To encourage this change, we make menu files optional, ask that
+ packages include .desktop files as appropriate and prohibit
+ packages from providing both menu and .desktop files for the same
+ application.
+
+Using its power under §6.1.1 to decide on any matter of technical
+policy, and its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee adopts the changes proposed by Charles
+ Plessy in ba679bff[1].
+
+ 2. In addition to those changes, the Technical Committee resolves
+ that packages providing a .desktop file shall not also provide a
+ menu file for the same application.
+
+ 3. We further resolve that "menu programs" should not depend on the
+ Debian Menu System and should instead rely on .desktop file
+ contents for constructing a list of applications to present to
+ the user.
+
+ 4. We advise the maintainers of the 'menu' package to update that
+ package to reflect this increased focus on .desktop files by
+ modifying the 'menu' package to use .desktop files for the
+ source of menu information in addition to menu files.
+
+ 5. Discussion of the precise relationship between menu file
+ section/hints values and .desktop file Categories values may be
+ defined within the Debian Menu sub-policy and Debian Menu
+ System.
+
+ 6. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
--- /dev/null
+Whereas:
+
+ 1. The Debian Technical Committee has been asked to resolve a
+ dispute between maintainers of Debian Policy over a change that
+
+ i. incorporates the description of the FreeDesktop menu system
+ and its use in Debian for listing program in desktop menus
+ and associating them with media types
+
+ ii. softens the wording on the Debian Menu system to reflect that
+ in Jessie it will be neither displayed nor installed by
+ default on standard Debian installations.
+
+ Using its power under §6.1.1 to decide matters of technical policy:
+
+OPTION A:
+
+ 1. The Technical Committee adopts the changes proposed by Charles
+ Plessy in ba679bff[1].
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+
+Using its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee suggests that the maintainers of the
+ Debian menu package support translating .desktop files of
+ packages which do not provide menu files.
+
+
+OPTION B:
+ 1. Considers that the policy procedure resulted in consensus, and
+ adopts the changes proposed by Charles Plessy in ba67bff.[1]
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+
+Using its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee suggests that the maintainers of the
+ Debian menu package support translating .desktop files of
+ packages which do not provide menu files.
+
+OPTION C:
+
+ 1. The Technical Committee adopts the changes proposed by Bill
+ Allombert.[1]
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446
+
+OPTION Z:
+
+Further discussion
--- /dev/null
+
+ Context
+
+ 1. A dispute about the status of menu systems in Debian, and the
+ contents of policy, has been referred to the Committee.
+
+ 2. There are currently two menu systems in Debian: the
+ freedesktop.org (.desktop file based) system, and the traditional
+ Debian menu system.
+
+ 3. These two systems have, in general: different maintainers and
+ proponents; often different users; different intended scopes (in
+ the sense of what subset of packages in Debian should provide
+ menu entries); a different emphasis.
+
+ 4. The two systems make different choices in response to the need
+ for various technical tradeoffs. The traditional Debian menu is
+ less feature rich, but is easier for a menu consumer.
+
+ Philosophy
+
+ 5. Where feasible, there should be room in Debian for competing
+ implementations of similar functionality; especially when they
+ have different but overlapping sets of goals. The contributors
+ to each should be enabled to do their work, so long as the cost
+ for the project as a whole is reasonable.
+
+ Conclusions
+
+ 6. Both menu systems should be documented in policy.
+
+ 7. The documentation for each menu system (specifying file formats,
+ when to include a menu entry, etc.) should follow the views of
+ Debian's experts on, and contributors to, each system.
+
+ 8. Lack of an entry in one or other menu system, where that system's
+ scope calls for an entry to be provided, is a bug. But it is not
+ a release critical bug.
+
+ 9. A maintainer should not be criticised for providing a package
+ without doing the work to provide all the applicable menu
+ entries. However, a maintainer who is offered a reasonable patch
+ should accept it.
+
+ 10. We request that the policy team implement this decision. We
+ leave the specific details of the wording to the policy team.
+
--- /dev/null
+In an effort to make progress in the discussion, I thought I'd start
+by listing as many of the potential ballot items as I could think of
+and get concensus on which should be removed, so that we could bring
+the remaining list to a vote.
+
+A suitable edit to §9.6 of the policy manual for each option would be
+generated before ballot was written, but I think the wording is
+"obvious" from the contents below:
+
+1)
+ Require menu
+ Disallow desktop
+2)
+ Require menu
+ Allow desktop files
+3)
+ Require none
+ Allow either
+4)
+ Require one of menu/desktop
+ Allow other
+5)
+ Allow menu
+ Require desktop
+6)
+ Disallow menu
+ Require desktop
+7)
+ Refuse to rule
+8)
+ FD
--- /dev/null
+ Whereas:
+
+ 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
+ package provides a standard interface between packages providing
+ applications and "menu programs"'. It further states that 'All
+ packages that provide applications that need not be passed any
+ special command line arguments for normal operations should
+ register a menu entry for those applications'.
+
+ 2. All details about menu system requirement are delegated to the
+ Debian Menu sub-policy and Debian Menu System manuals (the
+ "Debian menu system").
+
+ 3. An external specification, the Freedesktop Desktop Entry
+ Specification (the ".desktop spec"), with native support in many
+ X desktop environments, has appeared since the Debian Menu
+ system was developed. The .desktop spec offers a fairly strict
+ super-set of Debian Menu system functionality.
+
+ 4. The .desktop specification has significant technical benefits
+ for users over the Debian menu system. The .desktop
+ specification works together with the freedesktop.org mime type
+ and icon specifications to provide operations expected by
+ desktop users from other environments, such as Mac OS X or
+ Windows. As such, applications must provide a .desktop file to
+ operate well in most desktop environments.
+
+ 5. The Debian Technical Committee has been asked to resolve a
+ dispute between maintainers of Debian Policy over a change that
+
+ i. incorporates the description of the FreeDesktop menu system
+ and its use in Debian for listing program in desktop menus
+ and associating them with media types
+
+ ii. softens the wording on the Debian Menu system to reflect that
+ in Jessie it will be neither displayed nor installed by
+ default on standard Debian installations.
+
+ Therefore:
+
+ 1. The Technical Committee resolves that packages which provide
+ applications customarily designed for use within a desktop
+ environment should provide a .desktop file conforming to the
+ Freedesktop Desktop Entry Specification.
+
+ 2. Packages may provide menu files at the pleasure of the
+ maintainer, but packages providing a .desktop file shall not
+ also provide a menu file.
+
+ 2. We further resolve that "menu programs" should not depend on the
+ Debian Menu System and should instead rely on .desktop file
+ contents for constructing a list of applications to present to
+ the user.
+
+ 3. We recommend that the maintainers of the 'menu' package update
+ that package to reflect this increased focus on .desktop files
+ by modifying the 'menu' package to use .desktop files for the
+ source of menu information in addition to menu files.
+
+ 4. Discussion of the precise relationship between menu file
+ section/hints values and .desktop file Categories values may be
+ defined within the Debian Menu sub-policy and Debian Menu
+ System.
+
+The following information is an informative addition to help describe
+the motivation for this policy change.
+
+ A. The .desktop spec provides more functionality:
+
+ a) Associating mime types with applications
+ b) Support for more icon image formats
+ c) Translation of menu items
+ d) D-Bus application activation
+ e) StartupNotify support
+
+ B. Support for the .desktop spec is widely provided as part of
+ upstream packaging for desktop applications.
+
+ C. A .desktop file describe in the .desktop spec captures
+ essentially the same information as that present in the Debian
+ menu system:
+
+ menu .desktop Notes
+ ?package TryExec [0]
+ title Name / GenericName [1]
+ needs Terminal [2]
+ section Catagories [3]
+ command Exec
+ icon Icon [4]
+ hints Catagories [5]
+
+ Notes
+
+ [0] ?package uses Debian package names, TryExec offers a
+ system-independent mechanism using a special program or
+ mode of the existing program to query whether the
+ dependencies to run the application are satisfied
+
+ [1] GenericName can offer a brief functional description of a
+ program, much like the Debian alternatives for things like
+ www-browser
+
+ [2] needs adds 'vc' and 'wm' classifications, a .desktop file
+ does not anticipate running applications on virtual consoles
+ as a separate notion from within an X. I'll note that the
+ only package on my system with needs="vc" is psmisc for the
+ pstree application, which runs just fine in any X terminal
+ emulator. Also .desktop files do not expect people to switch
+ window managers during a session.
+
+ [3] The menu file requires that the package define the entire
+ menu path to the entry, while the .desktop file defines only
+ the Catagories within the menu, which allows the user
+ environment to construct its own presentation method
+
+ [4] Menu files allow only for xpm format icons while
+ .desktop files support a wide variety of image formats,
+ including png jpg and svg. Menu files also limit the size of
+ icons to 32x32, which can be painfully small on higher
+ resolution monitors, or less detailed when scaled to large
+ sizes.
+
+ [5] Because the .desktop specification does not enforce a
+ particular layout of menu entries, applications are
+ encouraged to specify as many 'categories' as they like and
+ have the menu system pick where to include them. This can
+ easily include policies like that described for the hints
+ field in the Debian menu.
+
+ D. .desktop files also provide additional fields not present in
+ the Debian menu system:
+
+ Type Application, Link or Directory. The latter two
+ provide a common format for storing references
+ to non-application objects within the desktop
+ environment.
+
+ NoDisplay An artifact of the ability to handle
+ content-based application launching; a
+ NoDisplay entry isn't shown in the menu
+ system, but is available for handling Mime types.
+
+ Comment Offered as a tooltip to the user, providing
+ additional details about the application.
+
+ Hidden An artifact of the implementation allowing
+ users to selectively disable system menu entries
+
+ OnlyShowIn/ Allows desktop-system specific applications to not
+ NotShowIn appear in other desktop environments, such as
+ desktop system preferences systems.
+
+ DBusActivatable Whether the application supports standard
+ D-Bus messages to control the application, including
+ the ability to direct applications to open
+ additional files or perform other operations
+
+ Path The starting directory for the application. I
+ haven't found any .desktop file using this
+ feature, but it is replicates functionality
+ present in Mac OSX and Windows.
+
+ Actions Similar to a mechanism provided on Windows
+ where you can list many different operations
+ available from a single application, such as
+ "open", "print", "play", "frobnicate" and
+ Windows automatically adds these to the
+ right-click menu from within explorer.
+
+ MimeType The mime types supported by the
+ application. This allows the wider system to
+ find a application suitable for
+ viewing/modifying specific content, such as a
+ file browser.
+
+ KeyWords Provides tags to allow for some degree of
+ search-ability/categorization of menu
+ entries. I'd be able to explain this in more
+ detail if I could find any examples of it in use.
+
+ StartupNotify/ Announces that the application supports the Startup
+ StartupWMClass Notification Protocol Specification, which
+ allows the desktop environment to detect when
+ the application has successfully launched so
+ that it can disable the waiting cursor.
+
+ URL Used in 'Link' .desktop files to reference an object.
+
+ E. .desktop files cede significant authority over menu
+ organization to the user agent presenting the overall
+ application menu. This is already a reality as many desktop
+ environments show *none* of the menu file data at all; having
+ applications which currently ship a menu file change to
+ shipping a .desktop file will bring them into uniformity with
+ other pieces of the desktop environment by incorporating them
+ into the existing desktop menu system
+
+ F. The .desktop specification and other Freedesktop.org
+ specifications relating to mime types and icons are all interrelated
+ and work together to provide a system capable of implementing
+ common desktop operations. Not providing a .desktop file
+ significantly reduces the functionality of the overall
+ environment, and so any desktop application must provide the
+ full suite. Also delivering a Debian menu file would end up
+ duplicating information in potentially conflicting ways.
+
--- /dev/null
+Whereas:
+
+ 1. The Debian Policy Manual states (§9.6) that 'The Debian menu
+ package provides a standard interface between packages providing
+ applications and "menu programs"'. It further states that 'All
+ packages that provide applications that need not be passed any
+ special command line arguments for normal operations should
+ register a menu entry for those applications'.
+
+ 2. All details about menu system requirement are delegated to the
+ Debian Menu sub-policy and Debian Menu System manuals (the
+ "Debian menu system").
+
+ 3. An external specification, the Freedesktop Desktop Entry
+ Specification (the ".desktop spec"), with native support in many
+ X desktop environments, has appeared since the Debian Menu
+ system was developed. The .desktop spec offers a fairly strict
+ super-set of Debian Menu system functionality.
+
+ 4. The .desktop specification has significant technical benefits
+ for users over the Debian menu system. The .desktop
+ specification works together with the freedesktop.org mime type
+ and icon specifications to provide operations expected by
+ desktop users from other environments, such as Mac OS X or
+ Windows. As such, applications must provide a .desktop file to
+ operate well in most desktop environments.
+
+ 5. The Debian Technical Committee has been asked to resolve a
+ dispute between maintainers of Debian Policy over a change that
+
+ i. incorporates the description of the FreeDesktop menu system
+ and its use in Debian for listing program in desktop menus
+ and associating them with media types
+
+ ii. softens the wording on the Debian Menu system to reflect that
+ in Jessie it will be neither displayed nor installed by
+ default on standard Debian installations.
+
+ Therefore:
+
+
+OPTION A:
+
+ 1. The Technical Committee adopts the changes proposed by Charles
+ Plessy in ba679bff[1].
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+
+Using its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee suggests that the maintainers of the
+ Debian menu package support translating .desktop files of
+ packages which do not provide menu files.
+
+
+OPTION B:
+
+ 1. Considers that the policy procedure resulted in consensus, and
+ adopts the changes proposed by Charles Plessy in ba67bff.[1]
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+
+Using its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee suggests that the maintainers of the
+ Debian menu package support translating .desktop files of
+ packages which do not provide menu files.
+
+
+OPTION C:
+
+ 1. The Technical Committee adopts the changes proposed by Bill
+ Allombert.[1]
+
+ 2. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446
+
+
+OPTION D:
+
+ The Technical Committee has reviewed the underlying technical
+ issues around this question and has resolved that Debian will be
+ best served by migrating away from our own Debian Menu System and
+ towards the common Freedesktop Desktop Entry Specification, and
+ that menu information for applications should not be duplicated in
+ two different formats.
+
+ To encourage this change, we make menu files optional, ask that
+ packages include .desktop files as appropriate and prohibit
+ packages from providing both menu and .desktop files for the same
+ application.
+
+Using its power under §6.1.1 to decide on any matter of technical
+policy, and its power under §6.1.5 to offer advice:
+
+ 1. The Technical Committee adopts the changes proposed by Charles
+ Plessy in ba679bff[1].
+
+ 2. In addition to those changes, the Technical Committee resolves
+ that packages providing a .desktop file shall not also provide a
+ menu file for the same application.
+
+ 3. We further resolve that "menu programs" should not depend on the
+ Debian Menu System and should instead rely on .desktop file
+ contents for constructing a list of applications to present to
+ the user.
+
+ 4. We advise the maintainers of the 'menu' package to update that
+ package to reflect this increased focus on .desktop files by
+ modifying the 'menu' package to use .desktop files for the
+ source of menu information in addition to menu files.
+
+ 5. Discussion of the precise relationship between menu file
+ section/hints values and .desktop file Categories values may be
+ defined within the Debian Menu sub-policy and Debian Menu
+ System.
+
+ 6. Further modifications to the menu policy are allowed using the
+ normal policy modification process.
+
+[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
+
+OPTION Z:
+
+Further discussion
--- /dev/null
+digraph Results {
+ ranksep=0.25;
+ "Option A" [ style="filled" , fontname="Helvetica", fontsize=10 ];
+ "Option B" [ style="filled" , fontname="Helvetica", fontsize=10 ];
+ "Option C" [ style="filled" , color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
+ "Option D" [ style="filled" , color="powderblue", shape=egg, fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
+ "Z\nFurther Discussion" [ style="filled" , shape=diamond, fontcolor="Red", fontname="Helvetica", fontsize=10 ];
+ "Option B" -> "Option A" [ label="2" ];
+ "Option D" -> "Option A" [ label="7" ];
+ "Option A" -> "Z\nFurther Discussion" [ label="7" ];
+ "Option D" -> "Option B" [ label="7" ];
+ "Option B" -> "Z\nFurther Discussion" [ label="5" ];
+ "Z\nFurther Discussion" -> "Option C" [ label="5" ];
+ "Option D" -> "Z\nFurther Discussion" [ label="7" ];
+}
--- /dev/null
+#!/bin/sh
+echo "Debian Menu systems"
+../scripts/pocket-devotee \
+ --option 'A: adopt changes proposed by Charles Plessy (…)' \
+ --option 'B: consider that the procedure resulted in consensus, and adopt changes proposed by Charles Plessy (…)' \
+ --option 'C: adopt changes proposed by Bill Allombert (…)' \
+ --option 'D: adopt changes proposed by Charles Plessy, additionally resolve that packages providing a .desktop file shall not also provide a menu file (…)' \
+ --option 'Z: Further Discussion' \
+ --default-option 'Z' \
+ --quorum 2 \
+ << EOF
+hartmans: D > B > A > Z > C
+don: D > A = B > C > Z
+tfheen: D > A = B > Z > C
+odyx: D > B > A > Z > C
+keithp: D > B > A > Z > C
+bdale: D > A = B > Z > C
+aba: D > A > Z > B > C
+EOF
--- /dev/null
+To: debian-devel-announce@lists.debian.org
+Subject: Call for (self-)nominations for technical committee seats
+
+First and foremost, the technical committee would like to thank Bdale
+Garbee and Steve Langasek for serving on the committee in addition to
+their many other services to Debian. Given the newly introduced §6.2.7
+"Term limit", both their terms will expire on December 31st 2015, and
+there will be two empty seats which can be filled.
+
+To fill these seats, we are soliciting nominations, including
+self-nominations. To nominate yourself or someone else, please send
+e-mail to debian-ctte-private@debian.org with the subject "CTTE
+Nomination of loginname", where loginname is the nominee's Debian
+account login.[1] Please let us know in the body of the e-mail why the
+nominee would be a good fit for the committee, specifically instances
+where the nominee was able to help resolve disagreements, both
+technical and non-technical.
+
+Being a member of the committee does require a time commitment.
+Members should be able to follow e-mail discussions on an ongoing
+basis and respond within a couple of days so that discussions
+progress. Members should ideally be able to spend 10 hours a month
+for relatively busy months, but typical time requirements will be
+less.
+
+We anticipate starting our selection process on or about the first of
+December. After the selection, the committee will then recommend
+nominees to the project leader, who may appoint the nominees (§6.2).
+
+1: See http://db.debian.org/ if you need to look the login up
--- /dev/null
+From: Don Armstrong <don@debian.org>
+To:
+Cc: debian-ctte-private@debian.org
+Reply-To: debian-ctte-private@debian.org
+Subject: CTTE Nomination accept/decline
+
+You have been nominated by someone other than yourself to be
+considered for appointment to the Debian Technical Committee.
+
+Please reply to this e-mail indicating if you are (or are not) willing
+to be considered for appointment. Names of accepted nominees will be
+made public.
+
+--
+Don Armstrong
--- /dev/null
+From: Don Armstrong <don@debian.org>
+To: debian-devel-announce@lists.debian.org
+Subject: CTTE Nominations closed; thanks to all nominees for agreeing to serve
+Reply-to: debian-ctte-private@debian.org
+Mail-Followup-To: debian-ctte-private@debian.org
+
+The Technical Committee would like to thank all of the nominees,
+especially those who agreed to serve Debian on the Technical
+Committee. In addition, we also appreciate the effort of everyone who
+nominated someone else and provided information about positive
+interactions with those nominees to the Committee.
+
+The Technical Committee has begun private deliberations, and will
+recommend a nominee to the Project Leader for approval under §6.2.2.
--- /dev/null
+===== TITLE
+
+Chair of CTTE
+
+===== WEB SUMMARY
+
+Didier Raboud is elected CTTE Chair.
+
+===== EMAIL INTRO
+
+===== EMAIL EPILOGUE
+
+===== DECISION
+
+In 821361, the CTTE held an election for the CTTE Chair after the
+appointment of a new member.[1] Didier Raboud (odyx) was selected as
+the new CTTE Chair.
+
+1: This is not in the constitution, but was discussed and agreed upon
+in #795857 and is documented in procedures.md in the CTTE git
+repository.
--- /dev/null
+../scripts/pocket-devotee \
+ --option 'A: Don Armstrong' \
+ --option 'B: Andreas Barth' \
+ --option 'C: Phil Hands' \
+ --option 'D: Sam Hartman' \
+ --option 'E: Tollef Fog Heen' \
+ --option 'F: Keith Packard' \
+ --option 'G: Didier Raboud' <<EOF
+hartmans: G>B=E>F=D=C>A
+odyx: G>D>A>B=C=E=F
+don: G>A=B=C=D=E=F
+philh: G>A=B=C=E=F
+EOF
projects / debian-ctte.git / commitdiff
