Re: More votes in Debian? Any idea for improvement?
Stefano Zacchiroli <zack@debian.org> writes:
> On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote:
>> 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.
> Yes, exactly, I agree with this analysis, even though we probably have
> different perceptions of the various reasons why people would not be
> willing to refer issues to the technical committee. I'm probably biased
> by the fact that I've been "used", as DPL, as interface for questions
> like "should I refer this to the tech-ctte?". As such, I'm probably more
> aware of the negative part of the reason (delays) than of the positive
> one (preferring consensus).
That's good data to have. Thank you.
> Still, it should be pointed out that there often are people on the
> "losing" also for the "status quo" options. Those you mention as
> frustrated by the status quo are the people on the losing side. No less
> than the people who would be on the losing side for decisions taken with
> methods other than consensus.
That's true.
I think that the consensus process stands a better chance of making
everyone happy with the eventual outcome, but it's important not to
confuse "exhausting some of the parties so that they go silent" with
"making everyone happy," and I agree that the consensus process can do the
former as much as the latter. And interminable discussions are also
demotivating, and I can see plenty of situations where interminable
discussions are more frustrating than having someone make a decision that
one disagrees with but which at least has been made.
> I don't want to argue against consensus-based decision making, because I
> love it as a default mechanism. But I don't think it is correct to
> believe it is immune from the "losing side" issue.
Agreed.
> I don't have more than gut feelings to offer on this. But mine is that
> there are technical decision chapters --- again, mostly in the area of
> default picking --- where the bar for questioning past decisions is
> perceived as too high. Nobody wants yet another inconclusive -devel
> discussion on what is the default $this or $that, so we simply avoid
> discussing those. The matter is simpler to settle when the jurisdiction
> of the default picking is well defined (e.g. default settings for a
> specific package), but it is not when jurisdiction overlaps.
That does seem like a good place to add a somewhat more hierarchical
process, such as a time-boxed discussion on debian-devel (say, a week or
two) followed by a tech-ctte decision taking into account the debian-devel
discussion.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: