From: Didier Raboud Date: Wed, 27 Apr 2016 17:01:37 +0000 (+0200) Subject: Move some resolved issues X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=16b3a6f49c05a88ae4f440ab627160f5fed827cd;hp=7bf78d0066a12de9d4acb153a154af62c53fea43;p=debian-ctte.git Move some resolved issues --- diff --git a/636783_supermajority/constitution.html b/636783_supermajority/constitution.html deleted file mode 100644 index a87c74c..0000000 --- a/636783_supermajority/constitution.html +++ /dev/null @@ -1,924 +0,0 @@ - - - - - Debian Constitution - - - - - - - - - - - - - -
-

Debian Constitution

-

Constitution for the Debian Project (v1.4)

-

Version 1.4 ratified on October 7th, 2007. Supersedes -Version 1.3 ratified on September 24th, -2006, -Version 1.2 ratified on October 29th, -2003 and -Version 1.1 ratified on June 21st, -2003, which itself supersedes Version 1.0 -ratified on December 2nd, 1998.

- -

1. Introduction

-

The Debian Project is an association of individuals who have -made common cause to create a free operating system.

-

This document describes the organisational structure for formal -decision-making in the Project. It does not describe the goals of the -Project or how it achieves them, or contain any policies except those -directly related to the decision-making process.

-

2. Decision-making bodies and individuals

-

Each decision in the Project is made by one or more of the -following:

-
    -
  1. The Developers, by way of General Resolution or an election;
  2. -
  3. The Project Leader;
  4. -
  5. The Technical Committee and/or its Chairman;
  6. -
  7. The individual Developer working on a particular task;
  8. -
  9. Delegates appointed by the Project Leader for specific - tasks;
  10. -
  11. The Project Secretary.
  12. -
-

Most of the remainder of this document will outline the powers of -these bodies, their composition and appointment, and the procedure for -their decision-making. The powers of a person or body may be subject to -review and/or limitation by others; in this case the reviewing body or -person's entry will state this. In the list above, a person or -body is usually listed before any people or bodies whose decisions they -can overrule or who they (help) appoint - but not everyone listed -earlier can overrule everyone listed later.

-

2.1. General rules

-
    -
  1. -

    Nothing in this constitution imposes an obligation on anyone to - do work for the Project. A person who does not want to do a task - which has been delegated or assigned to them does not need to do - it. However, they must not actively work against these rules and - decisions properly made under them.

    -
  2. -
  3. -

    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.

    -
  4. -
  5. -

    A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.

    -
  6. -
-

3. Individual Developers

-

3.1. Powers

-

An individual Developer may

-
    -
  1. make any technical or nontechnical decision with regard to their - own work;
  2. -
  3. propose or sponsor draft General Resolutions;
  4. -
  5. propose themselves as a Project Leader candidate in - elections;
  6. -
  7. vote on General Resolutions and in Leadership elections.
  8. -
-

3.2. Composition and appointment

-
    -
  1. -

    Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile.

    -
  2. -
  3. -

    The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers - feel that the Delegates are abusing their authority they can of - course override the decision by way of General Resolution - see - §4.1(3), §4.2.

    -
  4. -
-

3.3. Procedure

-

Developers may make these decisions as they see fit.

-

4. The Developers by way of General Resolution or election

-

4.1. Powers

-

Together, the Developers may:

-
    -
  1. -

    Appoint or recall the Project Leader.

    -
  2. -
  3. -

    Amend this constitution, provided they agree with a 3:1 - majority.

    -
  4. -
  5. -

    Make or override any decision authorised by the powers of the Project - Leader or a Delegate.

    -
  6. -
  7. -

    Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.

    -
  8. -
  9. -

    Issue, supersede and withdraw nontechnical policy documents and - statements.

    -

    These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet.

    -

    They may also include position statements about issues of the - day.

    -
      -
    1. A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.
    2. -
    3. The Foundation Documents are the works entitled Debian - Social Contract and Debian Free Software Guidelines.
    4. -
    5. A Foundation Document requires a 3:1 majority for its - supersession. New Foundation Documents are issued and - existing ones withdrawn by amending the list of Foundation - Documents in this constitution.
    6. -
    -
  10. -
  11. -

    Make decisions about property held in trust for purposes - related to Debian. (See §9.).

    -
  12. -
  13. -

    In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.

    -
  14. -
-

4.2. Procedure

-
    -
  1. -

    The Developers follow the Standard Resolution Procedure, below. - A resolution or amendment is introduced if proposed by any - Developer and sponsored by at least K other Developers, or if - proposed by the Project Leader or the Technical Committee.

    -
  2. -
  3. -

    Delaying a decision by the Project Leader or their Delegate:

    -
      -
    1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override them - by passing a resolution to do so; see §4.1(3).
    2. -
    3. 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).
    4. -
    5. 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.
    6. -
    7. 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.
    8. -
    9. If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.
    10. -
    -
  4. -
  5. -

    - 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. -

    -
  6. -
  7. -

    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.

    -
  8. -
  9. -

    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.

    -
  10. -
  11. -

    Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.

    -
  12. -
  13. -

    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.

    -
  14. -
-

5. Project Leader

-

5.1. Powers

-

The Project Leader may:

-
    -
  1. -

    Appoint Delegates or delegate decisions to the Technical - Committee.

    -

    The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee.

    -

    Once a particular decision has been delegated and made the - Project Leader may not withdraw that delegation; however, they may - withdraw an ongoing delegation of particular area of - responsibility.

    -
  2. -
  3. -

    Lend authority to other Developers.

    -

    The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question.

    -
  4. -
  5. -

    Make any decision which requires urgent action.

    -

    This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.

    -
  6. -
  7. -

    Make any decision for whom noone else has responsibility.

    -
  8. -
  9. -

    Propose draft General Resolutions and amendments.

    -
  10. -
  11. -

    Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)

    -
  12. -
  13. -

    Use a casting vote when Developers vote.

    -

    The Project Leader also has a normal vote in such ballots.

    -
  14. -
  15. -

    Vary the discussion period for Developers' votes (as above).

    -
  16. -
  17. -

    Lead discussions amongst Developers.

    -

    The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views.

    -
  18. -
  19. -

    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.

    -
  20. -
  21. -

    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.

    -
  22. -
