(In reply to comment #0)
> The decision process currently leads to decisions that make the spec
> inconsistent. For example, the recent decision to remove a paragraph of
> implementation advice in one section left another paragraph with essentially
> the same advice untouched, and left dozens of other paragraphs with similar
> advice alone.
> 
> The process should be changed to require that the chairs ensure that working
> group decisions are based on general guidelines that can be consistently
> applied to the whole specification (or group of specifications, where
> appropriate).
> 
> For example, in the case above, the working group decision could have been "the
> html specification should not include optional implementation advice", or "the
> html specification should not attempt to improve accessibility" or "the html
> specification should not acknowledge the possibility of authors making
> authoring mistakes", each of which would result in the paragraph being removed
> but would _also_ result in the spec being consistently updated so that it
> remained coherent.
> 
> This change should be retroactive (i.e. should require previous decisions to be
> explained in terms of general principles). Without such guidance, I'm unable to
> effectively execute my duties as editor.

The co-chairs recently decided against a couple of my change proposals. I do not feel it was the co-chairs job to include in these decisions a complete evaluation of the entire 900+ page HTML5 document. To do so would mean that any decision--even one as small as removing a simple and unnecessary paragraph--would require weeks, even months of their time. 

For instance, one of my change proposals was to remove figure. The chairs decided to keep the element based on objections in the survey. Should the co-chairs then have justified their decision in terms relative to why every element in the HTML5 spec also remains? 

Considering that no justification or rationale was given for when the element was first added, it seems to me you're asking for something you're not willing to give yourself. 

If you want to prevent a change you might start by providing better rationales when you respond in bugs. You might also want to write change proposals justifying your text and decisions when they're questioned or when working group members ask for a change.

One other thing, your statement:

'For example, in the case above, the working group decision could have been "the
html specification should not include optional implementation advice", or "the
html specification should not attempt to improve accessibility" or "the html
specification should not acknowledge the possibility of authors making
authoring mistakes", each of which would result in the paragraph being removed
but would _also_ result in the spec being consistently updated so that it
remained coherent.'

Such broad outlines based on a simple decision to move one unnecessary and confusing paragraphs is ludicrous. In addition, you have demonstrated an inability to refrain from making damaging wholesale changes, as reaction to something you disagree with. 

If you can't understand how to edit the document based on group discussions than yes, you probably do need to resign. Or the group needs to add additional editors who are not encumbered by having these overly broad decision policies attached to even minor decisions.

Writing a spec before coming to consensus on the design principles is backward. But we are at where we are at.

(In reply to comment #0)
> The process should be changed to require that the chairs ensure that working
> group decisions are based on general guidelines that can be consistently
> applied to the whole specification

Consistency is a worthy goal. A set of *real* design principles might fulfill this request and aid decision making. No principles or disputed principles can very well lead to inconsistent, contradictory, and discriminating decision making. Principles can be fundamental value guides used to base decisions.

Ian, do you have a set of design principles that you currently use for editing that you could offer as an example? 

Part of the problem may be that neither the decisions that Ian has made nor the decisions that the Chairs have made are based on any agreed to principles [1].  

The current design principles that we have to date do not have consensus and are not anything that can be applied consistently to make decisions. They are wishy-washy and non-committal. They are consistently crafted to allow inconsistency. [2]

In order to apply consistent decision making throughout the specification, perhaps a new attempt should be made at the design principles. Tantek [3] [4] seemed to be interested in pushing for:

a) known explicit technical design principles for the spec
b) consistent application of those principles

[1] http://lists.w3.org/Archives/Public/public-html/2010Jun/0290.html
[2] http://lists.w3.org/Archives/Public/public-html/2010Jun/0298.html
[3] http://lists.w3.org/Archives/Public/public-html/2010Jun/0288.html
[4] http://lists.w3.org/Archives/Public/public-html/2010Jun/0295.html

The chairs discussed this issue. We believe that it is not the role of the chairs to enforce consistency as the highest value. Rather, it is our role to evaluate arguments made by members of the Working Group to determine which proposal draws the weakest objections. Thus, if particular Working Group members feel that consistency is important and believe that a given proposal would violate it, they should cite the consistency problem and explain their reasoning, either in another Change Proposal or in a straw poll objection.

I disagree fundamentally with this approach and would like to escalate this.

I concur with the Chairs on this item: if an individual, especially an editor, believes that a change proposal would create inconsistencies within a document (or between documents), it should be clearly indicated as part of one of the change proposal or the straw poll. The chairs cannot be expected to ensure proper consistency across the existing 8 documents produced by the HTML Working Group.

(In reply to comment #6)
> I concur with the Chairs on this item: if an individual, especially an editor,
> believes that a change proposal would create inconsistencies within a document
> (or between documents), it should be clearly indicated as part of one of the
> change proposal or the straw poll. The chairs cannot be expected to ensure
> proper consistency across the existing 8 documents produced by the HTML Working
> Group.

Thanks, PLH!

The remaining question I see: is there anything we need to make the ample opportunities that we provide to working group members (including, but not limited to the editor) to express objections (for any reason, not just consistency) or alternative proposals clearer?

Removing TrackerRequest since we're not using the issue tracker for the decision policy. However, feel free to raise this concern again on the mailing list when the updated policy is posted for discussion.