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

comment inline

regards, Frederick

Frederick Hirsch
Nokia



On Jul 2, 2013, at 5:41 PM, ext fantasai wrote:

> On 07/02/2013 01:27 PM, Frederick.Hirsch@nokia.com wrote:
>> 
>>  <fh> Not sure everyone agrees (from following the thread) - so it isn't "shown to death".
> 
> At last TPAC there were like 40 people in a room all arguing that the WG
> should be allowed to update /TR as frequently as they want under whatever
> rules they've resolved on, and that the web site infrastructure should
> support them in this. I can't remember a single argument against that.
> I've only heard Chaals argue that the web site infrastructure already
> supports sufficient frequency for all practical purposes (which I disagree
> with, it is super-impractical).
> 
>> 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).
> 
> The W3C Process is not the bottleneck here, the publication process is.
> 
>>> 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.
>>> 
>>> 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.
> 
> Keeping /TR up-to-date does not require a new type of document status.
> It just requires that editors be able to publish to /TR as frequently
> as is necessary to keep /TR up-to-date, and that we remove any friction
> preventing that from being either possible or practical.
> 
> IMO, the minimal requirements are:
> 
>  - If any editor can publish to /TR on any day of the week in under 5
>    minutes (from "I'm ready to push to /TR" to "It's now published and
>    anyone can see it on /TR"), then the web site infrastructure is
>    sufficiently efficient for keeping /TR up-to-date.
> 
>  - If W3C maintains its current system for publishing snapshots, changes
>    the "This Version" line to say "Latest Snapshot", and simply allows
>    the undated shortname to be a "live" version of the spec (i.e. one
>    that the editor can push to in under 5 minutes, that has the same
>    status as the latest snapshot), then we have sufficient infrastructure
>    to support keeping /TR up-to-date while supporting the W3C Process as-is.
> 


This (and the subsequent thread) makes it clearer. Thanks for clarifying.

>    (If someone thinks this is insecure because it allows an editor to
>    publish anything they want to /TR without the WG's approval and label
>    it as WD/LC/CR/PR/REC... I suggest you don't give write access to /TR
>    to editors you don't trust to follow the WG's directions.)
> 
>  - If W3C maintains some automated way of retrieving previous revisions
>    of the "live" spec, then we have sufficient infrastructure to satisfy
>    those who want access to the historical archive of all things published
>    on /TR, which seems to be a blocking point for having a "live" document
>    on /TR/shortname.
> 
> That's it. It's all solveable by W3C Staff, without intervention of the
> AB, or the AC, or anybody else. Somebody just needs to do it.
> 
> Changing the Process is scope creep imho. Might want to adjust the Process
> to solve other issues, but it's not necessary for keeping /TR up-to-date.
> **I would like to solve keeping /TR up-to-date. I don't want to block it on
> changing the Process.**
> 
> ~fantasai
>

Received on Friday, 5 July 2013 19:38:06 UTC