https://bugs.documentfoundation.org/show_bug.cgi?id=166723
--- Comment #49 from Lars Jødal <[email protected]> --- We have discussed quite a bit how the text is changed with Accept, Reject and Reinstate. Here I will instead focus on what the use of the functions are. Let's assume Alice has written a text (baseline). Bob has made a tracked change, and Alice is now looking at the text (baseline with proposed change). In which situation will Alice use each of the three functions? Accept: Alice is happy about the change, and it becomes incorporated as part of a new baseline. Case closed. Reject: Alice is not happy about the change, and she decides that it should not be part of the text. Baseline unchanged, case closed. Reinstate: Alice is not happy about the change, but instead of just deciding, she uses Reinstate to produce a text that contains tracks of the proposed change. _If_ Accept is used on the text after Reinstate, the result will correspond to Reject (unchanged baseline). But the case is not closed, and Bob has the possibility of editing the change futher (Reject, Reinstate, rewriting...). (If Bob uses Reject after Alices Reinstate, the new baseline will correspond to Accept'ing Bob's change, and if Bob uses Reinstate on top of Alice's Reinstate, Bob's proposed change is again a proposed change. The point is that the outcome has not been decided yet, even though Alice has indicated that she does not like the change.) Can we agree that this scenario describes reasonable use of Reinstate (as well as Accept and Reject)? For a short label, we are not likely to find a term that is 100% unambiguosly clear, so I suggest we settle for a less ambitious goal: A label that makes it reasonably clear to the user, what the "Reinstate" button on the screen is useful for. If we change nothing, the label remains Reinstate. As written in earlier comments, I can see the reasoning behind this label, especially for deletions, but the basis of this bug thread is that it is not clear enough. >From earlier comments, we have a number of suggestions. Selecting those that ave been seriously discussed: Suggestions from comment 30 (and before that, comment 8): * "Invert suggestion" * "Invert change" * "Flip to reversion" * "Invert" Suggestion from comment 18: * "Reject but track" Suggestion from comment 40: * "Oppose change" I think these are the ones that have been considered seriously. I take the liberty of also adding one more from comment 5 (also commented on in comment 8): * "Revert" My personal evaluation from the perspective of Alice: Alice is not happy about the change. If she were to decide alone, her action would be Reject. But she may not be in charge, or she is open for discussion (or she is just being polite), so she does not outright Reject it. Instead, she uses a function (Reinstate) after which Bob's change is no longer default choice. * This can be described as Alice opposing Bob's change. * It can also be described as Alice rejecting Bob's change, but leaving a track of his change. * From what happens to the text, I see the logic in the suggestions with the word "invert" or "flip". However, as a user in Alice's place, I will be focussing on the text (what does the text say now?) rather than on the change (what is change and what is not?). Therefore, these descriptions would not be obvious to me, even though I might reason into seing why they make logical sense. * "Revert" is somewhere in the middle. It is not my preferred term, but it makes sense both regarding meaning and regarding what logically happens. If this term is going to be shot down (again), I am not going to fight for it. In summary: If we do nothing, the term remains "Reinstate". As a user, I would prefer "Oppose change" or "Reject but track", both of which to me reasonably well describes what I/Alice wants to do with the proposed change. I doubt this will lead to full agreement. But is there a chance that we can reach something closer to agreement? Will we have to settle with a majority decision? Or do we do nothing and simply keeps "Reinstate"? -- You are receiving this mail because: You are the assignee for the bug.
