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

Re: Transition to a revised Technical Report Development Process [W3Process-ISSUE-39, W3Process-ACTION-10, proposal]

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Sat, 26 Oct 2013 09:35:55 +0100
Cc: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, "Stephen Zilles" <szilles@adobe.com>, "Ralph Swick" <swick@w3.org>, "Advisory Board" <ab@w3.org>, "W3C Process Community Group" <public-w3process@w3.org>
To: "Jeff Jaffe" <jeff@w3.org>, "David Singer" <singer@apple.com>
Message-ID: <op.w5i7p5boy3oazb@chaals.lan>
On Sat, 19 Oct 2013 00:51:00 +0200, David Singer <singer@apple.com> wrote:

>
> On Oct 14, 2013, at 20:57 , Jeff Jaffe <jeff@w3.org> wrote:
>
>> On 10/14/2013 11:27 PM, Michael Champion (MS OPEN TECH) wrote:
>>> I'm proposing the next recharter or charter extension as the forcing  
>>> function to move to the new process. That might be too draconian for  
>>> some groups or specs, but the Director/team can use discretion in such  
>>> cases.
>>>
>>>> It becomes too confusing to start all over again.
>>> I'm still not understanding this point.  The new process eliminates  
>>> steps, it doesn't force anyone to "start all over again".
>>> What's the scenario you're concerned about?
>>
>> I'm sympathetic to the worry.  I've spent a great deal of time with  
>> Tracking Protection of late.  I can imagine great frustration if they  
>> were driving all of their effort towards LC, and all of a sudden they  
>> were told that there is no LC; instead they need to drive to LCCR and  
>> demonstrate wide review - something that they had never planned on  
>> doing before getting to LC.
>
> I agree, this could be ugly.
>
> "we have a document, please give us public comment"
> "OK, we have addressed the public and other comments, now implement and  
> tell us what we missed"
>
> do seem to be pretty separate steps.  how does the new process envisage  
> them?

As the responsibility of the Working Group to determine how to handle. It
seems that in most successful cases there is in fact implementation going
on at a very early stage, often before the public has even had a chance to
comment.