-

5.2. Appointment

-
    -
  1. The Project Leader is elected by the Developers.
  2. -
  3. The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.
  4. -
  5. For the first week any Developer may nominate - themselves as a candidate Project Leader, and summarize their plans for their term.
  6. -
  7. 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.
  8. -
  9. 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.
  10. -
  11. 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.
  12. -
  13. - The decision will be made using the method specified in section - §A.6 of the Standard Resolution Procedure. The quorum is the - same as for a General Resolution (§4.2) and the default - option is None Of The Above. -
  14. -
  15. The Project Leader serves for one year from their election.
  16. -
-

5.3. Procedure

-

The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.

-

Where practical the Project Leader should informally solicit the -views of the Developers.

-

The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.

-

6. Technical committee

-

6.1. Powers

-

The Technical Committee may:

-
    -
  1. -

    Decide on any matter of technical policy.

    -

    This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).)

    -
  2. -
  3. -

    Decide any technical matter where Developers' jurisdictions - overlap.

    -

    In cases where Developers need to implement compatible - technical policies or stances (for example, if they disagree about - the priorities of conflicting packages, or about ownership of a - command name, or about which package is responsible for a bug that - both maintainers agree is a bug, or about who should be the - maintainer for a package) the technical committee may decide the - matter.

    -
  4. -
  5. -

    Make a decision when asked to do so.

    -

    Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.

    -
  6. -
  7. -

    Overrule a Developer (requires a 3:1 majority).

    -

    The Technical Committee may ask a Developer to take a - particular technical course of action even if the Developer does - not wish to; this requires a 3:1 majority. For example, the - Committee may determine that a complaint made by the submitter of a - bug is justified and that the submitter's proposed solution should - be implemented.

    -
  8. -
  9. -

    Offer advice.

    -

    The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make - informal statements about their views and about the likely views of - the committee.

    -
  10. -
  11. -

    Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)

    -
  12. -
  13. -

    Appoint the Chairman of the Technical Committee.

    -

    - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the - committee votes starting one week before the post will become - vacant (or immediately, if it is already too late). The members - may vote by public acclamation for any fellow committee member, - including themselves; there is no default option. The vote - finishes when all the members have voted, or when the voting - period has ended. The result is determined using the method - specified in section A.6 of the Standard Resolution Procedure. -

    -
  14. -
  15. -

    The Chairman can stand in for the Leader, together with the - Secretary

    -

    As detailed in §7.1(2), the Chairman of the Technical - Committee and the Project Secretary may together stand in for the - Leader if there is no Leader.

    -
  16. -
-

6.2. Composition

-
    -
  1. -

    The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.

    -
  2. -
  3. -

    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.

    -
  4. -
  5. -

    When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.

    -
  6. -
  7. -

    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.

    -
  8. -
  9. -

    If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.

    -
  10. -
-

6.3. Procedure

-
    -
  1. -

    The Technical Committee uses the Standard Resolution - Procedure.

    -

    A draft resolution or amendment may be proposed by any member - of the Technical Committee. There is no minimum discussion period; - the voting period lasts for up to one week, or until the outcome is - no longer in doubt. Members may change their votes. There is a - quorum of two.

    -
  2. -
  3. -

    Details regarding voting

    -

    The Chairman has a casting vote. When the Technical Committee - votes whether to override a Developer who also happens to be a - member of the Committee, that member may not vote (unless they are - the Chairman, in which case they may use only their casting - vote).

    -
  4. -
  5. -

    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.

    -
  6. -
  7. -

    Confidentiality of appointments.

    -

    The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public.

    -
  8. -
  9. -

    No detailed design work.

    -

    The Technical Committee does not engage in design of new - proposals and policies. Such design work should be carried out by - individuals privately or together and discussed in ordinary - technical policy and design forums.

    -

    The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.

    -

    Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.

    -
  10. -
  11. -

    Technical Committee makes decisions only as last resort.

    -

    The Technical Committee does not make a technical decision - until efforts to resolve it via consensus have been tried and - failed, unless it has been asked to make a decision by the person - or body who would normally be responsible for it.

    -
  12. -
-

7. The Project Secretary

-

7.1. Powers

-

The Secretary:

-
    -
  1. -

    Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.

    -
  2. -
  3. -

    Can stand in for the Leader, together with the Chairman of the - Technical Committee.

    -

    If there is no Project Leader then the Chairman of the - Technical Committee and the Project Secretary may by joint - agreement make decisions if they consider it imperative to do - so.

    -
  4. -
  5. -

    Adjudicates any disputes about interpretation of the - constitution.

    -
  6. -
  7. -

    May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.

    -
  8. -
-

7.2. Appointment

-

The Project Secretary is appointed by the Project Leader and the -current Project Secretary.

-

If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.

-

If there is no Project Secretary or the current Secretary is -unavailable and has not delegated authority for a decision then the -decision may be made or delegated by the Chairman of the Technical -Committee, as Acting Secretary.

-

The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.

-

7.3. Procedure

-

The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.

-

When acting together to stand in for an absent Project Leader the -Chairman of the Technical Committee and the Project Secretary should -make decisions only when absolutely necessary and only when consistent -with the consensus of the Developers.

-

8. The Project Leader's Delegates

-

8.1. Powers

-

The Project Leader's Delegates:

-
    -
  1. have powers delegated to them by the Project Leader;
  2. -
  3. may make certain decisions which the Leader may not make - directly, including approving or expelling Developers or designating - people as Developers who do not maintain packages. This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.
  4. -
-

8.2. Appointment

-

The Delegates are appointed by the Project Leader and may be -replaced by the Leader at the Leader's discretion. The Project Leader -may not make the position as a Delegate conditional on particular -decisions by the Delegate, nor may they override a decision made by a -Delegate once made.

-

8.3. Procedure

-

Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.

-

9. Assets held in trust for Debian

-

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.

-

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.

-

SPI and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.

-

9.1. Relationship with Associated Organizations

