General Resolution: Endorse the concept of Debian Maintainers

The Debian Project endorses the concept of Debian Maintainers with limited access, and resolves that:

A new keyring will be created, called the Debian maintainers keyring. It will be initially maintained by:
- Anthony Towns (proposer, ftpmaster, jetring developer)
- Joey Hess (jetring developer)
Commit access will also be provided to others in Debian with similar roles to ensure that any problems relating to this keyring can be dealt with by multiple people. These people will initially be:
- Brian Nelson (n-m frontdesk)
- Christoph Berg (n-m frontdesk, jetring developer)
- James Troup (DAM, ftpmaster, keyring-maint)
- Joerg Jaspert (DAM)
- Marc Brockschmidt (n-m frontdesk)
- Michael Beattie (keyring-maint)
- Ryan Murray (ftpmaster)
The keyring will be handled using suitable technology to ensure it can be maintained by a team. It is expected it will initially be maintained in alioth subversion using the jetring tool, and that the keyring will be packaged for Debian and regularly uploaded to unstable.

The team will be known as the Debian Maintainer Keyring team. Changes to the team may be made by the DPL under the normal rules for delegations.
The initial policy for an individual to be included in the keyring will be:
- that the applicant acknowledges Debian's social contract, free software guidelines, and machine usage policies.
- that the applicant provides a valid gpg key, signed by a Debian developer (and preferably connected to the web of trust by multiple paths).
- that at least one Debian developer (preferably more) is willing to advocate the applicant's inclusion, in particular that the applicant is technically competent and good to work with.
All additions to the keyring will be publicly announced to the debian-project list.
The initial policy is that removals from the keyring will occur under any of the following circumstances:
- the individual has become a Debian developer
- the individual has not annually reconfirmed their interest
- multiple Debian developers have requested the individual's removal for good reason, such as problematic uploads, unfixed bugs, or being unreasonably difficult to work with
- the Debian Account Managers have requested the removal
The initial policy for Debian developers who wish to advocate a potential Debian maintainer will be:
- Developers should take care whom they choose to advocate, particularly if they have not successfully participated as an Application Manager, or in other mentoring roles. Advocacy should only come after seeing the individual working effectively within Debian, both technically and socially.
- Advocacy messages should be posted to debian-newmaint or other relevant public mailing list, and a link to that mail provided with the application.
- If a developer repeatedly advocates individuals who cause problems and need to be removed, the Debian Maintainer Keyring team may stop accepting advocacy from that developer. If the advocacy appears to be malicious or particularly careless, the Debian Account Managers may consider removing that developer from the project.
The initial policy for the use of the Debian Maintainer keyring with the Debian archive will be to accept uploads signed by a key in that keyring provided:
- none of the uploaded packages are NEW
- the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
- none of the packages are being taken over from other source packages
- the most recent version of the package uploaded to unstable or experimental includes the field DM-Upload-Allowed: yes in the source section of its control file
- the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)
- the usual checks applied to uploads from Debian developers pass
The initial relationship to the existing new-maintainer (n-m) procedure will be as an independent means of contributing to Debian. This means, among other things, that:
- Applicants in the n-m queue may choose to apply to be a Debian maintainer while finishing their application or waiting for it to be accepted.
- Individuals may apply to the n-m process, and pass through it without becoming a Debian maintainer at any point.
- Individuals may apply to become a Debian Maintainer without being in the n-m queue, or having any intention of joining the n-m queue.
- Application Managers may advocate their n-m applicants but are not required to. They may decide to only advocate applicants who have passed some (or all) of the T&S or P&P checks.
There is no initial policy or plans for use of the keyring outside the archive. Individuals who wish to reuse the keyring for granting access to services to some or all Debian Maintainers may do so according to their own judgement, of course.

In particular, this means that Debian maintainers do not participate in the general resolution procedure defined in the Debian constitution, and cannot vote in Debian elections.

Quorum

With the current list of voting developers, we have:

 Current Developer Count = 1049
 Q ( sqrt(#devel) / 2 ) = 16.1941347407016
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 48.5824042221049

Quorum

Option1 Reached quorum: 212 > 48.5824042221049

Data and Statistics

For this GR, as always statistics shall be gathered about ballots received and acknowledgements sent periodically during the voting period. Additionally, the list of voters would be made publicly available. Also, the tally sheet may also be viewed after to voting is done (Note that while the vote is in progress it is a dummy tally sheet).

Majority Requirement

The proposal needs simple majority.

Majority

Option1 passes Majority. 1.594 (212/133) >= 1

Outcome

In the graph above, any pink colored nodes imply that the option did not pass majority, the Blue is the winner. The Octagon is used for the options that did not beat the default.

Option 1 Endorse the concept of Debian Maintainers
Option 2 Further Discussion

In the following table, tally[row x][col y] represents the votes that option x received over option y. A more detailed explanation of the beat matrix may help in understanding the table. For understanding the Condorcet method, the Wikipedia entry is fairly informative.

**The Beat Matrix**
	Option
	1	2
Option 1		212
Option 2	133

Looking at row 2, column 1, Further Discussion
received 133 votes over Endorse the concept of Debian Maintainers

Looking at row 1, column 2, Endorse the concept of Debian Maintainers
received 212 votes over Further Discussion.

Pair-wise defeats

Option 1 defeats Option 2 by ( 212 - 133) = 79 votes.

The Schwartz Set contains

Option 1 Endorse the concept of Debian Maintainers

The winners

Option 1 Endorse the concept of Debian Maintainers

Debian uses the Condorcet method for voting. Simplistically, plain Condorcets method can be stated like so :
Consider all possible two-way races between candidates. The Condorcet winner, if there is one, is the one candidate who can beat each other candidate in a two-way race with that candidate. The problem is that in complex elections, there may well be a circular relationship in which A beats B, B beats C, and C beats A. Most of the variations on Condorcet use various means of resolving the tie. See Cloneproof Schwartz Sequential Dropping for details. Debian's variation is spelled out in the constitution, specifically, A.6.

Manoj Srivastava

Proposal and amendment	Thursday, 21^st June, 2007	Wednesday, 27^th June, 2007
Discussion Period:	Wednesday, 27^th June, 2007	Saturday, 21^st July, 2007
Voting Period	Sunday, 22^nd July, 00:00:00 UTC, 2007	Sunday, 5^th August, 00:00:00 UTC, 2007