>>> To be clear, I'm not objecting to Ralph's proposal, I just think it's  
>>> a bit more complicated than we really need.  But if others are happy  
>>> with it let's adopt it and move on.
>>>
>>> ________________________________________
>>> From: Stephen Zilles <szilles@adobe.com>
>>> Sent: Monday, October 14, 2013 4:36 PM
>>> To: Michael Champion (MS OPEN TECH); Ralph Swick; Advisory Board; W3C  
>>> Process Community Group
>>> Subject: RE: Transition to a revised Technical Report Development  
>>> Process  [W3Process-ISSUE-39,  W3Process-ACTION-10, proposal]
>>>
>>> Mike,
>>> One concern I have with your proposal (and Ralph's too, I believe) is  
>>> that for "Supergroups" there is no forcing function to move specs to  
>>> the new process. The CSS working group (I hate to say this) has some  
>>> specifications that date back to 2006. That means that without a  
>>> forcing function we could still have two processes seven years after  
>>> the change.
>>>
>>> I like your goal of simplicity, but there are two things in Ralph's  
>>> proposal that seem to me to be useful. One is that specs that are  
>>> largely done be completed under the old process; that is, the WG does  
>>> not have the choice to make the change. It becomes too confusing to  
>>> start all over again. The other is that there should be some public  
>>> notice of the change of process for existing document. This seems to  
>>> me to be a useful requirement.
>>>
>>> Steve Z.
>>>
>>> -----Original Message-----
>>> From: Michael Champion (MS OPEN TECH)  
>>> [mailto:Michael.Champion@microsoft.com]
>>> Sent: Monday, October 14, 2013 1:43 PM
>>> To: Ralph Swick; Advisory Board; W3C Process Community Group
>>> Subject: RE: Transition to a revised Technical Report Development  
>>> Process [W3Process-ISSUE-39, W3Process-ACTION-10, proposal]
>>>
>>> Maybe I'm missing some devils lurking in the details, but I would have  
>>> thought the policy would be simpler, something like:
>>>
>>> 1. All Technical Reports published after the adoption of a revised
>>>    TR Development Process will state in the Status of This Document
>>>    whether they were developed under the 2005 Process or under the
>>>    new [2014] Process.
>>>
>>> 2. All new Working Groups whose charters are in AC review or existing  
>>> WGs
>>>    whose charters (including rechartering and extension) are about to  
>>> be approved by the Director MUST follow
>>>    the new [2014] TR Process.
>>>
>>> 3. Any existing Working Group MAY decide to follow the new TR Process
>>>    for any Recommendation Track documents.
>>>
>>> In short, WGs MAY choose the new process any time after it's made  
>>> official, new/rechartered WGs MUST use the new process.  As always,  
>>> the Director can grant dispensation for special cases where moving to  
>>> the new system would be inconvenient/inefficient, we don't need to  
>>> think through them all.
>>>
>>>> I do not think that Recommendation track documents that are close to  
>>>> Last Call under the current [2005] Process should be moved to a  
>>>> different Process.
>>> If we have crafted a good change to the process document, it's hard  
>>> for me to imagine why WGs would choose to inflict both LC and CR steps  
>>> on themselves.  LC is more or less just a busywork step that really  
>>> doesn't mean "last chance to comment" or "the spec is stable and ready  
>>> to implement."  If any WGs tell us during the review period that they  
>>> want to stick with the old process, I would take that as evidence  
>>> we've done something wrong.
>>>
>>> -----Original Message-----
>>> From: Ralph Swick [mailto:swick@w3.org]
>>> Sent: Monday, October 14, 2013 5:55 AM
>>> To: Advisory Board; W3C Process Community Group
>>> Subject: Transition to a revised Technical Report Development Process  
>>> [W3Process-ISSUE-39, W3Process-ACTION-10, proposal]
>>>
>>> Re: ISSUE-39: Managing the transition to a new TR cycle
>>>
>>> Should the W3C Advisory Committee approve a new Technical Report  
>>> Development Process the Director will need to state the manner and  
>>> schedule for deployment of the revised Process.
>>>
>>> As a stake in the ground for discussion, I propose the following:
>>>
>>> As of the Director's announcement of the approval of a new Technical  
>>> Report Development Process:
>>>
>>> 1. All Technical Reports published after the adoption of a revised
>>>    TR Development Process will state in the Status of This Document
>>>    whether they were developed under the 2005 Process or under the
>>>    new [2014] Process.
>>>
>>> 2. All new Working Groups whose charters are either in AC review or
>>>    whose charters are about to be approved by the Director will follow
>>>    the new [2014] TR Process.
>>>
>>> 3. Any existing Working Group whose charter is revised ("rechartered")
>>>    other than extending the end date will follow the new TR Process
>>>    for any Recommendation Track documents that are added to the  
>>> charter.
>>>
>>> 4. Any Working Group with Recommendation Track documents previously
>>>    published as Last Call Working Drafts or that are within 4 months of
>>>    expected publication as Last Call Working Drafts will follow the
>>>    2005 Process for those documents.
>>>
>>> 5. A Working Group whose charter was approved prior to the adoption of
>>>    the new TR Process may choose either the 2005 TR Process or the new
>>>    [2014] TR Process for Recommendation Track deliverables not yet
>>>    published as Working Drafts or with a Last Call Working Draft
>>>    scheduled to be published more than 4 months after the approval of
>>>    a new TR Process.  Before making a decision the Working Group
>>>    should formally open an issue on this question for each affected
>>>    document and allow comment from outside the Working Group.  The
>>>    normal issue review process -- including report to the Director at
>>>    transition points -- must be followed for this issue.
>>>
>>> Rationale: Given the sorts of Process changes proposed in the current  
>>> draft I believe that it will be only slightly more confusing to have  
>>> Recommendation Track documents from a single Group proceed under  
>>> different Processes than were those same documents to be produced by
>>> different Groups.   The Group should be entitled to choose which  
>>> process
>>> to follow, however; the Group and the community to whom the Group is  
>>> addressing its work may have a preference based on the relationship  
>>> between the various documents produced by that Group.
>>>
>>> I do not think that Recommendation track documents that are close to  
>>> Last Call under the current [2005] Process should be moved to a  
>>> different Process. "Close to" is a judgement call but 4 months feels  
>>> about right to me as a starting point for consideration.
>>>
>>> -Ralph
>>>
>>>
>>
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
           chaals@yandex-team.ru         Find more at http://yandex.com
Received on Friday, 25 October 2013 22:36:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 25 October 2013 22:36:42 UTC