>>>>> "Tollef" == Tollef Fog Heen <email@example.com> writes:
Tollef> Consensus are at least two things: «Are everybody
Tollef> ok/happy/ecstatic about this?», and «Are somebody unable to
Tollef> live with this resolution». Those are different things, and
Tollef> I don't think we're entirely clear on which of those we're
Tollef> loooking at. AIUI and IIRC, Sam has a strong IETF
Tollef> background where it's more about the second type of
Tollef> consensus than the first. (Please correct me if I'm wrong
I'm really excited thinking about this. thanks for raising the
I'm not actually sure they are that different. I think there is a
continuum between the two that depends a lot on the circumstances.
For example, If you have broad agreement that making some sort of
decision is important, and no one is happy/excited about the options,
you quickly find yourself in the land of "can people live with this?"
However in cases where you could do something but there's not agreement
that some decision is required, things work out differently. If I'm
excited about some option that isn't getting adequately considered, I
won't be able to live with any of the other options until the option I
favor is adequately considered. I'll argue that since we don't even
agree that we must make some decision, it's OK if we find that no of the
options generate enough happiness to move forward and that I'd rather
hold out until something that we all love. I'll certainly try and
object to moving forward simply because some option has least
RFC 7282 https://tools.ietf.org/html/rfc7282 are some interesting
thoughts about the IETF's version of rough consensus.
I agree with most of it. As the author/editor notes, this is more about
how the IETF thinks it should work than about how it actually works.
The document is having a impact and I suspect over time the IETF will
find itself working more like that.
I don't entirely agree with section 2. That section seems to be focused
on the situation where you believe making a decision is very important
and even then doesn't seem to adequately handle the situation where
you're deciding between alternatives where you have rough consensus that
all the alternatives would work.
However, RFC 7282 does present some really interesting points that I
think would be valuable to us.
One of them is that judging rough consensus based on issues and whether
the issues have been responded to is a lot easier than trying to judge
peoples' positions. It's also a lot easier to review for anyone
considering a problem. You can say things like "You think we don't have
rough consensus. What issues were not adequately addressed." The
person raising the concern that consensus was not achieved knows that
what they need to be able to do is point at the objections that were not
However, especially for something like policy, Debian needs to make sure
there's adequate support that we have consensus we're trying to solve
the problem. "Yeah, that's a great way to generate automated package
descriptions--or at least as good of a way as we can come up with given
the state of machine learning and translations. However, we don't
*want* a policy for generating automated package descriptions."
Is that getting to the point you made about eager//happy/ecstatic in
I'd be really interested if you could point me at documents that talk
about the sort of ok/happy/ecstatic type of consensus so I could read
them and see if I still think my idea that it's all a continuum
depending on what you're doing is correct.