-
    -
  1. -

    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.

    -
  2. -
-

9.2. Authority

-
    -
  1. -

    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.

    -
  2. -
  3. -

    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.

    -
  4. -
-

9.3. Trusted organisations

-

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.

-

Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.

-

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.

-

A. Standard Resolution Procedure

-

These rules apply to communal decision-making by committees and -plebiscites, where stated above.

-

A.1. Proposal

-

The formal procedure begins when a draft resolution is proposed and -sponsored, as required.

-

A.1. Discussion and Amendment

-
    -
  1. Following the proposal, the resolution may be discussed. - Amendments may be made formal by being proposed and sponsored - according to the requirements for a new resolution, or directly by - the proposer of the original resolution.
  2. -
  3. A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.
  4. -
  5. 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.
  6. -
  7. 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).)
  8. -
  9. 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.
  10. -
  11. 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.
  12. -
-

A.2. Calling for a vote

-
    -
  1. The proposer or a sponsor of a motion or an amendment may call - for a vote, providing that the minimum discussion period (if any) has - elapsed.
  2. -
  3. - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. -
  4. -
  5. 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).
  6. -
  7. - 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. -
  8. -
-

A.3. Voting procedure

-
    -
  1. - Each resolution and its related amendments is voted on in a - single ballot that includes an option for the original - resolution, each amendment, and the default option (where - applicable). -
  2. -
  3. - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. -
  4. -
  5. - The votes are counted according to the rules in A.6. The - default option is Further Discussion, unless specified - otherwise. -
  6. -
  7. In cases of doubt the Project Secretary shall decide on matters - of procedure.
  8. -
-

A.4. Withdrawing resolutions or unaccepted amendments

-

The proposer of a resolution or unaccepted amendment may withdraw -it. In this case new proposers may come forward keep it alive, in which -case the first person to do so becomes the new proposer and any others -become sponsors if they aren't sponsors already.

-

A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.

-

If the withdrawal of the proposer and/or sponsors means that a -resolution has no proposer or not enough sponsors it will not be voted -on unless this is rectified before the resolution expires.

-

A.5. Expiry

-

- If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks the secretary may issue a statement - that the issue is being withdrawn. If none of the sponsors of any - of the proposals object within a week, the issue is withdrawn. -

-

- The secretary may also include suggestions on how to proceed, - if appropriate. -

-

A.6. Vote Counting

-
    -
  1. Each voter's ballot ranks the options being voted on. Not all - options need be ranked. Ranked options are considered - preferred to all unranked options. Voters may rank options - equally. Unranked options are considered to be ranked equally - with one another. Details of how ballots may be filled out - will be included in the Call For Votes. -
  2. -
  3. 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. -
  4. -
  5. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. -
      -
    1. - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. -
    2. -
    3. - 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). -
    4. -
    5. - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. -
    6. -
    -
  6. -
  7. From the list of undropped options, we generate a list of - pairwise defeats. -
      -
    1. - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). -
    2. -
    -
  8. -
  9. From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. -
      -
    1. - An option A transitively defeats an option C if A defeats - C or if there is some other option B where A defeats B AND - B transitively defeats C. -
    2. -
    -
  10. -
  11. We construct the Schwartz set from the set of transitive defeats. -
      -
    1. - An option A is in the Schwartz set if for all options B, - either A transitively defeats B, or B does not transitively - defeat A. -
    2. -
    -
  12. -
  13. If there are defeats between options in the Schwartz set, - we drop the weakest such defeats from the list of pairwise - defeats, and return to step 5. -
      -
    1. - A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) - is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if - V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). -
    2. -
    3. - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. -
    4. -
    -
  14. -
  15. 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. -
  16. -
-

- Note: Options which the voters rank above the default option - are options they find acceptable. Options ranked below the default - options are options they find unacceptable. -

-

When the Standard Resolution Procedure is to be used, the text -which refers to it must specify what is sufficient to have a draft -resolution proposed and/or sponsored, what the minimum discussion -period is, and what the voting period is. It must also specify any -supermajority and/or the quorum (and default option) to be -used.

-

B. Use of language and typography

-

The present indicative (is, for example) means that the statement -is a rule in this constitution. May or can indicates that the -person or body has discretion. Should means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. Text marked as a citation, such as this, is rationale -and does not form part of the constitution. It may be used only to aid -interpretation in cases of doubt.

-
-
- - - diff --git a/636783_supermajority/intro b/636783_supermajority/intro deleted file mode 100644 index 1375ec1..0000000 --- a/636783_supermajority/intro +++ /dev/null @@ -1,20 +0,0 @@ -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 ] diff --git a/636783_supermajority/propose-informal b/636783_supermajority/propose-informal deleted file mode 100644 index 66cf536..0000000 --- a/636783_supermajority/propose-informal +++ /dev/null @@ -1,35 +0,0 @@ - ----- 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. - - [+The Technical Committee should limit private - discussions to situations where holding the conversation in - public would be infeasible or counterproductive.+] - - ----- GENERAL RESOLUTION ENDS ----- diff --git a/636783_supermajority/propose-numberfix b/636783_supermajority/propose-numberfix deleted file mode 100644 index 48251d5..0000000 --- a/636783_supermajority/propose-numberfix +++ /dev/null @@ -1,13 +0,0 @@ - ----- 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 ----- diff --git a/636783_supermajority/propose-supermajority b/636783_supermajority/propose-supermajority deleted file mode 100644 index 8e4f2b8..0000000 --- a/636783_supermajority/propose-supermajority +++ /dev/null @@ -1,88 +0,0 @@ - ----- 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 ----- diff --git a/741573_menu_systems/decision b/741573_menu_systems/decision deleted file mode 100644 index 52da647..0000000 --- a/741573_menu_systems/decision +++ /dev/null @@ -1,104 +0,0 @@ -===== 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 diff --git a/741573_menu_systems/dla_draft.txt b/741573_menu_systems/dla_draft.txt deleted file mode 100644 index a3396dd..0000000 --- a/741573_menu_systems/dla_draft.txt +++ /dev/null @@ -1,60 +0,0 @@ -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 diff --git a/741573_menu_systems/iwj_draft.txt b/741573_menu_systems/iwj_draft.txt deleted file mode 100644 index d804429..0000000 --- a/741573_menu_systems/iwj_draft.txt +++ /dev/null @@ -1,47 +0,0 @@ - - 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. - diff --git a/741573_menu_systems/keithp_alternatives.txt b/741573_menu_systems/keithp_alternatives.txt deleted file mode 100644 index 1a9e07d..0000000 --- a/741573_menu_systems/keithp_alternatives.txt +++ /dev/null @@ -1,31 +0,0 @@ -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 diff --git a/741573_menu_systems/keithp_draft.txt b/741573_menu_systems/keithp_draft.txt deleted file mode 100644 index 25ddee8..0000000 --- a/741573_menu_systems/keithp_draft.txt +++ /dev/null @@ -1,206 +0,0 @@ - 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. - diff --git a/741573_menu_systems/odyx_draft.txt b/741573_menu_systems/odyx_draft.txt deleted file mode 100644 index e1c4da3..0000000 --- a/741573_menu_systems/odyx_draft.txt +++ /dev/null @@ -1,133 +0,0 @@ -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 diff --git a/741573_menu_systems/results.dot b/741573_menu_systems/results.dot deleted file mode 100644 index d60058f..0000000 --- a/741573_menu_systems/results.dot +++ /dev/null @@ -1,15 +0,0 @@ -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" ]; -} diff --git a/741573_menu_systems/results.png b/741573_menu_systems/results.png deleted file mode 100644 index e962111..0000000 Binary files a/741573_menu_systems/results.png and /dev/null differ diff --git a/741573_menu_systems/run_vote.sh b/741573_menu_systems/run_vote.sh deleted file mode 100755 index c776dff..0000000 --- a/741573_menu_systems/run_vote.sh +++ /dev/null @@ -1,19 +0,0 @@ -#!/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 diff --git a/797533_new_ctte_members/call_for_nominations.txt b/797533_new_ctte_members/call_for_nominations.txt deleted file mode 100644 index fb1804b..0000000 --- a/797533_new_ctte_members/call_for_nominations.txt +++ /dev/null @@ -1,30 +0,0 @@ -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 diff --git a/797533_new_ctte_members/nomination_confirmation.txt b/797533_new_ctte_members/nomination_confirmation.txt deleted file mode 100644 index d2358e1..0000000 --- a/797533_new_ctte_members/nomination_confirmation.txt +++ /dev/null @@ -1,15 +0,0 @@ -From: Don Armstrong -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 diff --git a/797533_new_ctte_members/thank_nominees.txt b/797533_new_ctte_members/thank_nominees.txt deleted file mode 100644 index 9aa1580..0000000 --- a/797533_new_ctte_members/thank_nominees.txt +++ /dev/null @@ -1,14 +0,0 @@ -From: Don Armstrong -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. diff --git a/821361_chair_election/decision b/821361_chair_election/decision deleted file mode 100644 index 4cf1f37..0000000 --- a/821361_chair_election/decision +++ /dev/null @@ -1,21 +0,0 @@ -===== 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. diff --git a/821361_chair_election/run_vote.sh b/821361_chair_election/run_vote.sh deleted file mode 100755 index 54892d2..0000000 --- a/821361_chair_election/run_vote.sh +++ /dev/null @@ -1,13 +0,0 @@ -../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' <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 diff --git a/resolved_issues/636783_supermajority/constitution.html b/resolved_issues/636783_supermajority/constitution.html new file mode 100644 index 0000000..a87c74c --- /dev/null +++ b/resolved_issues/636783_supermajority/constitution.html @@ -0,0 +1,924 @@ + + + + + Debian Constitution + + + + + + + + + + + + + +
+

Debian Constitution

+

Constitution for the Debian Project (v1.4)

+

Version 1.4 ratified on October 7th, 2007. Supersedes +Version 1.3 ratified on September 24th, +2006, +Version 1.2 ratified on October 29th, +2003 and +Version 1.1 ratified on June 21st, +2003, which itself supersedes Version 1.0 +ratified on December 2nd, 1998.

+ +

1. Introduction

+

The Debian Project is an association of individuals who have +made common cause to create a free operating system.

+

This document describes the organisational structure for formal +decision-making in the Project. It does not describe the goals of the +Project or how it achieves them, or contain any policies except those +directly related to the decision-making process.

+

2. Decision-making bodies and individuals

+

Each decision in the Project is made by one or more of the +following:

+
    +
  1. The Developers, by way of General Resolution or an election;
  2. +
  3. The Project Leader;
  4. +
  5. The Technical Committee and/or its Chairman;
  6. +
  7. The individual Developer working on a particular task;
  8. +
  9. Delegates appointed by the Project Leader for specific + tasks;
  10. +
  11. The Project Secretary.
  12. +
+

Most of the remainder of this document will outline the powers of +these bodies, their composition and appointment, and the procedure for +their decision-making. The powers of a person or body may be subject to +review and/or limitation by others; in this case the reviewing body or +person's entry will state this. In the list above, a person or +body is usually listed before any people or bodies whose decisions they +can overrule or who they (help) appoint - but not everyone listed +earlier can overrule everyone listed later.

+

2.1. General rules

+
    +
  1. +

    Nothing in this constitution imposes an obligation on anyone to + do work for the Project. A person who does not want to do a task + which has been delegated or assigned to them does not need to do + it. However, they must not actively work against these rules and + decisions properly made under them.

    +
  2. +
  3. +

    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.

    +
  4. +
  5. +

    A person may leave the Project or resign from a particular post + they hold, at any time, by stating so publicly.

    +
  6. +
+

3. Individual Developers

+

3.1. Powers

+

An individual Developer may

+
    +
  1. make any technical or nontechnical decision with regard to their + own work;
  2. +
  3. propose or sponsor draft General Resolutions;
  4. +
  5. propose themselves as a Project Leader candidate in + elections;
  6. +
  7. vote on General Resolutions and in Leadership elections.
  8. +
+

3.2. Composition and appointment

+
    +
  1. +

    Developers are volunteers who agree to further the aims of the + Project insofar as they participate in it, and who maintain + package(s) for the Project or do other work which the Project + Leader's Delegate(s) consider worthwhile.

    +
  2. +
  3. +

    The Project Leader's Delegate(s) may choose not to admit new + Developers, or expel existing Developers. If the Developers + feel that the Delegates are abusing their authority they can of + course override the decision by way of General Resolution - see + §4.1(3), §4.2.

    +
  4. +
+

3.3. Procedure

+

Developers may make these decisions as they see fit.

+

4. The Developers by way of General Resolution or election

+

4.1. Powers

+

Together, the Developers may:

+
    +
  1. +

    Appoint or recall the Project Leader.

    +
  2. +
  3. +

    Amend this constitution, provided they agree with a 3:1 + majority.

    +
  4. +
  5. +

    Make or override any decision authorised by the powers of the Project + Leader or a Delegate.

    +
  6. +
  7. +

    Make or override any decision authorised by the powers of the Technical + Committee, provided they agree with a 2:1 majority.

    +
  8. +
  9. +

    Issue, supersede and withdraw nontechnical policy documents and + statements.

    +

    These include documents describing the goals of the project, its + relationship with other free software entities, and nontechnical + policies such as the free software licence terms that Debian + software must meet.

    +

    They may also include position statements about issues of the + day.

    +
      +
    1. A Foundation Document is a document or statement regarded as + critical to the Project's mission and purposes.
    2. +
    3. The Foundation Documents are the works entitled Debian + Social Contract and Debian Free Software Guidelines.
    4. +
    5. A Foundation Document requires a 3:1 majority for its + supersession. New Foundation Documents are issued and + existing ones withdrawn by amending the list of Foundation + Documents in this constitution.
    6. +
    +
  10. +
  11. +

    Make decisions about property held in trust for purposes + related to Debian. (See §9.).

    +
  12. +
  13. +

    In case of a disagreement between the project leader and + the incumbent secretary, appoint a new secretary.

    +
  14. +
+

4.2. Procedure

+
    +
  1. +

    The Developers follow the Standard Resolution Procedure, below. + A resolution or amendment is introduced if proposed by any + Developer and sponsored by at least K other Developers, or if + proposed by the Project Leader or the Technical Committee.

    +
  2. +
  3. +

    Delaying a decision by the Project Leader or their Delegate:

    +
      +
    1. If the Project Leader or their Delegate, or the Technical + Committee, has made a decision, then Developers can override them + by passing a resolution to do so; see §4.1(3).
    2. +
    3. 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).
    4. +
    5. 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.
    6. +
    7. 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.
    8. +
    9. If the Project Leader (or the Delegate) withdraws the + original decision, the vote becomes moot, and is no longer + conducted.
    10. +
    +
  4. +
  5. +

    + 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. +

    +
  6. +
  7. +

    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.

    +
  8. +
  9. +

    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.

    +
  10. +
  11. +

    Votes are cast by email in a manner suitable to the Secretary. + The Secretary determines for each poll whether voters can change + their votes.

    +
  12. +
  13. +

    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.

    +
  14. +
+

5. Project Leader

+

5.1. Powers

+

The Project Leader may:

+
    +
  1. +

    Appoint Delegates or delegate decisions to the Technical + Committee.

    +

    The Leader may define an area of ongoing responsibility or a + specific decision and hand it over to another Developer or to the + Technical Committee.

    +

    Once a particular decision has been delegated and made the + Project Leader may not withdraw that delegation; however, they may + withdraw an ongoing delegation of particular area of + responsibility.

    +
  2. +
  3. +

    Lend authority to other Developers.

    +

    The Project Leader may make statements of support for points of + view or for other members of the project, when asked or otherwise; + these statements have force if and only if the Leader would be + empowered to make the decision in question.

    +
  4. +
  5. +

    Make any decision which requires urgent action.

    +

    This does not apply to decisions which have only become + gradually urgent through lack of relevant action, unless there is a + fixed deadline.

    +
  6. +
  7. +

    Make any decision for whom noone else has responsibility.

    +
  8. +
  9. +

    Propose draft General Resolutions and amendments.

    +
  10. +
  11. +

    Together with the Technical Committee, appoint new members to + the Committee. (See §6.2.)

    +
  12. +
  13. +

    Use a casting vote when Developers vote.

    +

    The Project Leader also has a normal vote in such ballots.

    +
  14. +
  15. +

    Vary the discussion period for Developers' votes (as above).

    +
  16. +
  17. +

    Lead discussions amongst Developers.

    +

    The Project Leader should attempt to participate in discussions + amongst the Developers in a helpful way which seeks to bring the + discussion to bear on the key issues at hand. The Project Leader + should not use the Leadership position to promote their own + personal views.

    +
  18. +
  19. +

    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.

    +
  20. +
  21. +

    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.

    +
  22. +
+

5.2. Appointment

+
    +
  1. The Project Leader is elected by the Developers.
  2. +
  3. The election begins six weeks before the leadership post becomes + vacant, or (if it is too late already) immediately.
  4. +
  5. For the first week any Developer may nominate + themselves as a candidate Project Leader, and summarize their plans for their term.
  6. +
  7. 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.
  8. +
  9. 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.
  10. +
  11. 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.
  12. +
  13. + The decision will be made using the method specified in section + §A.6 of the Standard Resolution Procedure. The quorum is the + same as for a General Resolution (§4.2) and the default + option is None Of The Above. +
  14. +
  15. The Project Leader serves for one year from their election.
  16. +
+

5.3. Procedure

+

The Project Leader should attempt to make decisions which are +consistent with the consensus of the opinions of the Developers.

+

Where practical the Project Leader should informally solicit the +views of the Developers.

+

The Project Leader should avoid overemphasizing their own point of +view when making decisions in their capacity as Leader.

+

6. Technical committee

+

6.1. Powers

+

The Technical Committee may:

+
    +
  1. +

    Decide on any matter of technical policy.

    +

    This includes the contents of the technical policy manuals, + developers' reference materials, example packages and the behaviour + of non-experimental package building tools. (In each case the usual + maintainer of the relevant software or documentation makes + decisions initially, however; see 6.3(5).)

    +
  2. +
  3. +

    Decide any technical matter where Developers' jurisdictions + overlap.

    +

    In cases where Developers need to implement compatible + technical policies or stances (for example, if they disagree about + the priorities of conflicting packages, or about ownership of a + command name, or about which package is responsible for a bug that + both maintainers agree is a bug, or about who should be the + maintainer for a package) the technical committee may decide the + matter.

    +
  4. +
  5. +

    Make a decision when asked to do so.

    +

    Any person or body may delegate a decision of their own to the + Technical Committee, or seek advice from it.

    +
  6. +
  7. +

    Overrule a Developer (requires a 3:1 majority).

    +

    The Technical Committee may ask a Developer to take a + particular technical course of action even if the Developer does + not wish to; this requires a 3:1 majority. For example, the + Committee may determine that a complaint made by the submitter of a + bug is justified and that the submitter's proposed solution should + be implemented.

    +
  8. +
  9. +

    Offer advice.

    +

    The Technical Committee may make formal announcements about its + views on any matter. Individual members may of course make + informal statements about their views and about the likely views of + the committee.

    +
  10. +
  11. +

    Together with the Project Leader, appoint new members to itself + or remove existing members. (See §6.2.)

    +
  12. +
  13. +

    Appoint the Chairman of the Technical Committee.

    +

    + The Chairman is elected by the Committee from its members. All + members of the committee are automatically nominated; the + committee votes starting one week before the post will become + vacant (or immediately, if it is already too late). The members + may vote by public acclamation for any fellow committee member, + including themselves; there is no default option. The vote + finishes when all the members have voted, or when the voting + period has ended. The result is determined using the method + specified in section A.6 of the Standard Resolution Procedure. +

    +
  14. +
  15. +

    The Chairman can stand in for the Leader, together with the + Secretary

    +

    As detailed in §7.1(2), the Chairman of the Technical + Committee and the Project Secretary may together stand in for the + Leader if there is no Leader.

    +
  16. +
+

6.2. Composition

+
    +
  1. +

    The Technical Committee consists of up to 8 Developers, and + should usually have at least 4 members.

    +
  2. +
  3. +

    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.

    +
  4. +
  5. +

    When there are 5 members or fewer the Technical Committee may + appoint new member(s) until the number of members reaches 6.

    +
  6. +
  7. +

    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.

    +
  8. +
  9. +

    If the Technical Committee and the Project Leader agree they + may remove or replace an existing member of the Technical + Committee.

    +
  10. +
+

6.3. Procedure

+
    +
  1. +

    The Technical Committee uses the Standard Resolution + Procedure.

    +

    A draft resolution or amendment may be proposed by any member + of the Technical Committee. There is no minimum discussion period; + the voting period lasts for up to one week, or until the outcome is + no longer in doubt. Members may change their votes. There is a + quorum of two.

    +
  2. +
  3. +

    Details regarding voting

    +

    The Chairman has a casting vote. When the Technical Committee + votes whether to override a Developer who also happens to be a + member of the Committee, that member may not vote (unless they are + the Chairman, in which case they may use only their casting + vote).

    +
  4. +
  5. +

    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.

    +
  6. +
  7. +

    Confidentiality of appointments.

    +

    The Technical Committee may hold confidential discussions via + private email or a private mailing list or other means to discuss + appointments to the Committee. However, votes on appointments must + be public.

    +
  8. +
  9. +

    No detailed design work.

    +

    The Technical Committee does not engage in design of new + proposals and policies. Such design work should be carried out by + individuals privately or together and discussed in ordinary + technical policy and design forums.

    +

    The Technical Committee restricts itself to choosing from or + adopting compromises between solutions and decisions which have + been proposed and reasonably thoroughly discussed elsewhere.

    +

    Individual members of the technical committee may of + course participate on their own behalf in any aspect of design and + policy work.

    +
  10. +
  11. +

    Technical Committee makes decisions only as last resort.

    +

    The Technical Committee does not make a technical decision + until efforts to resolve it via consensus have been tried and + failed, unless it has been asked to make a decision by the person + or body who would normally be responsible for it.

    +
  12. +
+

7. The Project Secretary

+

7.1. Powers

+

The Secretary:

+
    +
  1. +

    Takes votes amongst the Developers, and determines the number + and identity of Developers, whenever this is required by the + constitution.

    +
  2. +
  3. +

    Can stand in for the Leader, together with the Chairman of the + Technical Committee.

    +

    If there is no Project Leader then the Chairman of the + Technical Committee and the Project Secretary may by joint + agreement make decisions if they consider it imperative to do + so.

    +
  4. +
  5. +

    Adjudicates any disputes about interpretation of the + constitution.

    +
  6. +
  7. +

    May delegate part or all of their authority to someone else, or + withdraw such a delegation at any time.

    +
  8. +
+

7.2. Appointment

+

The Project Secretary is appointed by the Project Leader and the +current Project Secretary.

+

If the Project Leader and the current Project Secretary cannot agree +on a new appointment, they must ask the Developers by way of +General Resolution to appoint a Secretary.

+

If there is no Project Secretary or the current Secretary is +unavailable and has not delegated authority for a decision then the +decision may be made or delegated by the Chairman of the Technical +Committee, as Acting Secretary.

+

The Project Secretary's term of office is 1 year, at which point +they or another Secretary must be (re)appointed.

+

7.3. Procedure

+

The Project Secretary should make decisions which are fair and +reasonable, and preferably consistent with the consensus of the +Developers.

+

When acting together to stand in for an absent Project Leader the +Chairman of the Technical Committee and the Project Secretary should +make decisions only when absolutely necessary and only when consistent +with the consensus of the Developers.

+

8. The Project Leader's Delegates

+

8.1. Powers

+

The Project Leader's Delegates:

+
    +
  1. have powers delegated to them by the Project Leader;
  2. +
  3. may make certain decisions which the Leader may not make + directly, including approving or expelling Developers or designating + people as Developers who do not maintain packages. This is to + avoid concentration of power, particularly over membership as a + Developer, in the hands of the Project Leader.
  4. +
