[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: All candidates: Membership procedures

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

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
  * 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

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

  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.


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
zack@{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

Attachment: signature.asc
Description: Digital signature

Reply to: