https://bugs.documentfoundation.org/show_bug.cgi?id=166723
--- Comment #36 from Lars Jødal <[email protected]> --- (In reply to Eyal Rozenberg from comment #35) > (In reply to Lars Jødal from comment #31) > > As I understand the idea behind, and use of, Reinstate, it is to be used > > when one would otherwise use Reject, but wants it to be seen, what was > > suggested. > > Then - with respect, you misunderstand. "reinstate" is not a more visible > reject. It accepts the change into the underlying document, then adds a > tracked proposal onto the modified baseline document, which, if accepted, > would revert that change. > > Another way to think about is that you have two versions of the text: > > * baseline > * proposed > > and what "reinstate" does is switch the two of them. What had previously > been just a proposition, is now the (accepted) baseline; and what had > previously been accepted into the baseline, now becomes a mere proposition. These are good terms. As there may have been misunderstanding on the way, I will spell them out a bit, to be sure that we agree on their meaning. In the example from Miklos' posting on the new feature, https://vmiklos.hu/blog/sw-redline-reinstate.html, Bob has written a text, Alice proposes some changes to it, and Bob is not happy with all of them and will used Reinstate (rather than Reject). In this context: baseline = Bob's original text = resulting text after Reject proposed = Alice's version of the text = resulting text after Accept (Hopefully we agree?) Using these terms, we have for standard Reject and Accept: Reject: The text goes from proposed to baseline (no track left of proposed text). Accept: Proposed becomes new baseline (no tracking of changes to original baseline). Now, how about Reinstate? After Reinstate, the new proposed text (= the resulting text after Accept) corresponds to the original baseline. And the new baseline text (= the resulting text after Reject) corresponds to the proposed text. So yes, the effect of Reinstate can be described as switching baseline and proposed. A drawback of this description is that it takes some logic thinking to see it. It can also be noted that it does not cover _every_ aspect of the function, as the change-tracking is not simply reverted (it is in some cases, but not in all). Please allow me to think through the "Reject but track" once more. To me, Reinstate is a tool to use instead of Reject. This makes me see it as an augmented version of Reject: Bob wants to reject Alice's proposal, but in a way that does not just let Alice's proposal disappear completely. After Reinstate, the new baseline (the resulting text if Bob or Alice afterwards uses Reject) is equal to Alice's proposal, yes. However, IMHO it is also correct to describe it as a rejection of Alice's proposal, a rejection that leaves a track of what Alice proposed. Futhermore, I think that "Reject but track" is at least as close as "reverse baseline and proposal" in describing what the user will see on the screen as tracked changes. As I now see it, it is not a matter of one being right and the other being wrong. Instead, it is a matter of viewpoint: * Reinstate = reverse what is baseline and what is proposal * Reinstate = reject the proposal, but keep tracks of it Or put a bit differently: * Reinstate: baseline and proposal are switched (in the sense of the result of Reject or Accept) * Reinstate: proposal is rejected, but a track of proposal is kept Whatever the viewpoint, the final result will depend on whether Reinstate is followed by Accept or Reject or another Reinstate. I hope I have described both viewpoints correctly and fairly? Can we agree that it is a matter of viewpoint, not a matter of one description being correct and another description being wrong/misunderstood? In comment 18, I defined "good wording" as "something that guides the typical user towards the correct understanding of what the feature does." We have at least these wordings to choose among: * "Reinstate" * "Invert suggestion" * "Invert change" * "Flip to reversion" * "Invert * "Reject but track" My own vote still goes to "Reject but track". What do others think? -- You are receiving this mail because: You are the assignee for the bug.
