Following Ganneff’s post to debian-devel-announce, several discussions have again started on the topic of Debian’s membership and several proposals have been made. Unfortunately none of these proposals try to resolve the underlying trust problem that has been growing over the years. Despite the NM process (or maybe due to it), we managed to give DD status to people who are motivated but whose technical skills are doubtful (at that point people ask for an example, and as much as I hate fingerpointing, here’s an example with #499201. The same maintainer created troubles with libpng during the etch release cycle and tried to take over a base package like mawk recently).
With our current model, all DD can sponsor, NMU, introduce/adopt/hijack packages without review. This is fine as long as we trust the body of DD to contain only skilled and reasonable people. I believe that premise to be somewhat broken since Debian has become too big for people to know everybody and since the NM process had no way to grant partial rights to volunteers who were motivated but that clearly had not shown their ability to handle more complex stuff than what they had packaged during their NM period (like some trivial perl modules for example).
Thus I strongly believe that any membership reform must provide a convincing answer to that trust problem before being implemented. I took several hours to draft a proposal last Friday and I’ve been somewhat disappointed that nobody commented on it. I hope to draw some attention on it with this blog post.
The proposal builds on the idea that we should not have “classes” of contributors but simply two: a short-term contributor and a long-term contributor (those are called Debian Developers and have the right to vote). But all contributors can be granted “privileges” as they need them for their work and each privilege requires the contributor to fulfill some conditions. The set of privileges and the conditions associated all need discussions (but I have personal opinions here, see below). There’s however one privilege that is somewhat particular: it’s the right to grant privileges to other contributors. Handling it as a privilege like another is on purpose: it makes it clear that anyone can try to get that privilege and the procedure is clear. In practice, imagine that set of people as a big team encompassing the responsibilities split over DAM/AM/FD/DM-team and where all members can do all the steps required to grant/retire a privilege provided that 2 or 3 members agrees and that nobody opposes (in case of opposition a specific procedure is probably needed). I called that set of people the Debian Community Managers. It should contain only skilled and dedicated developers.
One of their main duties would be to retain the trust that the project as a whole must have in all its members. They would have the powers to retire privileges if they discover someone that has not acted according to the (high) expectations of the project.
Among the privileges would be “limited upload rights” (like DM have currently), “full upload rights” (like DD have currently although it might be that we want to split that privilege further in right to sponsor, right to package new software, right to maintain a package of priority > standard, etc.) and “developer status” (email + right to vote, once you can prove 6 months of contribution).
There’s lots of stuff to discuss in such a proposal (like how to decide who gets what privileges among existing DD) but I think it’s a good basis and need some serious consideration by all the project members. The NM process is there only so that we can collectively trust that new members are as good as we expect them to be and trust can only be built over time so it’s good that we can grant privileges progressively.
Some people believe that I’m reinventing a new NM process that will end up to be very similar to the current one. My answer is that the conditions associated to each privilege should be based on the work done by the contributor and the advocations that he managed to collect. It should not be a questionnaire like “Task and Skills”. This, together with the distribution of the power/work on many people, would render this system very different from today’s NM process.
Some people believe that I’m copying Ubuntu when designing this since it’s somewhat similar to the process to become MOTU and/or get upload right to Ubuntu’s main component. Let me say that I’m not copying deliberately at least, I simply took the problem from the most important side. But remember that many aspects of Ubuntu have been designed by Debian developers that tried to avoid known pitfalls of Debian, and maybe they got some things right (or better at least) while doing this.
“I called that set of people the Debian Community Managers. It should contain only skilled and dedicated developers.”
That notion makes me very scary from the beginning.
I have already blogged about this.
If you want to build such an injust system, then these persons have to be strongly supervised and limitated in any possible abuse.
Until you clearly state how you plan to choose them, and until it is not *strongly* and *clearly* affirmed that this has to be *transparent* and *controled* by the *majority* and *votes*, I will fight to the death such a proposition.
And consider other bad alternatives is it happens.
Otherwise, it could be fine. But don’t forget the big picture when trying to solve a specific issue.
Everything is always controlled by votes as last resort in Debian since you can ask for a GR. And for “transparent”: of course, all the decisions taken by community managers should be public and taken publicly.
The mail on -project suggest to use a vote to elect the first set of community managers. After that the set would evolve according to the predefined rules to handle the corresponding privilege. If it ever goes wrong, we can bootstrap the process again with a new vote/election.
“After that the set would evolve according to the predefined rules to handle the corresponding privilege.”
This is completely dangerous. you simply can’t hope that the highest level of power is a group of people, even elected at first place. The highest level of power has to be the developpers, the ground, people.
I do not mean “if it goes wrong”, I mean in any case.
There is, more generally, a real motivation behind the fact that every democratic system regulary draws again the roles trough elections, and not only on a per-abuse case.
I will try to write a more complete post to planet on this topic very soon.
Right now you don’t have anything to say on who is the DAM and the power is even more concentrated…
Anyway, if you want regular election, we will end up with the problem that non-technical members will end up deciding who are the skilled technical members that should be community managers. That’s acceptable as last resort when the system goes wrong but not really as default mode of selection.
One way to reduce the problems could be to say that a community manager can only grant a right that he also has on the basis that having this right means that he’s probably able to judge if someone would make good use of that right.
What if we kept the general developer body in control by putting the Debian Community Managers up for election every couple years?
Ken, why would that be more needed than for ftpmasters or security team?
I understand it’s a sensitive subject but I don’t think re-election are needed as long as the system works. If you want explicit safety measure, we could say that the DPL could trigger a re-election for example exactly like the developer body can by starting a GR.
I believe that some continuity in this set of people is even more desirable than in any other team so I’d rather not have regular re-elections.
I won’t argue more since I have posted a message long enough on planet, but I strongly disagree on this.
I’m not sure it’s a good idea. I don’t personally think Debian needs to be as much of a democracy as people think, but wanted to throw the idea out there as a possible direction in case the demand for accountability to the general body of DD’s is as big an issue as it seems from what I keep reading.
I don’t know why you said no-one commented. I thought there were several follow up replies on the mailing list. I’m not a DD so mine is the view of a mere user, but I think your proposal radically changes what Debian is, and I would be much less motivated to get more involved in the project. However, there is a lot of feeling that improvement is needed.
I like perl, and I like the philosophy about proudly stolen elsewhere. There are so many precedents for loosely-affiliated but strongly regulated social organisations that Debian could copy from. For example, a professional accounting body. First step is to be an associate member, requiring a one of a number of recognised degrees, and a simple introductory exam, plus references from existing members. After an apprenticeship of two to three years, and a series of exams, you become a member. To keep membership, you must complete a certain amount of professional development points every three years; a broad range of activities count, such as giving presentations, mentoring, have articles published, or even documented self-study programs. Debian has nothing like this at the moment.
If you want to go into public practice (sign off an audits, offer tax advice) you need to complete some specific exams, but you have the same voting rights as other members. (This reminds me of what DD status should be like). Also, all accountants with public practice licence can equally serve all clients, but there are strict ethical rules about moving clients between accountants. Sound like the NMU guidelines, a bit. Note that there is no restriction on someone whose experience is entirely with automotive clients taking on a hotel client, but the code of practice requires the accountant to self-assess if they have the rights skills. Ultimately, serious mistakes here could be the subject of a membership review by the membership committee.
The association is run by an elected committee, who have the right to audit membership status (deviations from the code of ethics, failure to meet professional development points). Very experienced members or members who have distinguished themselves can be elevated to Fellow, but this doesn’t carry more rights.
So elevation to voting membership is based on exams and apprenticeship. Some special rights are limited to those who have taken additional certification, but once those rights are granted, the powers are wide, limited by self-regulation. Members are bound by a voluntary code of conduct, which is reviewed by a membership committee. Membership can only be maintained by following a program of “professional development” which is broadly defined.
Tim, when I wrote my post nobody had commented during the whole weekend, only yesterday I got some feedback by Lucas Nussbaum.
Your position is not clear, what would make you less motivated to get involved ?
Your examples are nice but I find them very similar either to what we have in the NM process or to what I suggest: “exams” are questions like Tasks and Skills in the current process. Right now all DD have the same extended powers and we rely on anyone to self-assess that they have the right skills to maintain a given package. The “membership committee” is nothing more than my “Community Managers”.
My example is an organisation where once certified to be a full member, the powers are equal and self-regulation is the primary way to control the use of those powers, although with a supervisory committee able to revoke membership in exceptional circumstances. Plus membership must be maintained through a continuous professional development (CPD) program.
Such a committee and the CPD would be enhancements to Debian membership. Obviously you can’t have a CPD-type program without an enforcement body. The committee is not made of dedicated resources; it is resourced by active members who find time to serve the community in this role; this is a good way to make sure things don’t get too bureaucratic.
I understood your proposal to be significantly different: grant narrow powers, and then case by case and application by application, offer more powers. I like the more liberal idea: once you’re a member of society you can do anything that’s not forbidden. Of course, the community managers are elected, but it’s a big concentration of power, and if you install a state, you somehow need to pay for it; in this case the scarce resource would be time. How will these people dedicate time? This role would take time and skill. I think Community Managers would become politicians, or the politicians would become Community Managers. Things would have to be really broken for such a big change. I wonder if that’s the case. If I had a vote, I need more convincing than one bug.
Please can we discuss this after the current release?
And now I expect Spam Karma to eat this.