[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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:

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

] 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

] * 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

] 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

] 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

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
 4) tech ctte doesn't take on the difficult issues 



Reply to: