On Thu, 10 Apr 2014 00:07:25 +0200, Arthur Barstow <art.bars...@nokia.com> wrote:

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.]

The idea is that instead of setting an expectation of "do the spec, have a Last Call, then see if it works", groups should expect to work on specs with testing feedback as they go.

* 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.

Agreed.

[I mention this because some have stated the proposed process is `more agile`.]

I'm not quite sure what anyone means by that - it seems to be bandied around as a magical incantation more powerful than "in public" and "on github" combined...

My goal (as editor) was to have a process that was more flexible to match the few groups that still wanted to work on the "write a spec, deskcheck it, implement it" model, while supporting what I think is a far more common and usually more effective model of "write implement and test a piece, clean it up and start another piece (or two)".

The Process (contrary to what Art suggests below) does retain the idea of heartbeat publication, but rather than being based on time (unless nothing is happening at all) they are called for when there is a significant change that would benefit from broader review. I.e. as a signal for "look carefully at what we did here and here please".

* 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.

Well yeah. The real work doesn't change much.

* 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.

There is a clear *should* requirement - there *should* be a TR publication when something significant has changed that would benefit from wide review.

(The process makes the hopeful assumption that the publication process itself gets reasonably streamlined).

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

The proposed process doesn't particularly support that model (i.e. you are avoiding doing what it say you *should* do).

But in any event, a review snapshot and an ED are different. Implementors, and people working on the spec in the group, should usually be reading the Editor's draft.

But for reviewers who cannot follow the work as it moves through the group (time commitment, language difficulty, etc) having documents that are clearly identified as "for review" (and ideally, which point out which parts are worth reviewing because they have changed, which parts remain stable from the last such snapshot, which parts are basically in flux and should be expected to change significantly more than the rest) is extremely valuable.

A big goal is to get those reviews, as well as CR reviews, earlier in the process, instead of spinning around LC/CR for most of the development time of the spec saying "it's almost finished"...

* 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.

Don't ask me. I wasn't a big part of that decision process. But I *think* we could be a new group if we wanted to, although we could continue any specs that are "almost finished" under the old process.

[Thank gawd Yves and Cindy will be responsible for `managing` this process ;-)]

[Indeed. Although I think (hopeā€¦) it *looks* much more complicated than it will be in practice].

Comments about how the above are welcome as well as any other comments about how the proposed TR process could affect the group.

It should not affect the group much at all, except that if we do a CR more or less right we won't have to go back through Last Call to revise it.

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
      cha...@yandex-team.ru         Find more at http://yandex.com

Reply via email to