In March of 2014, Charles Plessy asked the Debian Technical Committee to review one of the policy editors decisions to revert changes to how policy talks about the Debian Menu and MIME support. See http://bugs.debian.org/741573 for the TC process and https://bugs.debian.org/707851. for the process within debian-policy.
One of the issues is the question of whether the Debian Policy community reached consensus around the proposal. I've investigated this question as part of trying to understand how I will vote within the TC process. I had hoped to get the TC as a whole interested in the question of whether consensus had been reached, but while several TC members have joined that discussion, it seems that the TC as a whole will not address that question. However, I've tried to investigate the process. I draw your attention to https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=497;bug=741573 . In that message I outlined my plan for how I'd review whether consensus was reached as a TC member. It's probably worth taking a look at that message even if you don't care about the issue. I propose that a reasonable way for the TC or anyone else for that matter to evaluate consensus is to: * Confirm from the bug log that a proposal gained enough seconds * Confirm that the people seconding believe (as required by the process.txt document) both that the proposal is sound/complete and that it has reached consensus. * Make an explicit call for unresolved technical objections and if any objections areraised, consider them. [1] [1] Note that consider is complex. RFC 7282 gives thoughts that some folks have had on some of these issues in cases where you have agreement that the work should be done and are trying to come to rough consensus on how to do it. Issues like whether the issue has been considered before, whether it was understood when considered, etc all are important. Evaluating rough consensus once you get to a point where you have objections is kind of an art form. If my approach does not seem reasonable then I'd recommend revising process.txt to give better guidance to folks reviewing your work. I tried to implement my approach. It is my belief that rough consensus was achieved. Those who seconded the proposal more-than-less reviewed the discussion for rough consensus. I also looked at significant chunks of the discussion including the list of objections that Bill raised. It's my belief that the objections Bill raised were discussed by the broader community and his points were considered. It's my belief that the other objections he pointed to (other than his own) in his mail indicating he'd reverted the change were explicitly addressed. In at least one case I got confirmation of that from the person raising the objection. That said, I'd like to draw your attention to two of the mails I got asking people to review seconds and to the process text surrounding seconds. These responses are on the edge with regard to whether the person seconding actually met the process requirement of evaluating rough consensus. If someone wanted to argue that no consensus was reached, these two seconds would be one way to make such an argument. What needs to happen next: The proposal needs to be reviewed and seconded. Any Debian developer who agrees with the change and the conclusion of rough consensus from the discussion should say so in the bug log by seconding the proposal. [TAG: patch]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch State E: Seconded ------------------ The proposal is signed off on by N Debian Developers. To start with, we're going with N=3, meaning that if three Debian Developers agree, not just with the proposal but with the conclusion that it reflects consensus and addresses the original issue -- it is considered eligible for inclusion in the next version of Policy. Since Policy is partly a technical project governance method, one must be a Debian Developer to formally second, although review and discussion is welcome from anyone. Once this tag has been applied, the bug is waiting for a Policy team member to apply the patch to the package Now, I ask you to consider Lisandro Damián Nicanor Pérez Meyer 's response to my question about his second: Sam> What I'm hearing is that during the time you made the second you were Sam> paying attention to the discussion and didn't believe there were any Sam> counter-seconds--people jumping up and down saying their issues had not Sam> been addressed? Sam> If I've got that right, I think that's all we need at this point. No, you are hearing a different thing ;) What I'm saying is that the procedure at one point requires people to write a mail specifying that they are seconding the proposal. And I was one of them. To the best of my knowledge no one counter-seconded the proposal in this way. So again, the process was followed. Another thing is discussing the matter. Yes, I ack that there where some people who didn't like the idea, much in the same way that there are people who like the idea. No one of the two system is the panacea, so of course there would be always some kind of disagreement. But my position in that regard is that we had a rough consensus. Hope that clarifies my previous mail :) And from Russ Allbery: > You are copied on this message because you raised objections noted by > the policy editors during the discussion of menu policy or seconded the > proposal in #707851. The TC is currently evaluating a request to review > that proposal and the process surrounding it. > If you seconded the proposal, I'd like to confirm that as part of your > second, you believed that there was rough consensus and that objections > that were raised had been addressed. That is, please confirm that you > evaluated not just the quality of the proposal, but also evaluated the > discussion. Hi Sam, I did try to evaluate both the quality of the proposal and outcome of the discussion, and thought that the people who had raised objections were in the rough. I may not have done a very good job of that, though. (Also, I felt like the proposal was a good path forward, which doesn't make me a particularly unbiased judge of consensus.) Sam hartman Speaking only for myself
pgpLbxrzOfS0O.pgp
Description: PGP signature
