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

Tab Atkins Jr. wrote:
> On Mon, Jan 18, 2010 at 4:24 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On the other hand, the chairs may grant (note: to all parties) an extension
>> if it is felt that people are working on a proposal and were unable to get
>> it done in the time alloted.  From my perspective, "I couldn't be bothered
>> to write up a rationale for what is in the spec until I saw the alternative
>> being proposed" is generally not sufficient cause for granting an extension.
> 
> 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?

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

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

> The entire point of the Process is to reduce the power of a single
> person to DoS the group, by requiring a non-trivial amount of effort
> from people who raise issues before the working group has to respond
> in kind.  Changing this so that the working group has to spend effort
> automatically when an issue is raised completely kills the reasoning
> behind the process in the first place, and will make the group as a
> whole *very* vulnerable to DoSing.

That is *a* point, not *the entire point*.

There is a point to requiring rationale in the first place for every 
change made to the document, retroactively if necessary.

There is also a point to requiring those that would like something 
different to actually document what they would like.

I definitely subscribe to the latter (see [1]), but that doesn't mean 
that I don't think that the former is important too.  In particular, 
saying that a DoS attack is a theoretical possibility is not an excuse 
for features to be present in HTML5 without literally *ANYBODY* in the 
group willing to provide the rationale for that feature.

> I still hate the current Process, but it sucks less than some alternatives.

It is not clear to me what you disagree with here.

> ~TJ

- Sam Ruby

[1] 
http://bitworking.org/news/Camera_Ready_Copy_and_the_Social_Denial_of_Service_Attack

Received on Monday, 18 January 2010 23:28:08 UTC