Bug#741573: #741573: Menu Policy and Consensus
Charles == Charles Plessy ple...@debian.org writes: Charles Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a Charles écrit : Bill == Bill Allombert ballo...@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 pgpTPlk83YIrd.pgp Description: PGP signature
Bug#741573: #741573: Menu Policy and Consensus
Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a écrit : Bill, in his role of policy editor said that he believed there was not a consensus. Hi Sam, I think that what you wrote does not reflect what happened: - Russ gave me the green light for committing the changes, see https://lists.debian.org/debian-policy/2014/02/msg00068.html. Only Policy Editors can decide that a change will be committed, thus it is my understanding that Russ, as a Policy Editor, judged that there was consensus. - Without consulting with the other Policy Editors, Bill reverted the commit. This solo action was done out of the usual process for seeking consensus before changing the Policy. 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? I totally share this point of view. (This is why after leading the release of the Policy version 3.9.5.0, seeing that I would not have time to do the same within a year or two, I quitted as a Policy Editor). On another axis of the discussion, what's the appeals process? The only appeal I would see would be through the DPL, since he appoints and replaces the Policy Editors, who are DPL delegates. Have a nice Sunday, PS: I will be on business trip in Trieste for one week. Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150719123950.gb4...@falafel.plessy.net
Bug#741573: #741573: Menu Policy and Consensus
Charles == Charles Plessy ple...@debian.org writes: Charles Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a Charles écrit : Bill, in his role of policy editor said that he believed there was not a consensus. Charles Hi Sam, Charles I think that what you wrote does not reflect what happened: Charles - Russ gave me the green light for committing the changes, Charles see Charles https://lists.debian.org/debian-policy/2014/02/msg00068.html. Charles Only Policy Editors can decide that a change will be Charles committed, thus it is my understanding that Russ, as a Charles Policy Editor, judged that there was consensus. I agree with that. Charles - Without consulting with the other Policy Editors, Bill Charles reverted the commit. This solo action was done out of the Charles usual process for seeking consensus before changing the Charles Policy. Well, I'd phrase it as Bill, in his role as policy editor felt that Russ had misjudged consensus. My understanding is that the process is silent on this: it neither permits nor forbids this. I actually think you want the process to permit policy editors to disagree with each other in this way. There's some question about how to handle a disagreement when it arises. Immediately reverting is an option that tends to maximize frustration, especially if it is not explicitly called out in the process. 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? Charles I totally share this point of view. (This is why after Charles leading the release of the Policy version 3.9.5.0, seeing Charles that I would not have time to do the same within a year or Charles two, I quitted as a Policy Editor). OK. If there's general agreement on this, it might be a good idea to get this expectation into the process document and reference that from the delegation. Naturally as part of that you'd want to make sure that the policy editors are comfortable with the responsibility the community is asking them to take up. On another axis of the discussion, what's the appeals process? Charles The only appeal I would see would be through the DPL, since Charles he appoints and replaces the Policy Editors, who are DPL Charles delegates. Well, I'll note that's not what you did; you brought the issue to the TC rather than the DPL. I'll also note that our constitution explicitly limits the DPL's actions with regard to a decision of a delegate. I think the DPL is who you'd bring an issue to if you thought an editor was consistently not meeting the responsibility of the post. I think the DPL has no formal power to reverse a specific decision. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tsl7fpw70ou@mit.edu
