- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 09 Apr 2014 15:07:25 -0700
- To: public-webapps <public-webapps@w3.org>
TL;DR: April 21 is the deadline for comments for LC#2 of a revised Technical Reports (TR) process <https://dvcs.w3.org/hg/AB/raw-file/5508dec95a6a/tr.html>. If you have any comments about LC#2 itself, please send them to the public-w3process list <http://lists.w3.org/Archives/Public/public-w3process/>. Below are some of my thoughts about the proposed revisions to the TR process and WebApps ... * I think the only really substantive change is the removal of LCWDs, thus a spec now goes from WD directly to CR. However, before advancing to CR, the group "must formally address all issues raised about the document since the previous publication". Additionally, there is still an expectation the spec will have wide review although the group has some flexibility to determine how that review is conducted (f.ex. who should be asked to review the spec, duration of the review, etc.). [ItSeemsToMe, this just means the old LC is now implied rather than explicit.] * Given WebApps' work mode and its history of getting specs to REC (see <https://www.w3.org/wiki/Webapps/TimeToREC> for some data), for all practical purposes, if the group was using the proposed process, I don't think would have substantively changed the time to REC since the primary blocking factors have been lack of tests, lack of implementations and in a couple of cases PAGs. [I mention this because some have stated the proposed process is `more agile`.] * Regardless of the specifics of the TR process, the time to REC [which I understand is not necessarily a high priority for all] is still a function of: active and competent Editor(s), active reviewers, active implementers and commitment to testing and interop. * The current (2005) process permits a group to do as much work as they want before LC and thus minimize process and publication overhead. For instance, before LC, a group could seek wide review, create a test suite, implement the spec and prove interoperability. If a group worked as such, after the LC comment period ended (and assuming no substantive comments require going back to WD/LCWD), the spec could skip CR and move directly to Proposed Recommendation. [I mention this because it appears the Gamepad API could be on this type of trajectory.] * With the proposed TR process, if a group wants to minimize process and publication overhead, after the FPWD is published, there is no mandatory requirement that any other TR publication(s) be made before a CR is published. This would certainly be a different workflow than we have followed in the past and I can see some +/- to this approach. If we were to do something like this, we would certainly want to make it very clear in the FPWD that this was the plan/expectation and strongly note that reviewers, implementers, etc. should only use the ED (and ignore the FPWD). * Assuming the Director approves the proposal, there is a somewhat elaborate transition plan defined in <http://lists.w3.org/Archives/Public/public-w3process/2014Mar/0019.html>. Given WebApps' current charter expires at the end of May 2014, it's not clear to me if our new/updated charter would mean we will be a "new" (2014) WG or not; we could be in a situation where some of our specs use 2005 process and others the 2014 process. [Thank gawd Yves and Cindy will be responsible for `managing` this process ;-)] Comments about how the above are welcome as well as any other comments about how the proposed TR process could affect the group. -Thanks, AB
Received on Wednesday, 9 April 2014 22:09:23 UTC