- From: Robin Berjon <robin@w3.org>
- Date: Tue, 29 Oct 2013 16:00:38 +0100
- 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