On Fri, 24 Oct 2008, Lars Wirzenius wrote: > I think we should go in the opposite direction: massively simplify > the whole membership thing.
I tend to agree on the description of the situation but I would also add that we effectively have a trust problem within the project and that any reform to the membership management must solve that problem. We do have DD that are okayish at packaging what they package but that I wouldn't trust to advocate new DM/DD or that are not good enough in sponsorship or that I wouldn't trust to maintain any complex software (think library or essential packages). As such I really don't buy that all DD should be equal when it comes to technical work however I do think we have to move in the direction where we broaden our membership to new kind of contributors and that all contributors should have the possibility to request all kinds of privileges (mainly vote right, limited upload right, full upload right, right to grant privileges to others). The set of contributors with the right to grant privileges to others could be called "Debian Community Managers" and would only comprise very skilled and dedicated members. This group would replace the NM team and would grant/retire privileges according to their own judgment and a set of reasonable rules to define. The initial set of community managers would be designated by a vote. Ideally the group of community managers would evolve to cover all the main teams of Debian so that for any privilege request we have one or more members that are well placed to evaluate the work of others. All the rules would have a single purpose: keep the initial trust placed in people intact and make sure we remain the quality distribution that we are supposed to be. I'm afraid we lost that trust a few years ago while the NM process was more an academic study than an apprenticeship. Now, let me illustrate the above explanation with some examples of how all this could work in practice: - any new contributor would register in nm.debian.org and have to go through the initial set of hops to upload a gpg key and sign an agreement that she will pursue the goals of Debian and that she agrees with all the foundation documents. - she contributes in the way that is of interest for her - if she has worked on a particular package she can request upload access for this package like we do for DM currently: she needs a sponsor first (someone with full upload rights) and two advocates (they should have uploads rights to the package that she request access to), and of course she needs her key to be signed by a Debian Developer. - if she needs a shell account on specific machines that can be granted provided that she follows the requirements defined by the DSA team. - if she's already a skilled hacker and interested in generic bugfixing she could in theory immediately request full upload rights but that would be the exception at this point I guess. - when she has contributed for more than 6 months (those 6 months need not happen after the registration on nm.debian.org) she can request the privilege to be a Debian Developer. This privilege entails the right to vote and to have the @debian.org email. The community managers just make sure that the contribution is real and that she understands how to handle her GPG keys and under what conditions she can sign someone else's GPG key. - if she decides to do more transversal work on the distribution she can request "full upload rights" for this but the community managers will have to gain confidence in her ability to not screw up by reviewing several uploads that she prepared/already got sponsored. They might attach some remarks like “limited to l10n/i18n work” or “limited to perl related packages” if the access has been requested for specific tasks instead of generic (bugsquashing) work. This remark is informational only but can be taken into account if someome later complains about a bad NMU or any other problem with her work. The community managers really try to ensure hard that all people with full upload rights are aware of their responsibility when they sponsor people and when they advocate other people for a grant of some upload privilege. They also ensures that the people are either very skilled, or aware of their own limits so that they avoid touching things where they are not skilled enough. In practice, we replace DAM + Front Desk + AM by a single team where each member can do all the steps to grant privileges to any contributor provided that he can justify/document that the contributor matches the criteria defined. I wouldn't replace the keyring team because I believe that it's best managed by a limited team but its role is only administrative since the decisions are taken by the community managers anyway. The community managers would also have to deal with complaints about contributors making bad use of their privileges. They would have the power to remove some privilege if needed. We also have to define some procedure to grant those privileges to the actual DD. All DD would keep their vote right, but would be granted either full upload rights or limited uploads right depending on their past usage of their rights. Sponsors, NMUers, porters get full upload rights and all other get limited upload rights to their own packages. That's it. There are many details/rules/guidelines to define yet but I believe that such a scheme could simplify our procedures while still improving the trust level of our membership process. It really maps better to the reality of our work and the way we build trust relationship (in a similar way to the web of trust for GPG identities). > The other end of the membership process is screwed up too. We should not > have to actively seek out members who are Missing In Action. Staying a > member in Debian should be an active process: if you don't do anything, > you should be automatically retired. Agreed. This part of your proposal is mostly fine with me. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]