Re: Put Editor's draft on TR page, not heartbeat formal publications -> RE: Evaluating policies; pubrules

On Thu, 22 Mar 2012 16:31:39 +0100, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On Thursday, 22 March 2012 at 15:28, Carr, Wayne wrote:
>
>> That particular proposal wasn't changing anything about the formal  
>> stages in TR. It was only to use the Editor's draft on the TR page  
>> instead of periodically publishing a WG Draft. (this was a proposal  
>> just about that - there was a different larger proposal).
>>
>> As an example, the html5 draft on the html TR page [1] at this moment  
>> is dated 2011-05-25. It will be updated soon, but the point is that now  
>> WG drafts on TR pages can be so old they're pointless to look at. If  
>> they can't be updated say within 6 weeks, it would be better to publish  
>> the Editor's draft on that page (with any content not agreed to,  
>> including content that is significantly altered, as "recent change, to  
>> be reviewed by WG" or something like that (to avoid concerns over  
>> Editor changes not yet agreed to by the WG).
>>
>
>
> What about having a disclaimer in the SoTD that states "Caution, this is  
> an Editor's draft and hence may contain changes not yet agreed to by the  
> WG"... or some such.
>

The concerns is not about disclaimers. I think is pretty clear that a  
draft is a draft and can change (there are already enough disclaimers in  
the current specs)
But people would like to implement things before the final stage (and this  
is good) and unfortunately monitoring the latest Editor's draft works fine  
in some cases (desktop browsers) and not as well in another cases.

So what I'm trying to suggest is a solution that could work fine for  
different scenarios.

What I feel is needed is two things:
- a draft that reflect at least some discussion in the group so is likely  
not to be an improvement compared to the previous version and not being  
challenged the day after (as opposed to an editor draft that can contain  
all sort of things)
- a status indicator for maturity of different section in the spec, when  
specs are very big and include many (unrelated) features -> but this is  
another thread.

I understand that some of the above is not required in some scenarios, and  
different groups have different working procedures, but I think is good to  
find a solution that works also for external organizations using w3c  
standards, since we do not want to create silos based on outdated specs.

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 22 March 2012 15:46:50 UTC