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
Attachment:
pgpOYmSNBN_x7.pgp
Description: PGP signature