It's all about trust
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/
Reply to: