Re: More votes in Debian? Any idea for improvement?
Thomas Goirand <firstname.lastname@example.org> writes:
> If you see projects like Openstack or oVirt (sorry for the examples
> taken from my area of expertise...), they have elections every 6 months
> for project leaders in this or that area of the project.
> In Debian, we just elect a DPL, and then we hope that he appoints people
> who then can make decisions on the behalf of Debian.
My opinion on this is very similar to Zack's and Wouters: technical
decisions should be made by the appropriate teams, not by voting, unless
There are multiple reasons for that, including, but not limited to:
* The teams having more insight into their job than the project as a
whole allows them to make better informed decisions more quickly.
* We should not bring politics into technical decisions, that's never
good. Appointing delegates is often a technical decision, and even if
it has other components, the tech part of it is still significant.
* Debian is a do-ocracy in many areas, recognising that with delegation
is, in my opinion, the right way to do it. Turn it into a vote, and
then it will quickly become a talk-ocracy.
* Generally, we should trust our teams to do their jobs well. In case
of problems, we have ways to fix it (revoking delegations,
etc). Reassuring team member positions by a project-wide wrote every
year (every 6 months would be even worse!) would just put extra
burden on both the Developer body as a whole, and the team members
for, I believe, no real gain.
> I feel strange that such a big project as Debian appears to work in a
> less democratic way than some software which has adopted open governance
> (truth, this is the new hype, but still...).
There are things that work for other projects, but don't work for
us. Excessive voting is one of those things. It works well if you have a
small core of about a dozen people or thereabouts. If you have close to
a thousand, even if only a third of those actively participate in
voting, that's still a huge number.
We also have a lot of teams, who just get the job done. I see no reason
to hinder their performance by making their position a matter of voting:
most likely, they'd be appointed anyway, and we wates time and effort of
both the team members, and of the voters too.
> I see no reason why we couldn't have more direct appointments for key
> positions in Debian. I feel like it would be possible to have more
> democratic, ways to do things, with direct votes.
I disagree. I believe in do-ocracy, and that it has served us well over
the years, and I'm confident it will work in the future too. On the
other hand, I've seen projects that strived to be openly governed fall
flat to their face and accomplish nothing.
Direct votes introduce an unneccessary burden and a bit too much
politics into what is almost entirely a technical decision best left to
be made by those who work in or close to that area.
> Also, on the opposite side, the DPL is currently having to appoint
> regularly others, which is only a formal thing and is sometimes a
> useless loss of time (maybe Zack can tell a bit more about this in a
> better English than mine...).
I believe it still takes less time, and only from a handful of people,
than a vote would, and the results would be pretty much the same.
> What are the improvements in this area that our 2012 candidates foresee?
There are of course, shortcomings of the current system (see Zack's
explanation), which might be improved upon.
The idea of self-determining, non-synchronized time-limited memberships
is interesting, but for that to work, we'd need a slightly larger pool
of people to work with. That happens to be very much in scope for my
plan of encouraging people to work with the core teams, and to make
those key positions and teams more attractive.
In summary, I find project-wide voting boring and unneccessary. Once or
twice a year is more than enough, more would be counter
productive. Smaller-scale votes, within teams is another thing, that can
work, and can result in improvement, but that has a few prerequisites to
function well - see above!