On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
> 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.
>
> 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...).
In talks about Debian, I always mention decision making in Debian as one
of the distinguishing features of our project. But I always also points
out that democracy is just one ingredient of it and that we have a
culture of using votes only for "political" issues and not for technical
issues.
Voting on technical matters, or to elect technical bodies, works well
for projects that have a more narrow scope than Debian. There are Free
Software *development* projects that use vote among developers as a way
to decide whether to give commit access to someone or not, for instance.
But at the Debian scale, I don't think vote should be used to decide on
technical merits, to choose technical solutions, or to elect technical
bodies. It will be democracy, sure, but I believe it will be less
effective than our current mechanisms at guaranteeing technical quality.
> 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.
>
> 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
There are problem with delegations, yes. We have two kinds of them
"permanent" (i.e. until step down or recall) and time-based and both
have issues:
- permanent delegations do not encourage periodic self-assessment of
delegates on whether they are still motivated to do the job; they also
risk to create power niches that require a lot of energy to fix, due
to social awkwardness.
- time-based delegations do not have those issues, but put the burden on
the DPL who periodically needs to renew them, and hence risk to become
a bottleneck
Delegations are a bit of an archaic device. It made a lot of sense in
the era of Free Software "benevolent dictators", but that era seems to
be fading away more and more, at least for large projects. And indeed we
have adapted our use of delegations over time. The fact the elected DPL
can recall or appoint delegates is very useful, as it balances power,
and has indeed saves us in the past. But these days, and outside those
exceptional situations, no one would expect the DPL to, say, appoint or
recall a "core team" member without the team consent. Those teams are
already self regulating a lot. IME the DPL "simply" watches out for
teams who are in need of re-staffing or staff change and actively
proposes that, possibly looking for candidates, if the team is not doing
that in autonomy.
But the above is quite a burden and in the end makes the DPL job not
particularly scalable and highly dependent on experience and "people
skills". There are established alternative solutions these days and I
think we should learn from them. For instance, other projects have
various kinds of self-determining boards with non-synchronized
time-limited membership. At each expiry a new member can get in or the
old one can try again; who gets in depend on the collective decision of
the others, non-expired, members.
The above can be done in very lightweight ways, would encourage periodic
self-assessment of motivations, would discourage the formation of power
niches, and still would not be prone to choosing the "more popular" (but
possibly unfit for the team in question) among wannabe members. I've
been studying what others projects have been doing on this front and I
look with favor at similar micro-governance models.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature