RE: Plan for progression of Media Capture and Streams towards W3C Last Call

Can you clarify on the procedure for opening bugs ("everyone's encouraged to file bugs on the "Media Capture and Streams" component in Bugzilla")?  

I was instructed on this mailing list by one of the editors that only the chairs can open bugs:  see http://lists.w3.org/Archives/Public/public-media-capture/2014Feb/0130.html. 

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Thursday, May 08, 2014 4:58 AM
To: public-media-capture@w3.org; Stefan Håkansson LK
Subject: Plan for progression of Media Capture and Streams towards W3C Last Call

With the closure of the Constraints topic, we believe that the last major item on this document is closed, and that the rest of the stuff we need to do consists of finding and fixing the remaining smaller issues.

As of this writing, there are 14 open bugs. There will be more.

The chairs are suggesting the following timeline:

- Yesterday, May 7: New version of the spec, with the conclusion of the Constraints discussion, published.
- From that publication to Sunday, May 18: WG review. Open season for bug filing; everyone's encouraged to file bugs on the "Media Capture and Streams" component in Bugzilla.
- Monday, May 19: Face to face time - we spend time discussing stuff that is beyond the nits stage. The chairs pick bugs to address.

At this time, we close the buganizer for input, saying that items should instead be raised on the mailing list if necessary, with the chairs filing bugs when needed, and work on burning down the buglist.

- When the bug list is empty of bugs filed before May 18, and the resulting document is published, we give a VERY short last period for review, and then send the document for W3C Last Call.

We do expect to see feedback on the W3C Last Call. Issues will be raised.

Hopefully, we can start burning those down in June; how much progress we make determines how much time we will need for the next process steps.

Also hopefully, we'll have a stable spec.

NOTE: The preferred format for proposed minor fixes or changes in wording is a Git pull request.
Those are fast to process, and accomplish what the suggester wanted.
For stuff that actually changes the meaning of the document, mailing list discussion is desirable.

Harald, for the chairs.

Received on Thursday, 8 May 2014 12:19:32 UTC