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

On Mon, Jan 18, 2010 at 6:06 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 18, 2010, at 3:42 PM, Tab Atkins Jr. wrote:
>
>> On Mon, Jan 18, 2010 at 5:27 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>>> Tab Atkins Jr. wrote:
>>>> I disagree.  It is implied that there is a material difference between
>>>> a single change proposal being written, and a change proposal plus a
>>>> zero-edits counter proposal; the former is implied to be more likely
>>>> to be accepted, despite the fact that the zero-edits counter proposal
>>>> is typically nothing more than a collection/distillation of arguments
>>>> that have already occurred on the mailing list.
>>>
>>> If it truly is that easy, what is the issue?
>>
>> I never said it was easy.  It typically involves a non-trivial amount of work.
>>
>>>> Thus, a really bad change proposal obligates me to write a counter
>>>> proposal just to reduce the chances of it being accepted by default.
>>>
>>> That would only happen if both the chairs were asleep at the wheel *AND*
>>> absolutely nobody in the working group were to comment on the Call for
>>> Consensus.  In other words: ain't going to happen.
>>
>> So then there's no reason to write a zero-edits counter proposal,
>> since we can just object when the Call for Consensus is made?  It's
>> been implied by Maciej that it's somehow better to write a zero-edits
>> counter proposal.
>
> You could choose to do that, but the Chairs would expect any such objection to come with full rationale. Would you rather write a rationale that's going to be judged on the one-week timeline of a Call for Consensus or the typical one-month timeline of Call for Counter-Proposals? Would you rather have your side of a dispute judged by multiple fragmented comments instead of an integrated whole, when the other side has laid out its position in a single coherent document?

That's what I thought.  You *are*, then, saying that a change proposal
by itself is more likely to be passed than a change proposal plus a
zero-edits counter proposal.  Sam seems to be implying otherwise.
Thus I am obligated to write a counter proposal to change proposals
that I feel are really bad, but I don't know if they're bad (and thus
worth the effort of writing a counter proposal) until they've been
written.  Thus the current method of saying "all right, change
proposal is in, here's the deadline for counter proposals" is a good
idea.  ^_^

>>>> Before the change proposal is written, however, I have no idea of its
>>>> quality.  Before it is written there is also the distinct possibility
>>>> that *no* change proposal will emerge at all, and the issue will be
>>>> closed without prejudice.  It doesn't make sense for me to expend
>>>> effort distilling the mailing list arguments in either of these
>>>> circumstances.
>>>
>>> This is only an issue if there are features in the document for which
>>> determining the rationale is not obvious.
>>
>> I can't tell if it's obvious or not, however, since it's you chairs
>> that make the decision.  I have no idea what you consider obvious.
>
> My own view is that everyone should have a fair chance to make their case before we resort to entering any decisions by default. While we are not granting infinite time limits, we have tried pretty hard to give anyone who wants to make a case, pro or con, the full opportunity to do so.

I agree that you have, and agree that your current methods are roughly
workable.  I'm specifically countering Shelley's assertions that your
current method is bad, and Sam's apparent implication that it's
reasonable to expect someone to write a detailed summary of the
justifications for the current spec text (that is, a zero-edits
proposal) before a change proposal has been written.

~TJ

Received on Tuesday, 19 January 2010 00:16:15 UTC