- From: <bugzilla@jessica.w3.org>
- Date: Fri, 21 May 2010 17:24:13 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9792 Summary: Clarify that no-change counter-proposals need to document rationale for the existing text Product: HTML WG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: working group Decision Policy AssignedTo: dave.null@w3.org ReportedBy: rubys@intertwingly.net QAContact: public-html-bugzilla@w3.org CC: mjs@apple.com, Paul.Cotton@microsoft.com, rubys@intertwingly.net, mike@w3.org We have a process which liberally allows text to be inserted by the editor without published rationale, and for such text to make it to published working drafts and potentially beyond as long as it goes unchallenged. Challenges initially take the form of a bug, and should the originator not be satisfied by the editor's resolution, may be escalated as an issue. At which point, the decision process requires those that wish a change to write up Change Proposal with Rationale and Details for what they would like to see. If this doesn't meet with immediate consensus, others are invited to write up what they would like to see in the spec, and include similar levels of detail. A common problem that we are seeing is that all too often, these "counter proposals" focus not on what they would like to see, but on pointing out perceived deficiencies in proposals others have made. While inclusion of this other material is fine in a change proposal, the decision process should be clarified to indicate that what we are looking for is rationale on what should be in the document in cases where there is disagreement. Note: the root cause for this is likely the names we have given to the proposals themselves. Neither "Change Proposal" nor "Counter-Change Proposal" provide the proper guidance. New names may be appropriate, but in any case the right fix is to clarify the process. -- 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 Friday, 21 May 2010 17:24:14 UTC