This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Recently the co-chairs made a decision regarding two change proposals for issues 90 and 91: removing the figure and aside elements[1]. The decisions given were based solely on the objections given in the survey and did not address objections or concerns raised in the change proposal (or counter proposal for that matter). Yet the chairs specifically stated not to re-state the objections given in the proposals, which means that arguments given in both documents were not addressed in the decisions. I would recommend two changes to the decision process: 1. When the change or counter proposal is submitted that the chairs not only confirm that it meets the proposal process format (and in the case of recent counter-proposals, help the person to strengthen their case), the co-chairs briefly list what they perceive to be the objections in the proposals--whether it is an objection against not making a change, or an objection against making the change. Then allow the editors to modify their documents (over a brief period of time), if they felt their objections were not being perceived. 2. Address these objections in any decision. To ignore the proposals is to reduce the decision process down to nothing more than a poll. Considering that only a handful of people now respond to anything in the HTML WG (though the membership stays at 400+), relying purely on a poll is not in the interests of ensuring the needs of the web community are being met. This change might help prevent Formal Objections. At a minimum, if the person does formally object, they have a basis for the objection. The co-chairs not addressing all of the concerns is little different than the HTML5 editor not providing a sufficient rationale when he marks a change WONTFIX.
In the case of <figure> and <aside>, the decisions documents said, "The counter proposal provides rationale for the feature." Elaborating on how that rationale trumps the points Shelley raised in her Change Proposal would have been beneficial. For instance fundamental questions presented like: * Reason for existence of the feature/why a special purpose element is judged to be required.[*] * Is the feature judged by the chairs to be semantically meaningful or not? * Is it structurally useful or not? * Are the costs to HTML editors, Content Management Systems, and other tools justified? * etc. The decisions documents did a good job of detailing rationale for most of the survey comments. However, it may have helped people understand the decision and facilitated acceptance if specific rationale points which were raised in the change proposals/counter proposals themselves had been addressed. [*] An inherent Catch 22 kind of paradox exists in the current Commit Then Review (CTR) decision policy. This present an inequitable balance in shifting burden of proof in favor of "concrete features with normative text" [1] [2] ... A feature existing, meaning that it should exist. [1] http://lists.w3.org/Archives/Public/public-html/2010Jun/0002.html [2] http://lists.w3.org/Archives/Public/public-html/2010Jun/0003.html
(In reply to comment #1) > In the case of <figure> and <aside>, the decisions documents said, "The counter > proposal provides rationale for the feature." Elaborating on how that > rationale trumps the points Shelley raised in her Change Proposal would have > been beneficial. For instance fundamental questions presented like: > > * Reason for existence of the feature/why a special purpose element is judged > to be required.[*] > * Is the feature judged by the chairs to be semantically meaningful or not? > * Is it structurally useful or not? > * Are the costs to HTML editors, Content Management Systems, and other tools > justified? > * etc. > > The decisions documents did a good job of detailing rationale for most of the > survey comments. However, it may have helped people understand the decision and > facilitated acceptance if specific rationale points which were raised in the > change proposals/counter proposals themselves had been addressed. The <details> decision [1] announce June 30, 2010 [2] did a fine job addressing change proposal rationale as well as survey comments. Big improvement. Thank you very much. [1] http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html [2] http://lists.w3.org/Archives/Public/public-html/2010Jun/0659.html
Addressed here: http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.10&r2=1.11&f=h