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

On Oct 26, 2013, at 1:35 , Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

> 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.

That's fine.  Just give people a name they can use (a consistent name) if they wish.

> 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.

It's not pretty to tell the public "oh, thanks for your feedback, but there are too many implementations to change now"…  :-(


> 
>>>> 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
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Saturday, 26 October 2013 01:26:58 UTC