W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

Re: 2014 Process: WD -> CR difficulties

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 2 Oct 2014 09:14:35 +0000
To: Jeff Jaffe <jeff@w3.org>, "public-w3process@w3.org" <public-w3process@w3.org>
CC: Coralie Mercier <coralie@w3.org>, Philippe Le Hegaret <plh@w3.org>, Thierry MICHEL <tmichel@w3.org>, Ian Jacobs <ij@w3.org>
Message-ID: <D052C7C3.12B0F%nigel.megitt@bbc.co.uk>

Thanks for the additional points. Some have simple answers, happily.


On 01/10/2014 23:00, "Jeff Jaffe" <jeff@w3.org> wrote:

>You've already gotten some great input on the list.  I have but a few
>additional thoughts.  Hope it helps.
>On 10/1/2014 9:01 AM, Nigel Megitt wrote:
>> Process folk:
>> TTWG has chosen to adopt the 2014 process for all its recommendation
>> products in development. I understand that we're about to go through
>> process first of all working groups.
>> Recent Experience
>> -----------------
>> We recently wanted to transition one document to CR, but were advised
>> the requirements for getting to CR are the same as they were for exiting
>> LC previously; yet without an LC we didn't have a clearly defined
>> mechanism for meeting those requirements. Specifically the need to
>> demonstrate wide review seemed to be vague, and triggered a "we aren't
>> sure what view the Director will take" response from staff, which, while
>> true, wasn't ideal for them or us.
>This is understood.  I expect that we will learn more from experience.
>I wouldn't say that getting to CR are the same as exiting LC.  We are
>trying to provide more flexibility to Chairs to determine what "wide
>review" makes sense for their WG.

As a chair, I need to be clear what decisions I should be making vs what
the group should be making. In of the 2014 Process it says "The
requirements for wide review are not precisely defined by the W3C Process"
and it describes the objective of the review, and indeed that the Director
will consider the review, but it does *not* say who should define the
review requirements for a specific document. If the intention is that this
should be the chair, I'd go along with that, and suggest an edit along the
lines of:

	The requirements for wide review are not precisely defined by the W3C


	The requirements for wide review are not precisely defined by the W3C
Process, and SHOULD be defined by the Group Chair.

Alternatively, the Working Group itself could take the action for defining
the requirements, I suppose.

I don't mind if the Director chooses to take this decision process into
account as part of considering the review: I guess the outcome is more
important than the process for the Director in this case.

If such an edit is not feasible then guidance that groups or chairs should
define the requirements for wide review explicitly as a pre-transition
step should be written down somewhere.

>> We chose to issue a new WD and put out as big a call for review as
>> possible. But there's been quite a bit of debate about how the process
>> could assist here.
>Here is an interesting test for TTML specifically.  In Section 3.3 of
>the TTML Charter you list external groups that should care about the
>spec, e.g. SMPTE.  So you might ask yourselves whether the call for
>review that you sent out as a minimum reached such external groups (as
>well as internal) that you care about.

We've already started on contacting external groups, and even left
ourselves extra time in the review period to take into account that it's
typically slower to send external bodies than W3C groups. We sent the
internal W3C notices first simply because it was quicker to do so.

A question arising here is the status of the liaisons [1] - even if
they're not on the group's charter it seems like it might be a good idea
to contact many of them. There's no algorithm for determining which bodies
to contact, though there does seem to be some metadata. Each
organisation's "W3C Activities affected" are listed, and each
Group/document has an overlap with a set of activities. So we could make
the wide review "wide" by finding the set of all groups which have an
"activity affected" that is also affected by the document. In the case of
IMSC 1 that results in 2 (Timed Text) + 7 (Web and TV) + 29 (WAI) = 38. It
sounds like a lot. Maybe the metadata isn't sufficiently fine-grained to
support this kind of query.

[1] http://www.w3.org/2001/11/StdLiaison.html

>> What in the process caused the problem?
>> ---------------------------------------
>> The 2014 process has streamlined the LC -> CR -> LC -> CR -> ... process
>> to make it quicker and less painful by removing LC, which is great, but
>> seems not not to have fully addressed WD -> CR.
>> Previously, WD -> LC -> CR was a set of clearly defined (or at least
>> understood) steps that were each manageable.
>> 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
>> good idea to clarify exactly what is needed to go from WD to CR and how
>> 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.
>I believe that we have said explicitly that individual WGs and Chairs
>have the flexibility to replicate the old Last Call if they feel that is
>useful for their groups.

I can not find this in the Process document. Maybe it's another example
where flexibility exists but, being unstated, is non-obvious, especially
to relatively new chairs.

>> 	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
>> 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.
>> Have we missed anything?
>> ------------------------
>> Is there anything in the process that we should have used to alleviate
>> this problem, but maybe missed?
>> Are there other suggestions for how to make WD -> CR as pain-free as
>> possible?
>Tough question and a tough call.  We were deliberate in wanting to add
>flexibility to groups to progress as they see fit and not be locked into
>a stepwise process.  The suggestion to start collecting best practices
>might be the best way to make it descriptive, if not prescriptive.
>> Kind regards,
>> Nigel
>> Co-chair, TTWG
>> On 01/10/2014 13:31, "Ian Jacobs" <ij@w3.org> wrote:
>>> On Oct 1, 2014, at 7:29 AM, Thierry MICHEL <tmichel@w3.org> wrote:
>>>>>> If we don't ask the public/W3C groups/External group to review the
>>>>>> latest WD version (the one before entering CR) , I don't see how the
>>>>>> director will be satisfied with a review done on former WD documents
>>>>>> which are obsolete.
>>>>> I think a heads up to the chairs is a fine idea. But the AB wanted to
>>>>> leave groups greater freedom in how they get review.
>>>> Your response does not respond to the above issue,it is not a matter
>>>> about heads up to the chairs, the issue is about the WD version that
>>>> needs to get wide review on. Would a former review on a obsolete
>>>> satisfy the Director ?
>>> I do not know for all possible cases. Suppose you published a draft
>>>"LC -
>>> 1" that was mostly stable and got lots of review, then did an update
>>> got review from someone new on the changes. Would that satisfy the
>>> Director? My guess is yes.
>>> Ian
>>> --
>>> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs

>>> Tel:                       +1 718 260 9447

Received on Thursday, 2 October 2014 09:15:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:21 UTC