Re: 2014 Process: WD -> CR difficulties

On 01/10/2014 14:26, "chaals@yandex-team.ru" <chaals@yandex-team.ru> wrote:

>01.10.2014, 15:02, "Nigel Megitt" <nigel.megitt@bbc.co.uk>:
>> Process folk:
>>
>> TTWG has chosen to adopt the 2014 process for all its recommendation
>>track
>> products in development. I understand that we're about to go through
>>this
>> process first of all working groups.
>
>Good luck, and thanks for making the effort of documenting your way...

Thanks for reading, and for your helpful suggestions!

>
>[...]
>> Now, WD -> CR is a much bigger step; the requirements for entering CR
>> haven't changed but the opportunity for meeting those requirements has
>> been elided.
>>
>> What can be done to mitigate the problem?
>> -----------------------------------------
>>
>> If we want to keep the benefits of the current process then it would be
>>a
>> good idea to clarify exactly what is needed to go from WD to CR and how
>>it
>> can be achieved.
>>
>> Here are a couple of non-mutually-incompatible suggestions to mitigate
>> this from being a more widespread problem across other groups, hopefully
>> without adding significant delay or complexity:
>>
>>         1. Offer the possibility (rather than a requirement) of a
>>"Last" label
>> for a Working Draft, which is still a WD, but one that groups wish to
>> signal is intended for transition to CR next.
>
>A number of groups already did this, producing a "pre-Last Call" draft.
>How exactly you say "Working Draft, hopefully ready for CR" is up to you
>- there is nothing in the Process that prohibits saying  "'last call'
>Working Draft" (not sure if W3C has any "pubrules" about this).

To aid communications about this concept it would be helpful if all groups
could adopt a common label for it.

>
>If you're publishing under the new process, that is a Working Draft, and
>doesn't trigger a call for exclusions. If you made significant changes as
>a result of lots of people reviewing it, you would need to show that
>those changes were also reviewed, as you note below.
>
>>         2. Create an independent "wide review" process step that may be
>>applied
>> to any document (in WD or CR) for use whenever wide review may be
>> required; recommend that this is executed at least once on at least one
>>WD
>> prior to requesting transition to CR, and that if there's significant
>> change between the wide review and the version that's being transitioned
>> to CR then continued review needs to be demonstrated.
>
>I'm not sure what that step would look like.

It would look like:

* Upon publication of the document:

** Request review from the following set:
*** The general public via W3C home/news pages and any other public comms
routes available
*** All the W3C dependencies and groups listed in the WG's charter
*** All the External groups listed in the WG's charter
*** All the W3C liaisons who have expressed an interest in the WG's work

** Where Request for review may be tailored for different recipients, but
should include:
*** What kind of feedback is being sought
*** Review timeline and feedback mechanism
*** Abstract and Status
*** Link to document to be reviewed
*** Link to W3C Process
*** Next steps intentions of WG for this document
*** Reason why the recipient of the request has been singled out


>>Have we missed anything?
>
>If you publish regular drafts, and have identified what changed, then you
>should be able to request review specifically of the pieces that changed.

Yes, makes sense. If the impact of the changes goes wider, it would be
fair to point that out too.

>Reviews of an earlier spec, that said it was all fine except section 8
>and 9, along with reviews of new sections 8, 9 and 10, seem like evidence
>of wide review even if they are not from the same people. Reviews of an
>early version that say "all looks good", and the same reviewer saying
>"oh, the changed sections 8-10 are still good/even/better/acceptable if I
>have to" also shows the spec has been reviewed.
>
>The hard thing is to get people to review and say "this looks good to me"
>having actually carefully read it. Another way to demonstrate that people
>have reviewed it is by finding implementations done by people who aren't
>involved in the Working Group. If the spec has been "battle tested" then
>it suggests that someone has been looking at it, whether they carefully
>commented on all the typos they found, or not. As you know, "wide review"
>is not formally defined as a mechanical set of rules.

Yes, that would be good evidence. We will also need to plan what evidence
of implementation will look like, for CR exit, of course.

>
>As chair, a brief chat to your domain lead might help clarify what to
>expect, given there is no obvious precedent.

That's what got us into this mess in the first place ;-)

Cheers,

Nigel

Received on Wednesday, 1 October 2014 14:55:19 UTC