W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2013

Re: Some thoughts on a new publication approach

From: Robin Berjon <robin@w3.org>
Date: Tue, 29 Oct 2013 16:00:38 +0100
Message-ID: <526FCD96.7060309@w3.org>
To: Richard Ishida <ishida@w3.org>
CC: "spec-prod@w3.org" <spec-prod@w3.org>
On 29/10/2013 14:06 , Richard Ishida wrote:
> I have two concerns. Can you assure me that I won't have a problem?

Of course not, but we can strive for it :)

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

Yes, the use case of a whole group producing a coordinated review is 
important (it differs from an individual reviewing in that the group 
needs a draft that doesn't change while it is discussing the issues at 
hand, which is vital for Review Everything groups like I18N and WAI PF).

First, issues that you already have with EDs you will likely continue to 
have. This can only be addressed by some form of agreement with the 
editor (or simply amongst the group) of a specific revision which needs 
be reviewed (typically a given commit SHA). We can perhaps make this 
easier by making it simple for an editor to generate a "review 
snapshot", which could for instance create a stable snapshot in 
/snapshots/deadb33f-shortname/. That's something to think about.

Second, under this scheme the VCS in use should always be publicly 
available; it therefore ought to be possible for the group to obtain and 
stick to a common version to review.

Finally, if your review intervenes at LC then you will have a snapshot 
draft no matter what.

Does that help? I don't think that the new scheme introduces substantial 
new problems compared to the current situation, though it does not 
necessarily fix all the issues you may already be having.

> [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 don't think that anything changes under the proposed new regime here, 
since you are considering the case in which an editor did not make a 
snapshot anyway.

Assuming everyone moves to git (which is orthogonal to this proposal but 
desirable), then you can always find old stuff with git log -g 
-Ssome_old_feature. It's not the mostest easiest thing in the world, but 
it's also not a problem introduced by the proposal.

Note that if we transfer everyone to a new system that published 
automatically from git, then over time we can add tools on top of that, 
including the ability to always access the state of the draft at an 
older commit or searching through the log.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 29 October 2013 15:00:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 October 2013 15:00:44 UTC