The chairs will discuss this proposed change.

My own tentative opinion is that we should make the policy document reflect what we have been already doing, as suggested in bug 8894, rather than to change what we've been doing.

This would mean that a call for additional proposals would remain an optional step, and would depend on whether we can achieve clear consensus without getting that far. If a change proposal does not draw any opposition, then we'd just call for consensus on the change proposal. If a mutually agreeable compromise change is made to the spec, then we'd call for consensus to close by amicable resolution. If the discussion shows continuing disagreement, then we'd ask anyone who continues to disagree to write it up formally, and give them a time limit.

The reason to have time limits at all is not to pre-empt anyone from speaking their piece, but rather to keep issues from being dragged out indefinitely. The chairs have been very generous (within limits) about granting extensions.

However, another consideration for the process is to prevent denial-of-service on the group. We don't want to create the possibility that someone may raise a lot of issues and not follow up. And I don't mean to imply malicious intent - often people find that they care less than they thought, or have less time than expected. Since we adopted the Decision Policy we have had Change Proposals submitted for 14 issues, while 8 have timed out in one way or another. And I believe all our issues were intended sincerely at the time they were raised.

Anyway, that's my tentative thinking. Not a final statement, and not necessarily representative of consensus of the chairs.

(In reply to comment #1)
> The chairs will discuss this proposed change.
> 
> My own tentative opinion is that we should make the policy document reflect
> what we have been already doing, as suggested in bug 8894, rather than to
> change what we've been doing.
> 
> This would mean that a call for additional proposals would remain an optional
> step, and would depend on whether we can achieve clear consensus without
> getting that far. If a change proposal does not draw any opposition, then we'd
> just call for consensus on the change proposal. If a mutually agreeable
> compromise change is made to the spec, then we'd call for consensus to close by
> amicable resolution. If the discussion shows continuing disagreement, then we'd
> ask anyone who continues to disagree to write it up formally, and give them a
> time limit.
> 
> The reason to have time limits at all is not to pre-empt anyone from speaking
> their piece, but rather to keep issues from being dragged out indefinitely. The
> chairs have been very generous (within limits) about granting extensions.
> 
> However, another consideration for the process is to prevent denial-of-service
> on the group. We don't want to create the possibility that someone may raise a
> lot of issues and not follow up. And I don't mean to imply malicious intent -
> often people find that they care less than they thought, or have less time than
> expected. Since we adopted the Decision Policy we have had Change Proposals
> submitted for 14 issues, while 8 have timed out in one way or another. And I
> believe all our issues were intended sincerely at the time they were raised.
> 
> Anyway, that's my tentative thinking. Not a final statement, and not
> necessarily representative of consensus of the chairs.
> 

I disagree.

First, many of the issues you mention, in fact all of them if I remember correctly, were ones created before the new procedure was in place. 

I'm also not saying that people have to defend against a change proposal, until someone actually volunteers to do one. But once a person volunteers to do a change proposal, and the clock starts, it needs to start for _everyone_. 

In the HTML WG email list, the reason people have stated that they don't want to do the zero-edit or counter proposals ahead of time, is because they to see if it's worth their effort [1]. They seem to consider that their time so much more valuable [2]. That this behavior is condoned by the co-chairs leaves me breathless with astonishment.

The editor can quickly, even sloppily add items to the proposal, just by editing the document. It is to the advantage of everyone that the components under debate are given a well considered defense, because such defenses have proven, over time, to actually help improve the item, at a minimum; perhaps even come up with a better replacement, or result in its removal. 

Look at the discussion about the hidden attribute, and the confusion related to it. These change proposals, and the defenses against them, actually result in a better document--at a minimum, they help clarify misunderstandings. Additionally, the defense does go on record, for those times in the future when someone else will inevitably question why the component is worded the way it is, behaves the way it does, or even exists. 

The only denial of service I have seen practiced in this group is when I've had several bugs wait 2+ months, just for the editor to flip a button and copy and paste a reason why he won't fix the item. Everyone else who is participating is doing so rigorously, and with genuine intent. Look at how much work the accessibility folks have had to do, just for the summary attribute? The amount of work is absurd, and this group should be embarrassed at supporting one person, who has no background in the accessibility, over so many who do.

You insult the team members who are advocating change, or clarification, when there is no evidence, NONE, that any of us are participating in the childish behavior you seem to be attributing to us. If this behavior arises, then you can institute action -- but I would suggest that you wait until you actually have evidence of such. 
 
If the folks aren't willing to get off their lazy you-know-whats, and put together some words in defense of something they supposedly they can't live without, then whatever they have to say probably won't be worth hearing anyway. 

So no, I will not support this, I will vigorously protest it, and if it continues, against the policy you all wrote, and we all agreed to, I will formally object. If people really support something, they can write a note in defense of it. They shouldn't have to wait to see what I, or other people say. They should know NOW why the want the status quo. If they do want to directly respond to the person, there is a period of time after the proposals are submitted, when everyone can update their change proposals to reflect what the other people have written, and the discussion around the same. 

If the purpose of all of this is to come to amicable resolution as much as possible, then this process should be effective. At a minimum, you should be testing whether your current recorded and agreed on procedure does work, as it is written, by asking for counter-proposals NOW for all of the items I'm writing a change proposal for. I can guarantee, absolutely guarantee, it won't be a waste of anyone's time.
 

[1] http://lists.w3.org/Archives/Public/public-html/2010Jan/0897.html
[2] http://lists.w3.org/Archives/Public/public-html/2010Jan/0880.html

I find using a bug database, as a means of managing disparity within a group to be novel, though unlikely to be effective. Regardless, I also know that I don't have time to deal with procedural issues, when I'm also involved in so many issues related to the actual HTML5 specification. In particular since I don't expect a positive respond from anything I might say.

I withdraw my request.

I think the working group Decision Policy has the responsibility of being coherent and understandable by anyone who views it, and some uses of terminology are extremely confusing.

The original concept, that one must submit a "Change Proposal" to change HTML5 to be more compatible with HTML4 (i.e., to undo a change that was made from HTML4 without sufficient justification) is itself suspect. But to then couple that with the notion that there might also be a "change proposal" that advocates "no change" to an editor's specification double confounds the situation. What things are called matters, where process transparency is a requirement.

The situation is even more murky because the editor of a specification is free, at any time, to reorganize the document or introduce new or different text which then becomes the status quo, so that a "no change" proposal becomes ambiguous: is the author of a "no change" proposal supporting the document as it was at the time the "no change" proposal was written, or is it an endorsement of the editor's judgment?

I think what Shelly was originally asking for was that the process for evolving the draft from its current status be fair and equitable.

"We don't want to create the possibility that someone may raise a lot of issues and not follow up."

I agree this would be bad, but I would propose that more working group polling would help individuals gauge which issues are worth pursuing. The W3C process requires responses to comments to come from "the working group". The change proposal process is unnecessarily formal and confrontational, and "zero change" change proposals seem to increase the noise rather than help it.

I'd urge the chairs to consider alternatives that don't involve "no change" change proposals. 

For example (just one example): change proposals get added to a wiki; the wiki allows "arguments for" and "arguments against".  Those who like a proposal can add to "arguments for", and those who don't like it can add to "arguments against". If there are several alternative changes, arguments can be linked rather than copied. That way, there is one place to collect the arguments.

Of course, there are many other ways of reducing the confusion that currently exists and I think is built into the idea of a "no change" change proposal, especially where "no change" is really "accept change from HTML4".

Shelley's original suggestion was to have a single deadline for both change proposals and counter-proposals or possible alternatives. It sounds like your proposal is that change proposals that suggest no change to the spec should not be required or allowed. Could you please file a separate bug for your new suggestion instead of reopening this previously closed bug? Although it relates to the title of the bug, it seems to be a substantively different request which aims to solve a different problem.

Strawman resolution: we will continue to treat zero-change proposals the same as any other Change Proposal or Counter-Proposal and we expect to document this.

Addressed here (as described above, by describing the process and the specific requirements for zero-edit proposals):

http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.9&r2=1.10&f=h