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

I agree with Steve -- I was comfortable with how we resolved Issue 9 in the AB, but the sense I get from the AC discussion is that we need to revisit how to signal that a document is ready for wide review if we are removing the process steps that nominally gave signals.  I hope we stick with our previous resolution that wide review means whatever a WG can convince the Director it means in a particular case.

-----Original Message-----
From: Jeff Jaffe [mailto:jeff@w3.org] 
Sent: Saturday, November 9, 2013 1:59 PM
To: Stephen Zilles; Michael Champion (MS OPEN TECH); Charles McCathie Nevile; Marcos Caceres; Tobie Langel; Sylvain Galineau
Cc: David Singer; 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]

On 11/9/2013 3:37 PM, Stephen Zilles wrote:
> Jeff,
> I do not think the comments that have been received are so much concerned with what does "Wide Review" mean, but are concerned with "how is it encouraged/ensured". For that reason, I think opening a new issue is a better way to deal with the problem and keep the discussion more focused.

Either way, but I always thought that the latter was an important part of Issue-9, which is why it is in the text of the issue.

>
> Steve Z
>
> -----Original Message-----
> From: Jeff Jaffe [mailto:jeff@w3.org]
> Sent: Saturday, November 09, 2013 4:05 AM
> To: Michael Champion (MS OPEN TECH); Charles McCathie Nevile; Marcos 
> Caceres; Tobie Langel; Sylvain Galineau
> Cc: David Singer; Stephen Zilles; 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]
>
> On 11/8/2013 12:56 PM, Michael Champion (MS OPEN TECH) wrote:
>>>    it errs on the side of giving responsibility to Working Groups, 
>>> rather than giving them administrative hoops to jump.
>> That's a great short summary of what the AB and the Process CG are trying to do here.  But I'm hearing feedback suggesting that we need to think a bit harder about the "signaling" role of the process steps we're proposing to eliminate.  Maybe the process document should say something about the mechanism by which WGs and chairs should signal a need for outside review even though we're decoupling the signals from the "administrative hoops."
> I suggest we re-open Issue-9.
>
> https://www.w3.org/community/w3process/track/issues/9
>
>> The process has to be flexible.  There are probably going to be traditional WGs that start with nothing but a charter, others that start with multiple input specs with the same scope but different syntax/semantics, and probably more and more that start with  fairly mature CG Final Report, member contribution, snapshot of a "living" spec, etc. Maybe we can handle all these scenarios better in the revised process document, but we can't pretend that all WDs are equally open to substantial revision by external reviewers just because they are at the same stage in the formal process. That's the bug we're trying to fix here.
>>
>> On a related matter, we might want to tweak the draft process to give clearer guidance about how to prevent the most frustrating "administrative hoop" that I hear about:  Going backwards in the process in order to meet late-breaking requirements or remove unimplemented features.Maybe the new process should encourage WGs to move forward to Rec with the features that are really interoperable, dropping other features whether or not they were marked "at risk" and moving them to the queue for v.next.  That's not viable when there is a 5-10 year timeline between versions of a Rec, but it's business as usual in "agile" software development approaches we're trying to learn from.  Yes those situations probably require a louder "you need to review this, it's not what we said we would do" signal from WGs.  The AB has proposed to treat this as the responsibility of WGs to execute properly rather than as inexplicable bureaucratic minutia that WGs have to do "just because".
>>
>> So this is sortof a rambling way to ask the AC:  Should the new process say more about the conditions and mechanisms of a "call for wide review" or should we leave this as an implementation detail for WGs to figure out how to do properly given the constraint that they ultimately need to convince the Director that the wide review has happened?
>>
>>
>> ________________________________________
>> From: Charles McCathie Nevile <chaals@yandex-team.ru>
>> Sent: Friday, November 08, 2013 8:13 AM
>> To: Marcos Caceres; Tobie Langel; Sylvain Galineau
>> Cc: Michael Champion (MS OPEN TECH); David Singer; Jeff Jaffe; 
>> Stephen Zilles; 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]
>>
>> On Fri, 08 Nov 2013 02:38:20 +0100, Sylvain Galineau 
>> <galineau@adobe.com>
>> wrote:
>>
>>> On 11/7/13 10:02 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>>>> On Thursday, November 7, 2013 at 1:40 PM, Tobie Langel wrote:
>>>>
>>>>> On Thursday, November 7, 2013 at 7:48 AM, Michael Champion (MS 
>>>>> OPEN
>>>>> TECH) wrote:
>>>>>> What we did consider are a couple of points:
>>>>>> - The LC and CR signals in the current process tend to happen 
>>>>>> these
>>>>> days after specs are widely implemented and what might sound like 
>>>>> constructive suggestions (e.g., "the names aren't very intuitive") 
>>>>> are made too late to be helpful.
>>>>>
>>>>> It is absolutely critical to get developer eyeballs looking at the 
>>>>> specs before it's too late to change the APIs. Anything that helps 
>>>>> with this is an important step forward.
>>>>>
>>>> Agree. It's also never too early to get input into a spec from anyone.
>>>> Taking away signals that allow people to wait longer to provide 
>>>> feedback would actually be a good thing. LC or CR is _waaaaayyy_ 
>>>> too late to be providing feedback.
>> Right.
>>
>>> It's too late because LC assumes most substantive feedback has 
>>> already been handled. A few weeks of LC only makes sense if you 
>>> assume wide review to have already happened.
>> Indeed. So the new process makes wide review a requirement before you 
>> get to LCCR.
>>
>> (And yeah, th name is horrid. Any consensus on what it should be? It 
>> seems at a glance that Candidate Recommendation is the popular choice).
>>
>>> So I'm not sure we're debating a new issue here.
>>> Most web developers I know never really understood what Last Call 
>>> means or what kind of a time window it involves. The new process 
>>> does not fix this;
>> It sets a little bit of explectation, but it errs on the side of 
>> giving responsibility to Working Groups, rather than giving them 
>> administrative hoops to jump.
>>
>>> I do not think the previous one did either.
>> A little, but not much.
>>
>> Ultimately, the process can mandate what it wants, but getting the 
>> right eyeballs on the spec is the job of the Working Group and 
>> nothing written in the requirements is more than encouragement to do it right.
>>
>> IMHO.
>>
>> cheers
>>
>> --
>> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>>          chaals@yandex-team.ru         Find more at http://yandex.com
>

Received on Sunday, 10 November 2013 17:49:50 UTC