Re: Change Proposals and Counter-Proposals (was Re: Issues 89 through 97)

On Mon, Jan 18, 2010 at 6:49 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 18, 2010, at 4:43 PM, Shelley Powers wrote:
>
> This approach is originally Sam's idea, and I am pleased with the way it's
> been working out. I don't think Sam is saying we're going to change things.
> But he *is* saying that the counter-proposal period is not guaranteed, and
> if a Change Proposal is either a clear winner or a clear loser just from
> mailing list discussion, we may not bother formally calling for
> alternatives.
>
>
> That's not a step in the Decision process. The decision process states
> that if the change proposal has general acclaim, it will most likely
> be passed by consensus. If the change proposal has little or no
> support, regardless of how it is written, it probably won't even go to
> the poll.
>
> The Decision Policy also includes a discussion period with no specific
> bound. A few times now,  we've chosen to request that some of that
> discussion be distilled into additional Change Proposals. That's been our
> best judgment of how to bring discussion to a resolution when there is no
> clear consensus winner. That's seemed more prudent to us than just going to
> a poll - we prefer for that to be the last resort. Other than that, I agree
> with what you said. If a Change Proposal is a clear winner or clear loser,
> it can succeed or fail without the need for any further Change Proposals.
>

That's not in the Decision Policy. There is nothing about a call for a
formal counter-proposal during the "discussion".

I'm sorry, but "discussion" is not the same as a formal call for a
Counter-Proposal. If people want zero-edit proposals, if they want the
status quo, they should be willing to defend the specification
following the same. If they can't even take the time to do this, then
yes, the change proposal should be the clear winner.

If people can't take the time to actually provide a rationale, aren't
even willing to try until prodded by the co-chairs, then the contested
spec text should not be in the HTML5 spec.

I am disappointed with how uneven and inconsistent the Decision Policy
is being applied. But evidently, there is little I can do.

Shelley

Received on Tuesday, 19 January 2010 01:19:42 UTC