Re: [admin] WebApps and the Proposed changes to the TR Process

On Thu, 10 Apr 2014 00:07:25 +0200, Arthur Barstow <art.barstow@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
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 10 April 2014 07:09:23 UTC