>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:
Charles> Le Sat, Jul 18, 2015 at 01:56:49PM +0000, Sam Hartman a
Charles> écrit :
>> >>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:
Charles> Also, the question is not whether the FreeDesktop menu
Charles> should be described in the Policy or not, or how to split
Charles> the proposal in 3, 4 or 42 parts. It is not even on
Charles> whether the Debian menu should be a "must" or a "should",
Charles> because for that as well, we got a "rough consensus", where
Charles> at the end of the process there was only a single person
Charles> opposing the change. Neither it is about re-starting a
Charles> search for people disagreeing (or shall I restart a GR on
Charles> systemd ?). The question is whether a single individual
Charles> can engage in confrontational commit wars to block changes
Charles> in Debian.
I hear your frustration that a proposal you worked on has been blocked
for over a year by the actions of one person.
For myself, though, I'd like to think of the questions differently,
because I'd like to grow from this experience.
Bill, in his role of policy editor said that he believed there was not a
consensus. He cited a specific set of messages that he believes were
not properly addressed.
I do think it is the job of policy editors to be involved in judging
consensus.
I've been in the position of judging consensus, and made unpopular
calls.
It's hard. You know you'll face others with strong negative feelings.
You're typically worried about whether you're making the right call.
You're typically hopeful that others will clearly see your point even
when they disagree. You're frustrated when that doesn't happen.
While I disagree with Bill, I respect him when he makes a hard call like
that.
I agree with Charles though that one person should not be able to block
the process.
My hope for improvement is in how we handle things when a policy editor
or someone else in a similar role in the project claims we don't have
consensus. What do we expect from our consensus judgers moving forward
in such situations? What do we expect from ourselves as advocates of
proposals? What is the process?
I'd like to share a couple of my thoughts. I'm nervous that in doing so
I'll bias the discussion more than I like. However, I'm more concerned
that unless I give some constructive examples of what I'm talking
about, it will be hard to move forward.
A lot of my experience with consensus process is in the IETF. There, if
you're in a position to judge consensus, you have an obligation to help
try and build the consensus when you judge that there is not consensus.
If you're in a position to judge consensus, you have an obligation to
lead the discussion, to focus on areas of disagreement, and to see if
your consensus call is correct. There's an expectation that when you
call a lack of consensus, getting to consensus is going to be a
priority, and you're going to put in significant time to help.
Should some or all of the above be part of what we expect from policy
editors?
On another axis of the discussion, what's the appeals process? Where do
you go when the discussion stalls or reaches an impass? (In general,
that should not be the immediate reaction to a call of lack of
consensus; such a call is generally the start of a very fast-paced
discussion.)
Charles tried the TC in this instance.
I think the TC has the expertise to review the technical aspects of
these matters. I think that's actually important to reviewing a
consensus discussion, and is most of the skills you'd need to review
this sort of consensus evaluation.
However, I think the TC might be more effective in situations like this
if it better understood its role. There was significant disagreement
between the members of the TC Charles brought the issue to and Charles
about what the role of the TC should be. During the process, the TC
membership changed, and today, I'd say that the TC is probably unsure
what its role should be here. For reasons I don't fully understand, the
TC process was slower than I'd like.
I hope by focusing on questions like these we can grow from this
experience and be better positioned to resolve future situations where
we're unsure about consensus. I hope we can treat everyone with
respect--those judging consensus, those reviewing that decision, those
disagreeing with that decision, and those who just want to see forward
progress.
thanks for your consideration.
--Sam
Attachment:
pgpnagtt_Xwuq.pgp
Description: PGP signature