On Sat, Mar 21, 2009 at 11:34:57AM +0200, Lars Wirzenius wrote: > What's your opinion on membership procedures? > > Last year there were some rough proposals for how to change the > membership procedures. It started with Joerg's proposal, but other > people suggested their own kinds of changes, including me. I feel > that my approach and Joerg's are pretty much diametrically > opposed. What's your opinion? Do you feel the current NM process > works well and almost always selects for the kind of people that are > really great for Debian? Would some other kind of process work > better? What kind of membership process would you like to see in > Debian in, say, a year from now?
Heya, here I am after having re-read your proposal (which I take, from
your reply, has not been significantly affected by the resulting
discussion).
You ask me to dream, ... let's dream.
I dream of:
- an NM process where the enthusiasm of applicants does not encounter
frustrations due to delays they cannot understand
- a project in which not only technical skills matter for being able
to vote
- membership principles which acknowledge the level of commitment
contributors are willing to offer: if in the beginning you are
willing only to work on X, you will be able to work on X, getting
from the project the credit and the recognition you deserve; if you
are willing to do more you will get more tools to do that and more
credit for your achievements
- a do-ocratic project in which everybody is free to temporarily
leave when real life strikes back, with no shame, and come back
whenever he/she wants and has time again to contribute
- a project where core teams, on the work of which the whole project
depends, exhibit no concentration of powers. That is:
* job descriptions are crystal clear,
* "recruiting" procedures are as clear and always open to new
applicants,
* team members are on the order of 10 people rather then 2 (no
problem if one is *the* leader, but the others should be able to
backup him/her up in case of emergencies),
* there is no overlapping of people among the core teams,
* there is no bureaucratic bottleneck imposed by the fact that core
teams are under-staffed.
Now, regarding the two proposals. Joerg proposal [1] was an
_evolutionary_ one starting from the status quo, introducing a new
class of non-technical contributors, and also meant to fix (as I
interpreted it back then) some of the technical oddities of the
current DM/DD duality. The main problem of that proposal has been in
the way it has been pushed; a way which has been refused [3] for that
reason.
Your proposal [2] touched more subjects which IMO warrant separate
discussions. I'll comment on the main topics.
- Project membership should expire: full ACK.
The way you propose to achieve that (putting into use the right to
vote) is not the only possible way, uploads are another, but I agree
with the principle, the rest are details at this point.
- All members get both voting and upload rights: not sure.
I've no strong objection, but I've the impression that there are out
there contributors which couldn't care less about upload rights; if
this is so I don't see why giving them that (if you want: don't fix
what is not broken). Same goes in the other direction.
- Expulsion via GR. Yes, makes sense.
It is a scenario rare enough where we don't need to appeal to
representative democracy to handle it, as we currently do with the
over-engineered expulsion procedure.
- Join via consensus: agreed in principle, worries about practical
applicability.
We have a lot of sub-areas in Debian, areas which do not necessarily
know each other. NM are often willing to join because they are
interested in a single area. Asking for project consensus sounds me
a bit odd. E.g.: I don't know what I can say about the acceptance in
Debian of a guy interested in working on translations or Java
package maintenance, while I can have a lot to say about the
acceptance of a guy interested in maintaining OCaml packages or the
PTS. I would be much more in favor of join via a philosophy and
procedure and then delegate technical skill review to the teams the
NM is planning to work in in the beginning (which would also give
some guaranteed of social interaction ability).
- Keyring maintenance: agreed with what you wrote, which however in my
mind settled down a bit differently "let's enlarge the keyring
maintenance team, and use jetring". This, however, is an example of
a point which deserves IMO a separate discussion, asking keyring
maintainers for comments.
A final remark. Choices like the above one need project ultra-wide
discussions and clear decisions via GRs. What I will do as DPL, if the
time come, is just to ensure that we clarify the available options
(yours being one of them) and have a vote on them; the DPL should do
no more than that.
Cheers.
PS Yes, I know you did not ask for explicit comments on your proposal,
but I had the impression that other thread followers were
interested, and then felt like commenting with more details.
[1] http://lists.debian.org/debian-devel-announce/2008/10/msg00005.html
[2] http://lists.debian.org/debian-project/2008/10/msg00145.html
[3] http://www.debian.org/vote/2008/vote_002
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
