- 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