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