+

8.2. Appointment

+

The Delegates are appointed by the Project Leader and may be +replaced by the Leader at the Leader's discretion. The Project Leader +may not make the position as a Delegate conditional on particular +decisions by the Delegate, nor may they override a decision made by a +Delegate once made.

+

8.3. Procedure

+

Delegates may make decisions as they see fit, but should attempt to +implement good technical decisions and/or follow consensus opinion.

+

9. Assets held in trust for Debian

+

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.

+

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.

+

SPI and Debian are separate +organisations who share some goals. +Debian is grateful for the legal support framework offered by SPI.

+

9.1. Relationship with Associated Organizations

+
    +
  1. +

    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.

    +
  2. +
+

9.2. Authority

+
    +
  1. +

    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.

    +
  2. +
  3. +

    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.

    +
  4. +
+

9.3. Trusted organisations

+

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.

+

Organisations holding assets in trust for Debian should +undertake reasonable obligations for the handling of such +assets.

+

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.

+

A. Standard Resolution Procedure

+

These rules apply to communal decision-making by committees and +plebiscites, where stated above.

+

A.1. Proposal

+

The formal procedure begins when a draft resolution is proposed and +sponsored, as required.

+

A.1. Discussion and Amendment

+
    +
  1. Following the proposal, the resolution may be discussed. + Amendments may be made formal by being proposed and sponsored + according to the requirements for a new resolution, or directly by + the proposer of the original resolution.
  2. +
  3. A formal amendment may be accepted by the resolution's proposer, + in which case the formal resolution draft is immediately changed to + match.
  4. +
  5. 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.
  6. +
  7. 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).)
  8. +
  9. 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.
  10. +
  11. 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.
  12. +
+

A.2. Calling for a vote

+
    +
  1. The proposer or a sponsor of a motion or an amendment may call + for a vote, providing that the minimum discussion period (if any) has + elapsed.
  2. +
  3. + The proposer or any sponsor of a resolution may call for a vote on that + resolution and all related amendments. +
  4. +
  5. 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).
  6. +
  7. + 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. +
  8. +
+

A.3. Voting procedure

+
    +
  1. + Each resolution and its related amendments is voted on in a + single ballot that includes an option for the original + resolution, each amendment, and the default option (where + applicable). +
  2. +
  3. + The default option must not have any supermajority requirements. + Options which do not have an explicit supermajority requirement + have a 1:1 majority requirement. +
  4. +
  5. + The votes are counted according to the rules in A.6. The + default option is Further Discussion, unless specified + otherwise. +
  6. +
  7. In cases of doubt the Project Secretary shall decide on matters + of procedure.
  8. +
+

A.4. Withdrawing resolutions or unaccepted amendments

+

The proposer of a resolution or unaccepted amendment may withdraw +it. In this case new proposers may come forward keep it alive, in which +case the first person to do so becomes the new proposer and any others +become sponsors if they aren't sponsors already.

+

A sponsor of a resolution or amendment (unless it has been +accepted) may withdraw.

+

If the withdrawal of the proposer and/or sponsors means that a +resolution has no proposer or not enough sponsors it will not be voted +on unless this is rectified before the resolution expires.

+

A.5. Expiry

+

+ If a proposed resolution has not been discussed, amended, voted on or + otherwise dealt with for 4 weeks the secretary may issue a statement + that the issue is being withdrawn. If none of the sponsors of any + of the proposals object within a week, the issue is withdrawn. +

+

+ The secretary may also include suggestions on how to proceed, + if appropriate. +

+

A.6. Vote Counting

+
    +
  1. Each voter's ballot ranks the options being voted on. Not all + options need be ranked. Ranked options are considered + preferred to all unranked options. Voters may rank options + equally. Unranked options are considered to be ranked equally + with one another. Details of how ballots may be filled out + will be included in the Call For Votes. +
  2. +
  3. 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. +
  4. +
  5. Any (non-default) option which does not defeat the default option + by its required majority ratio is dropped from consideration. +
      +
    1. + Given two options A and B, V(A,B) is the number of voters + who prefer option A over option B. +
    2. +
    3. + 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). +
    4. +
    5. + If a supermajority of S:1 is required for A, its majority ratio + is S; otherwise, its majority ratio is 1. +
    6. +
    +
  6. +
  7. From the list of undropped options, we generate a list of + pairwise defeats. +
      +
    1. + An option A defeats an option B, if V(A,B) is strictly greater + than V(B,A). +
    2. +
    +
  8. +
  9. From the list of [undropped] pairwise defeats, we generate a + set of transitive defeats. +
      +
    1. + An option A transitively defeats an option C if A defeats + C or if there is some other option B where A defeats B AND + B transitively defeats C. +
    2. +
    +
  10. +
  11. We construct the Schwartz set from the set of transitive defeats. +
      +
    1. + An option A is in the Schwartz set if for all options B, + either A transitively defeats B, or B does not transitively + defeat A. +
    2. +
    +
  12. +
  13. If there are defeats between options in the Schwartz set, + we drop the weakest such defeats from the list of pairwise + defeats, and return to step 5. +
      +
    1. + A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) + is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if + V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). +
    2. +
    3. + A weakest defeat is a defeat that has no other defeat weaker + than it. There may be more than one such defeat. +
    4. +
    +
  14. +
  15. 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. +
  16. +
+

+ Note: Options which the voters rank above the default option + are options they find acceptable. Options ranked below the default + options are options they find unacceptable. +

+

When the Standard Resolution Procedure is to be used, the text +which refers to it must specify what is sufficient to have a draft +resolution proposed and/or sponsored, what the minimum discussion +period is, and what the voting period is. It must also specify any +supermajority and/or the quorum (and default option) to be +used.

+

B. Use of language and typography

+

The present indicative (is, for example) means that the statement +is a rule in this constitution. May or can indicates that the +person or body has discretion. Should means that it would be +considered a good thing if the sentence were obeyed, but it is not +binding. Text marked as a citation, such as this, is rationale +and does not form part of the constitution. It may be used only to aid +interpretation in cases of doubt.

