Re: Policy Process and Rough Consensus
On Tue, Mar 31, 2015 at 12:40:00AM +0000, Sam Hartman wrote:
> Steve, in one of the TC meetings last year, you made the claim that the
> policy process was not a rough consensus process.
I believe this was:
<vorlon> keithp: our policy process isn't based on "rough
consensus", but on a stricter definition of consensus
http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-12-04-18.00.log.html
> 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).
That's mostly from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545548
isn't it?
Here's some other sources on how objections work:
] I think
] that we should stick to the current method of policy changes which
] allows for anyone to initiate discussions, and a small group of
] developers to bring changes forth; what we need is someone with
] authority to step in and steer discussions that are stalled; and
] decide whether a consensus has been reached.
]
] I still do not think that this person should be able to
] override formal objections from more than one developer
-- Manoj, Mar 2000
https://lists.debian.org/debian-policy/2000/03/msg00135.html
] The old document also sates that the whole process could be
] stopped dead in its tracks by a single formal objection. And then we
] deferred to the TC or took a vote. I think that is a flaw -- if
] there are serious objections from a significant minority of active
] members of the mailing list, sure, we should punt to the TC or a GR,
] but not if there is one lone objection.
-- Manoj, Oct 2006
https://lists.debian.org/debian-vote/2006/10/msg00397.html
] * Bill's other objections haven't met with any other agreement, so the
] consensus is to procede despite them. To use IETF terms, Bill's in the
] "rough" part of rough consensus. (I've been there before myself.)
-- Russ, Aug 2009
https://lists.debian.org/debian-policy/2009/08/msg00172.html
] The special tasks of Policy delegates are: ...
]
] * Rejecting proposals. Anyone can argue against a proposal, but the way
] I'd been thinking of it, only Policy delegates can formally reject it.
]
] * Counting seconds and weighing objections to proposals to determine
] whether the proposal has sufficient support to be included."
-- Russ, Aug 2009
https://lists.debian.org/debian-policy/2009/08/msg00155.html
] 3. Whenever there is any disagreement over a change, the process here
] effectively grinds to a halt. We don't seem to have a workable process
] for achieving rough consensus with some disagremeent, or making
] decisions when there's disagreement. We might be able to get around
] this by more aggressively appealing to the tech-ctte. Obvious
] examples: #587279, #248809.
-- Russ, Jul 2012
https://lists.debian.org/debian-policy/2012/07/msg00073.html
That seems to me to add up more to "policy is based on rough consensus,
but at times fails to live up to that, and instead requires a stricter
definition of consensus" than what Steve said.
> 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.
https://bugs.debian.org/555979 is arguably an example both ways:
a single objection arguably stalled the bug for a couple of months,
however a single objection was not enough to block the change. (IMO,
the objection wasn't even addressed, but eh). That said, it was a trivial
one line patch where the patch took five years to be written...
I guess my understanding is the policy process is supposed to be:
(a) proposer:
- proposes a change
- gets three or more seconds
- addresses any objections raised
followed by one of:
(b) policy editor:
- evaluates objections and responses, determines consensus exists
- commits the change to policy
(c) proposer: withdraws change
(d) tech ctte: reviews difficult proposals where consensus isn't able
to be obtained
But there are four significant failure modes where that doesn't work
in practice:
1) proposer doesn't propose a concrete change or there's no comments
(and hence no seconds)
2) objections just sit around rather than getting addressed/resolved
3) policy editor doesn't make policy changes in the event of even minor
disagreements
4) tech ctte doesn't take on the difficult issues
?
Cheers,
aj
Reply to: