This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have an instance of a change made after the last call cutoff that was made without any discussion on public-html and was not made in response to any bug report. This caused people to object, and the chairs (per the Enhanced Change Control policy in effect) asked for it to be reverted, and the editor refused, not once, but twice to do so. The chairs then requested the the WG Staff make the change that the editor was unwilling to do. Again, without participating in the discussion or any bug report, the editor made another change, and this has resulted in a second round of discussions and even bug reports. At this time, the outcome of that is unclear. In any case, we are rushing to resolve an issue that is not related to getting us to last call. The proposed solution is that we require a change proposal, including rationale and a description of the proposed change, after which the chairs will seek amicable resolution. Failing that, alternate change proposals will be sought. At a minimum, this will allow us to more predictably schedule our time.
I propose that, instead of requiring a Change Proposal, we ask that a change to reintroduce a reverted change, or to make a likely-controversial closely related change, should be either: - Based on a Working Group Decision (these can clearly override a revert) - Based on proposing a diff to the WG for discussion first The second is what we have apparently done in this case in the past with some success, so it does not seem like an unreasonable request.
(In reply to comment #1) > I propose that, instead of requiring a Change Proposal, we ask that a change to > reintroduce a reverted change, or to make a likely-controversial closely > related change, should be either: > > - Based on a Working Group Decision (these can clearly override a revert) > - Based on proposing a diff to the WG for discussion first > > The second is what we have apparently done in this case in the past with some > success, so it does not seem like an unreasonable request. Made this change, also adding a bug report when before the relevant cutoff as discussed amongst the Chairs, here: http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.30&r2=1.31&f=h