Some thoughts on a new publication approach

Hi all,

I've been thinking about how to evolve our existing publication system, 
based on previous discussions here and looking at usage patterns. Here 
is a brain dump of my notes.

A long, long time ago, W3C groups were pretty much all member-only (with 
a comments list for the community). The "Heartbeat Requirement", which 
states that drafts must be published at least every three months was 
instated essentially as an Aulde School Living Standard policy. If you 
have any doubt that this is the case, I encourage you to read the 
language in section §6.2.7[0], and contrast that with discussions 
pertaining to living standards. Essentially the same reasoning applies.

As most good ideas it can turn into a meaningless automatism after the 
reasons behind it have been forgotten. I think that it should be noted 
that given the availability and broad distribution of a public editors' 
draft, the Heartbeat Requirement becomes meaningless. TR-space should 
just be editors' drafts — modulo some small differences and additions.

There are three snapshots that are required for the patent policy: FPWD, 
LC, and REC.

For familiarity, I am assuming git concepts here. But they can be 
translated to another system (though git would seem like a likely 
implementation choice).

The editors have their spec in their own versioning repository 
somewhere, wherever they want. Before FPWD (i.e. before the short name 
is assigned) that is *all* that they have. Drafts made there should use 
the "unofficial draft" style, as in 
http://www.w3.org/respec/examples/boilerplate.html?specStatus=unofficial.

When the group decides on FPWD, a short name is assigned. That short 
name under /TR/ becomes a clone of the editors' repository. This can be 
done either through cron or with hooks of various kinds. The document 
there is always up to date with the editors' copy (possibly a few 
minutes late, but nothing significant).

At FPWD, a static snapshot is also made. I say static because I'm 
assuming that systems like ReSpec that generate things on the client 
side become accepted in TR, for non-snapshots. Basically, FPWD (and the 
other snapshot points) are *not* git SHAs. History can be rewritten in 
git, which can be defended against but would be annoying. Instead they 
really are snapshot exports of the repo. This also makes generating 
static versions easier.

Every draft in TR is required to feature a pointer to its existing 
snapshots (how many there are will depend on how advanced it is).

If editors want to experiment with crazy ideas that they don't want 
published "officially" (a requirement that several have formulated) then 
they can do so in other branches in their repo. TR won't be affected.

One thing that we do lose under this scheme is the quality control from 
pubrules and friends. We can replace those by essentially making TR a CI 
system. When you push a draft it is checked, and while it is burning 
every day an email is sent to the editors, chairs, team contacts, as 
well as their next of kin, neighbours, and romantic interests until 
shame^Wpride in a job well done brings them to fix the issues.

Finally, when work on a draft stops it should be possible to mark it as 
dead so that it clearly ceases to be a potential reference point.

I'm not saying that we can switch TR over to such a system overnight, 
but the plan is both PP-friendly and strikes me as reasonably simple to 
implement.

Any thoughts?

[0] http://www.w3.org/2005/10/Process-20051014/groups#three-month-rule

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 21 October 2013 14:26:13 UTC