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 Saturday, 9 November 2013 12:05:40 UTC