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

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.

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

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

Typically rationale *is* provided via mailing list discussion.  You
just discounted mailing-list discussion as a valid place to point for
rationale, however.

I am *not* willing to expend the effort to separately defend every
single portion of HTML, and I don't think it's reasonable to expect
anyone to, or even for the group as a whole to do so.  That's the
definition of DoS.

>> I still hate the current Process, but it sucks less than some
>> alternatives.
>
> It is not clear to me what you disagree with here.

Sorry, that wasn't germane to the discussion at hand.

~TJ

Received on Monday, 18 January 2010 23:43:25 UTC