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

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.

Thus, a really bad change proposal obligates me to write a counter
proposal just to reduce the chances of it being accepted by default.

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.

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.

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

~TJ

Received on Monday, 18 January 2010 23:12:10 UTC