Steve, in one of the TC meetings last year, you made the claim that the
policy process was not a rough consensus process.
I recently read process.txt.gz from the debian-policy package. That
document (admittedly dated after #741573 was submitted) claims the
opposite.
I don't know what the document said previously (although I realize I
could git clone if I cared).
Under that process, I'd assume the following:
* three seconds without an articulated unresolved technical objection is
strong evidence that a proposal has received rough consensus.
* When a proposal has received three seconds, someone claiming that
there is not rough consensus must clearly articulate what they believe
is an unresolved technical objection.
I'd tend to use RFC 7282's definition of unresolved technical objection
because it's the most coherent definition I've read and because we don't
have one of our own.
Obviously if the TC gets involved we'd also need to evaluate a proposal
for any significant technical flaws we discover in part of our process.
I'd appreciate any thoughts you have on the above approach in addressing
claims similar to #741573 that we might receive in the future. With
regard to #741573, my preference is to let Keith make his proposal. If
Charles pushes for us to evaluate process or Keith runs into trouble
building consensus, I'm likely to want to understand the specific
technical objections to the policy change that Bill reverted, but I
don't think that's necessary now.
--Sam
--
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/0000014c6d454d0a-d9e13f1f-122f-4bc6-8ce4-a649c96302dd-000...@email.amazonses.com
