Re: Enhanced change control after the Last Call cutoff.

I just want to voice my concern about having an agreed and thoroughly
discussed and at least partially implemented solution for media
accessibility by the timeline that is being proposed. I believe media
accessibility is an important feature that needs to be part of this version
of HTML since this version has introduced media elements. At minimum we
should deal with captions, subtitles and audio descriptions.

What is being envisaged by the chairs for this particularly difficult case
to deal with the deadlines and process to get to Last Call and would it be
allowed to bring in specification text even after LC and even if it still
needs discussion in this group to be finalized?

Regards,
Silvia.


On Sat, Sep 11, 2010 at 7:17 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
>
> 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)
>
>