W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Splitting HTML from the HTML DOM (was Re: Renamed topic: focus and length of HTML5)

From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, 7 Dec 2009 14:39:05 -0600
Message-ID: <643cc0270912071239l349938a2j55234a4e104f20df@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Maciej Stachowiak <mjs@apple.com>, Geoffrey Sneddon <gsneddon@opera.com>, Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, public-html <public-html@w3.org>
On Mon, Dec 7, 2009 at 2:08 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> Shelley Powers wrote:
>> I think another area of clarification is that if someone does a
>> counter-proposal, the person who submitted the proposal shouldn't have
>> to "address" the issues in the counter-proposal.
>> We could end up in a never ending spiral if we follow this
>> proposal/counter-proposal/counter-counter--- well, you get the drift.
>> We need to find one set of rules, and if we change them, we need to
>> grandfather older proposals in. For fairness if no other reason.
>> People putting out suggestions, and carefully written proposals
>> shouldn't have to jump through an ever changing set of hoops. We're
>> all here to try and help, not cause problems.
> I'm concerned about the opposite problem: a perception that "you get one
> shot at it, at which point somebody can make a counter proposal after having
> seen every argument you have made, and you get no shot at rebutting".
> Put another way, and applied to the situation at hand: if Manu and/or others
> don't wish to update the current change proposal, simply say so, and we will
> go with what we have got now.  No hoops, completely fair, but no opportunity
> to address the points that have been brought up in response to the proposal.
> Personally, I think Maciej provided a lot of value by identifying points
> that might merit revisiting.  And, to be fair, he did so on both the
> original proposal and counter-proposal.
>> Shelley
> - Sam Ruby

The biggest problem is the concept of counter-proposal.

Change proposals came out of the Issue tracker, and had life in the
beginning as a bug at some point.

A change proposal is a person saying, OK, this is the change I want.
It starts life as a bug request. The editor doesn't like it, won't
make the change, so it has been upped to an issue. The Change Proposal
 was a requirement from us specifying what action we want taken to
satisfy the issue, the rationale for it, and the detailed changes.

Where this counter-proposal came from, I have no idea. It is not part
of the formal Change Control procedure, or at least I can't find it.

In the procedure, there is discussion for each Change Proposal, and
the person can modify it for a reasonable period of time, hopefully to
get consensus. But there is nothing about formal counter-proposals. In
fact, these are NOT part of the initial change control process we all
agreed on.

Sorry, but it seems to me that those who want change are having to go
through a lot more hoops than those who the status quo.

Received on Monday, 7 December 2009 20:39:42 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC