[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Judging consensus at in-person meetings

Hi Ximin,

Thank you for the thoughtful feedback!  I appreciate it very much, and I
think you've made a number of good points.

I'm not sure I have a whole lot to add other than that I'm still thinking
about your points for further discussion later of other Policy issues (and
I completely stand by my decision in this specific case).  I did want to
clarify a few things touched on here, though.

Ximin Luo <infinity0@debian.org> writes:

> I was more responding to a more general pattern that I notice, of
> mentioning this idea of "consensus at physical meetings" as one way in
> which to justify something. For example Russ also mentioned "very
> difficult to judge consensus over email because only the strong opinions
> are visible". This was in response to Adrian's comments criticising
> certain parts of the text.

> The way that this is worded implies (a) that "strong opinions" is a bad
> thing, and (b) that this is an accurate description of email
> discussions. I neither believe (a), nor I do think Adrian was expressing
> a "strong opinion" - i.e. (b) is not always an accurate description of
> email discussions.

On point (a), I think I expressed this poorly.  It's not strong opinions
that concern me; strong opinions are common, and when they drive people to
do work, that's great for the project.  Rather, it's a couple of different
patterns: paralysis in the face of a small number of heartfelt objections,
and dominance of a conversation by people who are willing to persistently
write the longest email messages.  In this specific case, it was the first
of those two that I was looking at: were we in danger of getting paralyzed
by a small number of heartfelt objections, and was it worth investing more
time in trying to address those objections?

Determining whether either of those things is happening is always a
judgement call.  But I think project members should feel themselves called
on to make those judgements, even if they get it occasionally wrong.  One
of the things that worries me most about Debian (and we've had lots of
conversations about this in various places at various times) as a whole is
the risk that we become more and more change-adverse and essentially
discuss things to death as long as anyone has any objection, and thereby
starve the project of energy and forward movement.  Sometimes it's good to
try to convince everyone; sometimes it's better to say "I hear what you're
saying, but I don't think the objections you're raising are overriding and
I think the risk is low, so we're going to go forward anyway."

I love email as a discussion forum, but one of its flaws that is important
to keep in mind is that a lot of people will stop participating when
threads get beyond a certain length, and most people don't have the time
or patience for long threads with lots of repetitive back and forth.
Sometimes you have to find more creative ways to get information that
you're looking for and realize that you may be hitting a limitation in
email when discussion goes into extended back-and-forth between two or
three people and everyone else tunes out.  (Honestly, a lot of those
threads are *not* particularly thoughtful so much as persistent, which is
not the same thing.)

Anyway, on the specific point of consensus on reproducible builds, I
almost certainly overstated the importance of an in-person check at
DebConf.  The foundation of my belief on general consensus on *direction*
(*not* on the details of the wording) is the actual behavior of the
project over the past four years.  This is something we've talked a lot
about, and this is something we've done a lot of work on, and it's fairly
clear to me that it was embraced by the project.  I would have felt
comfortable making that call without DebConf, and didn't make that clear,
but the final check at DebConf (and other in-person discussions) was also
helpful just as a sanity check.

Please note that was consensus on a Policy requirement, not consensus on a
specific wording.  The specific wording discussion is separate, and there
was a lot of discussion in the bug about why this specific wording and not
other types of wording.  I'll leave that for the bug; I think I've already
belabored my reasoning sufficiently and no need to go into it again for a
different list.

I don't think I expressed the above all that well in the message to which
you were originally responding.  Hopefully this is a bit clearer.

One final point: thoughtful objections are sometimes valuable, but what's
usually more valuable to the project is thoughtful understanding of the
goals that someone is trying to achieve in Debian and figuring out how to
constructively help them achieve those goals.  If one can put one's
objections in the form of a constructive patch, or at least a proposal for
the patch that should be written, that's a lot more valuable to the
project than just objecting.  Sometimes this is called "bias for action":
most decisions are reversible, and most changes can be more easily refined
once there's a foundation in place for further refinement.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: