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 <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/>
