Re: Some thoughts on a new publication approach

On Monday, October 21, 2013 at 3:26 PM, Robin Berjon wrote:

> 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.

Yes!   
>  
> 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.

Yes! We do this already in SysApps.   
>  
> 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.

Fine.   
> 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.

Exactly.   
>  
> 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.

Fine.   
> 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?

The bit missing here is that we need to treat each step in the publication process as a "phase". During certain phases (e.g., LC), editors are not allowed to do certain things that would violate the PP. This could be controlled by only giving Editors the ability to pull from repos - all changes come in the form of Pull Requests and must then be checked by the team contact or chair as integrators. This stops the "but what if they sneak something in" nonsense that requires the snapshot model.

Received on Monday, 21 October 2013 16:10:32 UTC