Re: Some thoughts on a new publication approach

I have two concerns. Can you assure me that I won't have a problem?

[1] tying review comments back the the original document

The i18n WG has been lately finding it difficult to finalise the review 
of some specs because the comments were made on an editor's draft that 
was changed, sometimes to the point that the original text wwas 
completely removed, before the review comments were discussed with the 
WG. This makes it sometimes extremely difficult understand the original 
review comment.  What we need is to be able to point to a dated version 
of the document that will persist.

[2] finding old text

We have also had significant problems with features completely 
disappearing from editor's drafts in a way that made it difficult to go 
back to the original thinking. In some cases, this was because an editor 
independently decided to change things and didn't think to create a 
snapshot, and in others it was because a feature was removed in favour 
of a later version, but the text was not moved to another document.

I'm all for streamlining and simplification, but I hope that it will 
still be possible to *easily* link to dated versions of specs and that 
editors will think to produce them at regular or useful intervals.

RI

On 21/10/2013 15:26, 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.
>
> 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
>

Received on Tuesday, 29 October 2013 14:31:03 UTC