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
- [admin] WebApps and the Proposed changes to the TR... Arthur Barstow
-
