This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9792 - Clarify that no-change counter-proposals need to document rationale for the existing text
Summary: Clarify that no-change counter-proposals need to document rationale for the e...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: working group Decision Policy (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-21 17:24 UTC by Sam Ruby
Modified: 2010-07-28 01:14 UTC (History)
4 users (show)

See Also:


Attachments

Description Sam Ruby 2010-05-21 17:24:12 UTC
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.
Comment 1 Maciej Stachowiak 2010-07-28 01:14:32 UTC
Addressed here (as suggested above, by describing the process and the specific rationale requirements for zero-edit proposals):

http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.9&r2=1.10&f=h