NM Reform (Alternate Suggestion)

Summary

Raphael has [wiki:Projects/ReformedMembershipProcess suggested] a reform to the Debian membership process (New Maintainer). This is an alternative view on the membership process looking from the point of view of resource and permission granting, rather than creating artificial categories of contributor and hoping they fit everyone.

Rationale

The new maintainer process is fundamentally about granting permissions, privileges and access to resources. Currently we have an all-or-nothing approach which in turn requires prospective developers to be proficient in all fields before they can be granted access to anything. As seen in the recent Debian Maintainer threads and general resolution; there are many people who think this is not the best idea. The root of the current problem is that there are people who we wish could contribute easier, or we wish to better acknowledge the contributions of people who in either case don't fit the original model of a contributer to Debian.

When reforming the NM process we should endeavour to make as general and flexible as possible, so that when in future there are people who want to contribute in new ways we aren't again restricted by the membership process.

I propose this is best done by identifying what the permissions, privileges and resources governed by the membership process are, deciding what granularity of access control we want to provide and then determining what people need to demonstrate before being given each permission.

In this way we should be able to cope with all existing contributors and also new types of contributor we had not thought about, without defining what sort of contributions are 'allowed' in the process.

Permissions, Privileges and Resources

These are the things which the membership process grants, in no particular order or grouping:

Requirements for granting access

For each permission there should be some prerequisites which might be the holding of other permissions or things to check before granting that access. These are suggestions based upon the current NM:

The other things to which we grant access have less well-defined technical requirements and it's a social/political decision as to when to grant them. I think they should all involve at least the ID check, advocacy, SC agreement and some sort of P&P check

Possible statuses, groups of permissions et al

This is my suggestion for the granularity of access control:

Contributor

This is the basic 'class', which doesn't actually grant any of the technical access permissions, but is a pre-requisite for all the others. We might want to give out email addressess for this. The anticipation is that everyone who contributes to debian can be here. Can get sponsorship for any uploads they do (including NMU-via-sponsor; NEW-via-sponsor; updates-via-sponsor). It would be at least encouraged not to sponsor uploads from people who aren't at least a contributor.

Prerequisites:

Grants you:

Maintainer

This deals with people who need to do some package uploads. Sponsors would still need to be found for new packages to the archive and the sponsor would be encouraged to check what sort of packages they have done T&S for before uploading them with the DM-Upload flag.

Prerequisites:

Grants:

Developer

This is about archive-wide access.

Prerequisites:

Grants:

Project Member

This is about the political / governance of Debian.

Prerequisites:

Grants:

Machine User

This is about access to Debian machines

Prerequisites:

Grants:

Summary

Each 'type' of Debian involvement is about the rights they have, not about what they do. This is a general way of denoting membership which applies to any sort of contribution, does not require people to learn obscure things they don't need to know in order to contribute and does not grant access where it is not required. It will cope with any sort of contributions we have thought about already, and also those we haven't.

It also allows us to grant rights slowly and use those grants of rights as a testing/probationary ground on which we can evaluate the granting of further rights.

Examples

These are the use cases taken from Raphael's page:

These are the proposed classes from Raphael's page:

There is no reason to try and classify what contributions someone is making, only to ensure that they are responsible and technically able to be granted whatever permission they need in order to make their contribution.

Implementation

The implementation would be the creation of one keyring for each category of involvement. The (new) NM process would govern access to each keyring. Obviously, each check need only be done once, the NM process would keep track of what each person still needs to do if they want to be granted extra access.

Initially all the keyrings would be a copy of the current Debian keyring (current DDs have access to everything).

The NM process should be a lot shorter to get as far as _some_ sort of access, but conversely, to be granted full access it could take longer, since we can introduce probationary periods. Making part of the process to become a Developer be spending time as a Maintainer, making quality uploads, handling your bugs etc would be a lot better than seeing if people can answer a series of questions and looking at their technical ability over a short period.

Improvement over current NM

How will this improve the current NM? Well, by splitting up the rights and checks required by them, many applicants will not be applying for the full access and will not require the full checks, which should speed up the process. It also lends itself to making the checks more of an 'evaluation of what you have done' than an 'answer questions and hope it's OK'.

There should certainly be advertisement of what is required to become each sort of Debian contributor, particularly to advocates, in the hope that people will not apply for something they are not ready for.

Problems

Probably many (-: I have not commented on who would do all the checks or manage they keyrings, whether it should be 1 AM or a committee. Feel free to list issues I've not addressed here!


CategorySpec