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

In the past we tied things to formal publication stages that don't need 
to be tied to a particular stage of the whole draft.

Any TR publication, like a heartbeat draft, could have a section right 
after status that was "Call for Review".  that section would point out 
sections and particular issues the WG particularly wants feedback on.  
Individual sections of the draft or issues for review could be noted 
throughout the draft.

So, it wouldn't need to be a review that the whole draft is ready for 
LCCR.  It could be the WG thinks a particular section is done and 
indicate the WG is considering labeling it as stable.

There could be a public call for review mail list for all W3C specs 
where publications of TR drafts with calls for review were announced 
(not a discussion list - a low volume announement list).   So instead of 
trying to track WG mail lists, someone outside the WG who wanted to know 
when to review, could subscribe to that list.  That would also provide a 
record of the WGs effort to get wide review.

There could also be a similar notification section about which sections 
are stable in drafts (have been through a call for review and issues are 
resolved to the extent the WG is going to resolve them).  With 
notification when sections are marked as stable by a WG after successful 
reviews to the call for reviews list (as an outcome of the review).


On 11/7/2013 5:38 PM, Sylvain Galineau 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.
> 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. 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;
> I do not think the previous one did either.
>

Received on Friday, 8 November 2013 20:49:07 UTC