Re: More votes in Debian? Any idea for improvement?
Stefano Zacchiroli <zack@debian.org> writes:
> On the paper of the Constitution, the Technical Committee is already all
> we need to "cover up" for cases where decision by consensus does not
> work (I'm specifically thinking at §6.1.1 "Deciding on any matter of
> technical policy" and §6.1.3 "Make a decision when asked to do so"
> here). But in our practices, we tend to rely on the Technical Committee
> only for issues that fall in the broad category of "conflicts" (§6.1.2
> "Decide [...] where Developers' jurisdictions overlap").
> I've the impression that this is partly due to the perceived risk of
> slowing thing down forever if the Technical Committee fail to answer in
> $reasonable_time_frame.
I'm sure that's a large part of it, but I think people also avoid doing
this because it means not making decision by consensus. When some central
body hands down a decision, it almost guarantees that the people on the
"losing" side of that decision aren't going to feel convinced and are
probably going to be at least somewhat demotivated.
Now, whether the consensus process does any better at this is at least
debatable. But my impression is that it does do somewhat better, at the
cost of taking a lot of time and energy and usually multiple (somewhat
repetitive) rounds of the discussion.
The drawback of only using consensus, of course, is that it's very easy to
decide on the status quo by default. Consensus-based decision-making is
heavily biased towards the status quo, so I can understand why people who
would like to see a faster pace of change in Debian are frustrated by it.
> But I've the impression there are areas that do not quality as conflicts
> and that, at the same time, are particularly bad suited for decision by
> consensus. A specific area I've in mind are distribution wide defaults:
> what is the default MTA? the default Desktop Environment? editor?
> web-server? etc.
Do people feel like these decisions have been poorly made so far?
Personally, I think those are all cases where the project came to a fairly
reasonable conclusion, and I haven't seen a lot of lingering significant
unhappiness about them.
> The case of the default init system looks a bit different, but not
> *that* much. In a lot of default picking scenarios, there is no clearly
> technical superior solution and at the same time there are a lot of
> religious battles. That is what make them difficult to be decided upon
> by consensus.
I do think that the lack of a clearly superior solution is partly an
artifact of the fact that we're discussing all this in theory without much
practical experience with real Debian packages and the implications of a
transition or parallel support, which is one of the things that makes the
ongoing debian-devel threads frustrating.
> If you now allow me to twist a DPL candidate question to a Technical
> Committee member question :-), do you think default picking topics would
> be appropriate tech-ctte decisions under §6.1.1/§6.1.3 ? With all the
> needed disclaimers, of course, e.g.: after substantial discussion
> elsewhere, assuming the tech-ctte can decide in $reasonable_time_frame,
> etc.
Yes, I do.
But I'm reluctant to put any weight on that until the tech-ctte is
resolving the issues that it's already dealing with in a more timely
fashion.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: