On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote:
> Stefano Zacchiroli <zack@debian.org> writes:
> > 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.
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).
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.
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.
> > 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.
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.
> > 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.
In the specific case of init systems, I agree.
> > 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.
Fair enough. Thanks for sharing!
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