+
+
+ + + diff --git a/resolved_issues/636783_supermajority/intro b/resolved_issues/636783_supermajority/intro new file mode 100644 index 0000000..1375ec1 --- /dev/null +++ b/resolved_issues/636783_supermajority/intro @@ -0,0 +1,20 @@ +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 ] diff --git a/resolved_issues/636783_supermajority/propose-informal b/resolved_issues/636783_supermajority/propose-informal new file mode 100644 index 0000000..66cf536 --- /dev/null +++ b/resolved_issues/636783_supermajority/propose-informal @@ -0,0 +1,35 @@ + ----- 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. + + [+The Technical Committee should limit private + discussions to situations where holding the conversation in + public would be infeasible or counterproductive.+] + + ----- GENERAL RESOLUTION ENDS ----- diff --git a/resolved_issues/636783_supermajority/propose-numberfix b/resolved_issues/636783_supermajority/propose-numberfix new file mode 100644 index 0000000..48251d5 --- /dev/null +++ b/resolved_issues/636783_supermajority/propose-numberfix @@ -0,0 +1,13 @@ + ----- 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 ----- diff --git a/resolved_issues/636783_supermajority/propose-supermajority b/resolved_issues/636783_supermajority/propose-supermajority new file mode 100644 index 0000000..8e4f2b8 --- /dev/null +++ b/resolved_issues/636783_supermajority/propose-supermajority @@ -0,0 +1,88 @@ + ----- 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 ----- diff --git a/resolved_issues/741573_menu_systems/decision b/resolved_issues/741573_menu_systems/decision new file mode 100644 index 0000000..52da647 --- /dev/null +++ b/resolved_issues/741573_menu_systems/decision @@ -0,0 +1,104 @@ +===== 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 diff --git a/resolved_issues/741573_menu_systems/dla_draft.txt b/resolved_issues/741573_menu_systems/dla_draft.txt new file mode 100644 index 0000000..a3396dd --- /dev/null +++ b/resolved_issues/741573_menu_systems/dla_draft.txt @@ -0,0 +1,60 @@ +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 diff --git a/resolved_issues/741573_menu_systems/iwj_draft.txt b/resolved_issues/741573_menu_systems/iwj_draft.txt new file mode 100644 index 0000000..d804429 --- /dev/null +++ b/resolved_issues/741573_menu_systems/iwj_draft.txt @@ -0,0 +1,47 @@ + + 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. + diff --git a/resolved_issues/741573_menu_systems/keithp_alternatives.txt b/resolved_issues/741573_menu_systems/keithp_alternatives.txt new file mode 100644 index 0000000..1a9e07d --- /dev/null +++ b/resolved_issues/741573_menu_systems/keithp_alternatives.txt @@ -0,0 +1,31 @@ +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 diff --git a/resolved_issues/741573_menu_systems/keithp_draft.txt b/resolved_issues/741573_menu_systems/keithp_draft.txt new file mode 100644 index 0000000..25ddee8 --- /dev/null +++ b/resolved_issues/741573_menu_systems/keithp_draft.txt @@ -0,0 +1,206 @@ + 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. + diff --git a/resolved_issues/741573_menu_systems/odyx_draft.txt b/resolved_issues/741573_menu_systems/odyx_draft.txt new file mode 100644 index 0000000..e1c4da3 --- /dev/null +++ b/resolved_issues/741573_menu_systems/odyx_draft.txt @@ -0,0 +1,133 @@ +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 diff --git a/resolved_issues/741573_menu_systems/results.dot b/resolved_issues/741573_menu_systems/results.dot new file mode 100644 index 0000000..d60058f --- /dev/null +++ b/resolved_issues/741573_menu_systems/results.dot @@ -0,0 +1,15 @@ +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" ]; +} diff --git a/resolved_issues/741573_menu_systems/results.png b/resolved_issues/741573_menu_systems/results.png new file mode 100644 index 0000000..e962111 Binary files /dev/null and b/resolved_issues/741573_menu_systems/results.png differ diff --git a/resolved_issues/741573_menu_systems/run_vote.sh b/resolved_issues/741573_menu_systems/run_vote.sh new file mode 100755 index 0000000..c776dff --- /dev/null +++ b/resolved_issues/741573_menu_systems/run_vote.sh @@ -0,0 +1,19 @@ +#!/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 diff --git a/resolved_issues/797533_new_ctte_members/call_for_nominations.txt b/resolved_issues/797533_new_ctte_members/call_for_nominations.txt new file mode 100644 index 0000000..fb1804b --- /dev/null +++ b/resolved_issues/797533_new_ctte_members/call_for_nominations.txt @@ -0,0 +1,30 @@ +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 diff --git a/resolved_issues/797533_new_ctte_members/nomination_confirmation.txt b/resolved_issues/797533_new_ctte_members/nomination_confirmation.txt new file mode 100644 index 0000000..d2358e1 --- /dev/null +++ b/resolved_issues/797533_new_ctte_members/nomination_confirmation.txt @@ -0,0 +1,15 @@ +From: Don Armstrong +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 diff --git a/resolved_issues/797533_new_ctte_members/thank_nominees.txt b/resolved_issues/797533_new_ctte_members/thank_nominees.txt new file mode 100644 index 0000000..9aa1580 --- /dev/null +++ b/resolved_issues/797533_new_ctte_members/thank_nominees.txt @@ -0,0 +1,14 @@ +From: Don Armstrong +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. diff --git a/resolved_issues/821361_chair_election/decision b/resolved_issues/821361_chair_election/decision new file mode 100644 index 0000000..4cf1f37 --- /dev/null +++ b/resolved_issues/821361_chair_election/decision @@ -0,0 +1,21 @@ +===== 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. diff --git a/resolved_issues/821361_chair_election/run_vote.sh b/resolved_issues/821361_chair_election/run_vote.sh new file mode 100755 index 0000000..54892d2 --- /dev/null +++ b/resolved_issues/821361_chair_election/run_vote.sh @@ -0,0 +1,13 @@ +../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' <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