- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 16 Mar 2010 22:58:01 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8891 Larry Masinter <lmm@acm.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmm@acm.org Status|CLOSED |REOPENED OS/Version|Mac System 9.x |All Platform|Macintosh |All Resolution|WONTFIX | --- Comment #4 from Larry Masinter <lmm@acm.org> 2010-03-16 22:58:00 --- 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". -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 16 March 2010 22:58:02 UTC