Enhanced change control after the Last Call cutoff.

The Chairs have delared a cutoff on bugs to be considered LC blockers (with case-by-case exemptions if needed) because otherwise we essentially need to get to 0 bugs + 0 issues + 0 bugs closed recently enough that someone may be filing an issue shortly, and it does not seem practical to reach that state in a reasonable amount of time. We don't want to call a total stop to useful changes that aren't in response to those bugs, but that might create a situation where a person or group strongly objects to some change after the cutoff, but they don't have automatic recourse through the normal bug process.

Therefore, in exceptional cases, we would ask for a change to be reverted from the LC-track draft pending resolution of the issue through the Working Group. If any Working Group member sees a change go into any Last Call-track draft after the October 1st cutoff that seems controversial and likely to reduce rather than increase consensus, please let the Chairs know and we will make the call.

= What kind of changes might this apply to?  =

* We do not expect it to be used casually over random changes, since anyone asking for this would have to convince the chairs. 

* We think there is little chance of it being used to revert a fix for a UA behavior bug, because (a) that is not the sort of thing people complain about; and (b) divergence there would be a very serious problem, so everyone would be highly incentivized to seek other solutions. So if someone finds a late-breaking bug in the parsing algorithm, that's not the kind of change that would be problematic.

* Based on past experience, it seems likely that changes to accessibility topics already covered by issues are likely to be controversial. Editors may want to tread carefully in that area until the issues are resolved if the editor actively avoids that minefield.

* It is also reasonably likely that this processed could be used to object to new features. The Chairs recommend in general that new features should not be added after the cutoff, except in particularly exceptional circumstances.

* Most likely, this process will be used for the types of changes that in the past have lead to such wide concern that they led to reverts anyway, as with WebSRT. So in a sense we are just formalizing something that has happened in the past for clarity of all in the Working Group.

* We can't promise that no revert would lead to a fork of specific paragraphs or sentences; but it is *highly* likely that most calls for a revert could be dealt with so that there is simply omitted text or additional text in the W3C draft.

= What happens after a revert? = 

* If a spec change that gets reverted was based on a bug, the bug effectively goes WONTFIX, but I suppose it would have to be owned by and given a rationale by the Chairs, since it wouldn't be the editors choice to revert. This bug could be escalated through the normal channels, however, there would be somewhat less status quo bias in favor of the editor's initial disposition.

* A speedy revert would not be a permanent WG decision, not even for Last Call; it would simply a temporary mesure to maintain the perception of fairness for all Working Group members and to avoid the feeling that there is no recourse for certain changes.


We expect all editors who want to go to Last Call on the published schedule to agree to abide by this policy. Ian Hickson has already indicated his agreement for the three drafts he edits.

Regards,
Maciej
(on behalf of the Chairs)

Received on Friday, 10 September 2010 21:17:58 UTC