Re: Editor's drafts on /TR/… ftw, was Re: new TR tools and editor's drafts?

Hi Marcos, comments inline with <fh>

regards, Frederick

Frederick Hirsch
Nokia



On Jul 2, 2013, at 12:00 PM, ext Marcos Caceres wrote:

> 
> 
> 
> On Tuesday, 2 July 2013 at 14:24, Frederick.Hirsch@nokia.com wrote:
> 
>> Are we are conflating discovery with "living specs"?
>> 
>> Editors drafts should be allowed to be broken, etc as they are just that, editor drafts and should be separate from "approved" "authoritative" material - there is value in being able to reference approved material.
> I think groups + editors should be given a choice here. As I've argued and shown (to death), "authoritative" drafts are often way more broken than Editor's drafts.  
> 

 <fh> Not sure everyone agrees (from following the thread) - so it isn't "shown to death". I think there is merit to both points of view. I agree that WGs should have some choice in the matter, however I'm not sure how much leeway the W3C process gives ( or will give).

> Hence, if groups want to keep low priority, broken things, they can do so (and call them Editor's drafts). But other groups should be able to list things as "Living Standards" that are "authoritative" - it would be nice to have a W3C sanctioned style sheet and pub-rules recognized status for this.  
>> Thus there is no logical reason to put them in TR other than to have a single repository.  
> 
> I agree for discardable things. But for something labelled a Living Standard, it should get the "authoritative" respect it deserves. But again, it should be up to the WG. That way, Editor's drafts can remain if people want them - and having something labelled Living Standard signals that there is no Editor's drafts.   


 <fh> Marcos, this it the key point - we need to allow a "living standard" document type if W3C team and members agree to it, thus we aren't talking about "Editor Drafts" (let's keep that as it was understood previously).  Living Standard would be a new document type, not ED, not LC, not CR and not REC, but something different that needs to be understood as such. That makes it easier to have both approaches as makes sense for the community yet also avoids confusion with earlier approaches.

>> Given the use of links I'm not sure that consistency of storage location is a major requirement.
>> 
>> Currently TR drafts have links to the editors draft.
> Yes, and this is very frustrating for us that never want to read the outdated stuff on TR.   

 <fh> On the other hand, not so frustrating if one understands that one reflects approval at a point in time and the ED is a more fluid snapshot that is not stable (and not necessarily to be taken as having any standing whatever).

>   
>> 
>> I'm probably missing something in this discussion, but it seems like the "living spec" discussion again.
> 
> Funny how it keeps coming up, huh?  

 <fh> I'm sure you are helping with that :)

> 
> As I've said, the best way to handle this is to give groups a choice. There is really no need for us to butt heads around this - we should just allow different work modes. When the W3C does not allow different work modes, then Editor's route around it (and publish stuff on a different license - the most liberal license of all - C0):
> 

 <fh> Fundamental question - how open is W3C to giving choice versus locking down process. I understand that choice would meet different group philosophy requirements with the risk of confusing non-W3C members who don't follow the details. Hence the need for clear labeling. I think we agree on this.

 <fh> Thanks for being articulate Marcos.


> http://dom.spec.whatwg.org/
> http://fetch.spec.whatwg.org/
> http://url.spec.whatwg.org/
> http://whatwg.org/c
> 
> (That's like the core of the Web Platform! It completely undermines the whole trying to come up with a new W3C license effort AND the whole /TR/ is authoritative thing)   
> 
> And so on… there is a bunch more of those specs working around the W3C's limitation. I've been personally resisting moving my specs to the WHATWG (because I strongly believe there is a solution and know we can solve this … I just don't understand why it's taking so long to solve it :( ).   
> 
> 
>

Received on Tuesday, 2 July 2013 20:29:18 UTC