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

This relates to our ISSUE-2

On Wed, 21 Mar 2012 13:07:21 +0100, Marcos Caceres <w3c@marcosc.com> wrote:
> On Wednesday, 21 March 2012 at 11:51, Arthur Barstow wrote:
>
>> On 3/20/12 4:48 PM, ext Carr, Wayne wrote:
>> > Proposal: For WGs that have public editor's drafts, put the  
>> disclosure notice in the Editor's draft and put the Editor's draft on  
>> the TR page. Don't publish regular formal heartbeat drafts. Just  
>> publish formal versioned drafts for the required stages (First Draft,  
>> LC, CR, PR, REC). Also, provide access to the editor's drafts under  
>> source control so people can look at it at a particular date if they  
>> need to.

Some strawman proposals:

1. It should be possible to find all public drafts.

2. It should be possible, from any given draft, to find the latest version  
and to work out how the draft you are looking at relates to other drafts.

3. It should not be painful to publish a draft as the latest that should  
be found easily through normal searching.

>> Isn't this already the case for WGs that include a link to the Editor's
>> Draft in the spec header and don't enforce heartbeat pubs just for the
>> sake of it?
>
> No. At least in my case, the requirements are practical: I always want  
> to be looking at the latest and greatest and not some stale version on  
> /TR/ (this keeps biting me when I Google and get the wrong version!). An  
> ordinary outdated WD on TR is unhelpful.

But so is an undated Editor's draft, that happens to include some random  
idea the editor added last night, which on mature reflection Monday  
morning will be removed. The latest and greatest is often at least as  
unhelpful as an outdated "heartbeat" draft.

>> If a WG does want to publish intermediate WDs (i.e. WDs between FPWD and
>> LCWD) on /TR/, I don't think the process should prohibit it.

The process *encourages* it.

> Certainly not… but we shouldn't need to "publish" anything (i.e., go  
> through the publication cycle). The latest and greatest ED should just  
> be there on /TR/ mirroring what is on Mercurial or CVS.

No, I oppose that because I find it unhelpful. If it was trivial to update  
what *is* on /TR/, heartbeat drafts could be produced every few weeks,  
with more stability than "random stuff we added" while still being  
current, and noting issues.

To take an historical example (from a time last century when we were  
inventing things equivalent to CR, implementation reports and Patent  
Policy because they didn't exist).

The Authoring Tool Accessibility Guidelines 1.0 was published about every  
4-6 weeks on TR. This wasn't a very painful process. Changes since the  
last version would be agreed by the working group. There was a working  
group draft, published to the working group's public pages, following more  
or less every weekly teleconference, and adopting the changes agreed at  
that telecon. There was an archive page updated, minutes added to another  
page (pre RRSAgent and Zakim they had been written manually in HTML - and  
the format influenced what would become scribe.pl's output). There was no  
pubrules checker, just validity, linkcheck, and a few manual processes  
(pubrules checker made life better by automating a few of these).

All this was about the same level of work as a current common prcesses  
using e.g. anolis to generate and maintain documents. All of it was done  
in public, according to the old process. All of it was done by me, by  
hand, until I was forced to use the CSS spec processor tools in order to  
fit with the workflow of a colleague. Which was very nice and  
technological and all, but not really an improvement in efficiency.

I don't see how simply putting some unstable "editor's latest  
saturday-night-brainwave" on TR is an improvement, let alone one worth the  
effort of discussing and implementing. I agree that long-outdated TR  
drafts are a problem. I strongly suspect the answer lies more in  
publishing to TR more often.

Perhaps streamlining the mechanics of that process somewhat would make  
people less reluctant to do so. I also note that Working Groups seem to  
put a lot of unnecessary bureaucracy into the process of determining what  
is a heartbeat draft - this is not a question of "W3C Process", but of  
best practices in implementing it.

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 21 March 2012 13:49:39 UTC