Fwd: Timeline to Last Call

Hi all,

as the HTML spec is moving to last call, we should probably get more active
in having the media fragment URI uses integrated into it. I have forwarded
the timeline that they are proposing to follow.

The key right now is that we should probably register a bug in the bug
tracker for any spec text that we want to see entered for media fragment
support. The deadline is 1st October.

I am concretely thinking about:
* support for temporal media fragment URIs in the @src attributes of media
elements and what effect they have.
* the use of spatial media fragment URIs in the @src attribute of img
elements.

What do ppl think? Maybe at OVC/FOMS the groups of us that is there can have
a chat about it?

Cheers,
Silvia.


---------- Forwarded message ----------
From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, Sep 8, 2010 at 4:25 PM
Subject: Timeline to Last Call
To: HTML WG <public-html@w3.org>


Dear HTML WG,

The Chairs have been discussing with the team the need for a timeline to get
to Last Call. The W3C Team has strongly urged us to create a timeline to
drive an initial Last Call candidate, and we agree that this is essential to
progress HTML5.

The key aspect of this timeline is that there will be a cutoff date for bugs
to be considered before Last Call; any bugs after that date will instead be
treated as Last Call feedback. That date is October 1. Any bug in the system
by that date (even if reopened, resolved, or escalated) will be resolved
before Last Call, and we will fully process any that are escalated to
issues.

Each date in this timeline is a deadline with a consequence. If the date is
missed, the consequence *will* be applied. If there are any issues that WG
Members feel are critical to address before Last Call, then it is essential
to make sure they are in the bug system ASAP and that other required
milestones are met.

This timeline is primarily intended for the HTML5 draft. However, if any
editors feel they have other drafts that are ready to proceed to Last Call
on the same schedule, please let the Chairs know as soon as possible, by the
end of the week at the latest.

If anyone has any questions, feel free to ask here, ask the chairs
privately, or ask offlist on www-archive.

= Timeline =

- Oct 1, 2010 - cutoff for bugs to be considered as pre-LC feedback
Consequence of missing this date: bugs beyond this date will be treated as
Last Call comments. The Chairs could grant exceptions on a case-by-case
basis, but in general there is no guarantee of a bug filed after the cutoff
being settled before Last Call.

Note: We're working with the editor to find ways to ensure tighter change
control for the draft after the cutoff date, but we do not have anything to
announce on this front yet.

(2 months + 1 week for TPAC)

- Dec 8, 2010 - all bugs filed by cutoff date addressed by editor
Consequences of missing this date: bugs still open past this date can be
escalated to issues immediately if the originator so chooses.

(1 month + 2 weeks for winter holidays)

- Jan 22, 2010 - cutoff for escalating bugs for pre-LC consideration - all
issues in tracker, calls for proposal issued by this date
Consequences of missing this date: any further escalations will be treated
as a Last Call comment.

 (1 month)

- Feb 23, 2011 - every issue has at least one Change Proposal
Consequences of missing this date: issues will be closed without prejudice
and marked POSTPONED; can be reconsidered during LC or for a later version
of HTML.

 (1 month)

- Mar 22, 2011 - all calls for counter-proposals complete
Consequences of missing this date: if any issue has only one proposal, we
call for consensus on that proposal.

 (1 month)

- April 22, 2011 - all issues resolved; LC resolution presented to group
Consequences of missing this date: this would be solely a failure by the
chairs, so we would publicly eat crow and plot a new date.

 (1 month)

- May 22, 2011 - fixable LC objections addressed; if all goes well, LC
resolution carries
Consequences of missing this date: try LC resolution again.

Maciej Stachowiak
(on behalf of the HTML WG co-Chairs)