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

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.

     (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 Tuesday, 2 July 2013 21:42:18 UTC