On Mon, Feb 28, 2022, 6:24 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
On Tue, Mar 01, 2022 at 12:17:24AM +0100, Carsten Bormann wrote:
> > A full review should not be necessary.
>
> I wish that were true...
IMO a full review is necessary,
My opinion is different. If I followed your approach, a lot of documents would have been delayed and probably abandoned. I've been involved as author/editor for a number of multi-hundred-page documents. The results were not perfect but the documents were improvements over the documents they replaced and that is enough for me.
not least to ensure that the document
remains self-consistent and that any changes applied during editing are
uniformly applied to all relevant parts of the document, not just in the
subset of places that the editor noticed.
The changes made/proposed at editing are made by someone that is not an author, is not part of the working group and should be rejected if they raise potential difficulties such as you are worried about.
I cannot see how a large set of co-ordinated changes such as you are worried about can be made by someone who is not an author.
- if a split infinitive is corrected, then the correction can be approved without a further search for similar instances. Each case is a separate judgement call.
- similarly with corrections of commas.
- if a large set of co-ordinated changes is proposed, whose nature would require a full rerevew, they should be rejected, as politely as possible. If that is not possible for some reason, the working group should have the opportunity to weigh in, but that option should be very rarely used.
This is analogous to a situation that arises when doing code review.
If you change an API's semantics,
"If it hurts when you do that, don't do that".
You should not be changing an APIs' semantics as part of a code review. Those
Semantics should be agreed to before coding starts.
you had better go around and check
all the callers of that API to see if they need adjustments, not just the
callers of the API that your test suite happens to exercise.
Sound like a nightmare to me, since such adstments might require further adjustments.
With
specifications we do not have the rigid rules of function names to identify
the places to check, and the safe thing to do is read the whole document
with any changes that were made fresh in mind.
The safe thing is to limit changes after consensus to those that do not require such extensive review by the authors who may, as someone pointed out, have lost the necessary context.
-Ben
