Hi everyone,
There is mounting demand for a "reject" button (or "decline") in several conversations about Pending Changes: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback#Unapprove_bu...
...along with a lot of confusion about "unaccept": http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_issues#... http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#Unaccept_on_Erne... http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#I_don.27t_get_it http://en.wikipedia.org/wiki/Help_talk:Pending_changes#Can.27t_get_it_to_wor...
The solution we've proposed is a "reject" button which would replace the "unaccept" button in most contexts: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision
However, there are some misgivings about implementing such a feature: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Rev...
In short, the worry is that a convenient "reject" button will cause editors to introduce changes they never intended to introduce. The way that we need to implement "reject" is to undo all edits between the rejected revision and the latest accepted revision. Before we plow ahead and implement this, we'd like to get some developer feedback on this.
For example, let's say that there are three pending revisions in the queue. That means there is the latest accepted revision (we'll call "A1"), and three pending revisions ("P1", "P2", and "P3"). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions.
The specification says that when viewing the diff between A1 and P3, the "reject" button is enabled. A more conservative school of thought says that the "reject" button shouldn't be enabled, because its possible that P1 was a valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the "reject" button will result in the same confusion we're already seeing today.
Thoughts?
Rob
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier robla@wikimedia.org wrote:
For example, let's say that there are three pending revisions in the queue. That means there is the latest accepted revision (we'll call "A1"), and three pending revisions ("P1", "P2", and "P3"). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions.
The specification says that when viewing the diff between A1 and P3, the "reject" button is enabled. A more conservative school of thought says that the "reject" button shouldn't be enabled, because its possible that P1 was a valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the "reject" button will result in the same confusion we're already seeing today.
Why don't you have the "reject" button (whatever it's called) show you each diff individually, so you get the chance to accept or reject them one by one? (Disclaimer: I haven't really looked at Pending Changes at all, so I might be talking nonsense.)
On 27 June 2010 19:48, Rob Lanphier robla@wikimedia.org wrote:
For example, let's say that there are three pending revisions in the queue. That means there is the latest accepted revision (we'll call "A1"), and three pending revisions ("P1", "P2", and "P3"). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions.
The specification says that when viewing the diff between A1 and P3, the "reject" button is enabled. A more conservative school of thought says that the "reject" button shouldn't be enabled, because its possible that P1 was a valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the "reject" button will result in the same confusion we're already seeing today.
The guidance for reviewing multiple edits (http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_f...) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away. However, I would suggest a "rollback" or "undo" button (which does that same as those buttons always do) rather than a "reject" button - don't introduce a new term when it does the same thing as an existing feature with its own name.
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier robla@wikimedia.org wrote: [snip]
look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the "reject" button will
Do you have a any data to support your rarity claim beyond the fact that reviews spanning multiple revisions are themselves rare to the point of non-existence on enwp currently?
Why is rarity a good criteria to increase the incidence of blind reversion of good edits? An informal argument here is that many contributors will tell you that if their initial honest contributions to Wikipedia had been instantly reverted they would not have continued editing— and so extreme caution should be taken in encouraging blind reversion unless it is urgently necessary.
Current review delays on enwp are very short what is the urgency for requiring a mechanism for _faster_ reversions of edits which are not being displayed to the general public?
Could the goal of reducing the unapprove button be equally resolved by removing the unapprove button from the review screen where it is confusingly juxtaposed with the approve button and instead display it on the edit history next to the text indicating which revisions have the reviewed state?
On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
On 27 June 2010 19:48, Rob Lanphier robla@wikimedia.org wrote:
For example, let's say that there are three pending revisions in the
queue.
That means there is the latest accepted revision (we'll call "A1"), and three pending revisions ("P1", "P2", and "P3"). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions.
The specification says that when viewing the diff between A1 and P3, the "reject" button is enabled. A more conservative school of thought says
that
the "reject" button shouldn't be enabled, because its possible that P1
was a
valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare,
and
the diff remains in the edit history to be rescued, and can be reapplied
if
need be. A competing problem is that disabling the "reject" button will result in the same confusion we're already seeing today.
The guidance for reviewing multiple edits ( http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_f... ) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away.
I think it actually gets worse. What should the reject button do in the case that the reviewer is looking at A1 and P1?
However, I
would suggest a "rollback" or "undo" button (which does that same as those buttons always do) rather than a "reject" button - don't introduce a new term when it does the same thing as an existing feature with its own name.
The confirmation page that is shown when the user hits "reject" tells the reviewer that they are about to "undo" one or more revisions. We're not wedded to the word "reject", but it's pretty clear that reviewers are going to look around to the counterpart to "accept". There's already an "undo" link on these pages, but people still feel that some sort of "reject" or "decline" is necessary.
Rob
On 27 June 2010 21:07, Rob Lanphier robla@wikimedia.org wrote:
The guidance for reviewing multiple edits ( http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_f... ) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away.
I think it actually gets worse. What should the reject button do in the case that the reviewer is looking at A1 and P1?
It would function as "undo". In the event that the edit cannot be undone, it fails gracefully. The software can't be expected to do everything successfully.
However, I
would suggest a "rollback" or "undo" button (which does that same as those buttons always do) rather than a "reject" button - don't introduce a new term when it does the same thing as an existing feature with its own name.
The confirmation page that is shown when the user hits "reject" tells the reviewer that they are about to "undo" one or more revisions. We're not wedded to the word "reject", but it's pretty clear that reviewers are going to look around to the counterpart to "accept". There's already an "undo" link on these pages, but people still feel that some sort of "reject" or "decline" is necessary.
I think if a button labelled "rollback" or "undo" were right next to the "accept" button they would recognise it as the counterpart to "accept". If I saw a "reject" button I wouldn't know exactly what it's going to do. If I saw a "rollback" or "undo" button, I'd know exactly what to expect when I clicked it since I've been clicking button (well, links) with those names for years.
On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell gmaxwell@gmail.comwrote:
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier robla@wikimedia.org wrote: [snip]
look at the revision history. However, this should be reasonably rare,
and
the diff remains in the edit history to be rescued, and can be reapplied
if
need be. A competing problem is that disabling the "reject" button will
Do you have a any data to support your rarity claim beyond the fact that reviews spanning multiple revisions are themselves rare to the point of non-existence on enwp currently?
I don't have that data. However, let me put it another way. We have a known problem (many people confused/frustrated by the lack of an enabled "reject" button), which we're weighing against a theoretical and currently unquantified problem (the possibility that an intermediate pending revision should be accepted before a later pending revision is rejected). I don't think it's smart for us to needlessly disable this button in the absence of evidence showing that it should be disabled.
Why is rarity a good criteria to increase the incidence of blind
reversion of good edits? An informal argument here is that many contributors will tell you that if their initial honest contributions to Wikipedia had been instantly reverted they would not have continued editing— and so extreme caution should be taken in encouraging blind reversion unless it is urgently necessary.
The current spec doesn't call for blind reversion. It has a confirmation screen that lists the revisions being reverted.
Current review delays on enwp are very short what is the urgency for
requiring a mechanism for _faster_ reversions of edits which are not being displayed to the general public?
Could the goal of reducing the unapprove button be equally resolved by removing the unapprove button from the review screen where it is confusingly juxtaposed with the approve button and instead display it on the edit history next to the text indicating which revisions have the reviewed state?
I think making "accept"/"unaccept" into a single toggling button is the right thing to do. Furthermore, because of the potentially confusing result of "unaccepting" something, I'd even recommend only making it possible when looking at the diff between the penultimate accepted revision and the latest accepted revision, which is documented in this request: http://www.pivotaltracker.com/story/show/3949176
However, I don't think that removes the need for a "reject" button, for reasons I outline here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Rev...
Rob
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
On 27 June 2010 21:07, Rob Lanphier robla@wikimedia.org wrote:
The guidance for reviewing multiple edits (
http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_f...
) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away.
I think it actually gets worse. What should the reject button do in the case that the reviewer is looking at A1 and P1?
It would function as "undo". In the event that the edit cannot be undone, it fails gracefully. The software can't be expected to do everything successfully.
Hi Thomas,
If you're willing to write up an alternative proposal for how this should work, we'll take a look at it. It stands the best chance of getting implemented if you figure out a way of incremental implementation, since it sounds like you're a proponent of a "go back to the drawing board" approach to this.
I've put a placeholder for "Alternative B" here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision
Anyone else who wants to take a stab at a specification should also feel free to do so (as C, D, etc). I think it's going to be a lot easier to close this issue if we can discuss the merits of several complete competing proposals than it will be if we're just debating whether to move forward with a single proposal.
Rob
On 27 June 2010 23:16, Rob Lanphier robla@robla.net wrote:
If you're willing to write up an alternative proposal for how this should work, we'll take a look at it. It stands the best chance of getting implemented if you figure out a way of incremental implementation, since it sounds like you're a proponent of a "go back to the drawing board" approach to this.
I've put a placeholder for "Alternative B" here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision
Done. Please ask if anything isn't clear.
On Sun, Jun 27, 2010 at 6:04 PM, Rob Lanphier robla@robla.net wrote:
On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell gmaxwell@gmail.comwrote:
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier robla@wikimedia.org wrote: [snip]
look at the revision history. However, this should be reasonably rare,
and
the diff remains in the edit history to be rescued, and can be reapplied
if
need be. A competing problem is that disabling the "reject" button will
Do you have a any data to support your rarity claim beyond the fact that reviews spanning multiple revisions are themselves rare to the point of non-existence on enwp currently?
I don't have that data. However, let me put it another way. We have a known problem (many people confused/frustrated by the lack of an enabled "reject" button), which we're weighing against a theoretical and currently unquantified problem (the possibility that an intermediate pending revision should be accepted before a later pending revision is rejected). I don't think it's smart for us to needlessly disable this button in the absence of evidence showing that it should be disabled.
I think you've failed to actually demonstrate a "known problem" here.
The juxtaposition of the approve and unapproved can be confusing, I agree. In most of the discussions where it has come up people appear to have left satisfied once it was explained to them that 'rejecting' wasn't a tool limited to reviewers— that everyone can do it using the same tools that they've always used.
Or, in other words, short comings in the current interface design have made it difficult for someone to figure out what actions are available to them, and not that they actually have any need for more potent tools to remove contributions from the site.
I think it's important to note that reverting revisions is a regular editorial task that we've always had which pending changes has almost no interaction with. If there is a need for a one click multi-contributor multi-contribution bulk revert why has it not previously been implemented?
Moreover, you've selectively linked one of several discussions — when in others it was made quite clear that many people (myself included, of course) consider a super-rollback "undo everything pending" button to be highly undesirable.
Again— I must ask where there is evidence that we are in need of tools to increase the _speed_ of reversion actions on pages with pending changes at the expense of the quality of those determinations? Feel free to point out if you don't actually believe a bulk revert button would be such a trade-off.
The current spec doesn't call for blind reversion. It has a confirmation screen that lists the revisions being reverted.
I don't think it's meaningful to say that a revert wasn't blind simply because the reverting user was exposed to a list of user names, edit summaries, and timestamps (particularly without immediate access to the diffs).
A blind revert is a revert which is made without evaluating the content of the change. Such results are possible through the rollback button, for example, but they rollback is limited to the contiguous edits by a single contributor. Blind reverts can also be done by selecting an old version and saving it, but that takes several steps and the software cautions you about doing it.
The removal of rollback privileges due to excessively sloppy use is a somewhat frequent event and the proposed change to the software is even more risky.
These bulk tools also remove the ability to provide an individual explanation for the removal of each of the independent changes.
I think making "accept"/"unaccept" into a single toggling button is the right thing to do.
Because of page load times by the time I get the review screen up someone has often approved the revision. If I am not maximally attentive will I now accidentally unapprove a fine version of the page simply because the button I normally click has reversed its meaning?
This doesn't seem especially friendly to me. Or, "A user interface is well-designed when the program behaves exactly how the user thought it would", and this won't.
Furthermore, because of the potentially confusing result of "unaccepting" something, I'd even recommend only making it possible when looking at the diff between the penultimate accepted revision and the latest accepted revision, which is documented in this request: http://www.pivotaltracker.com/story/show/3949176
That sounds good to me. Though the review screen which you'd visit with the intent of reviewing a change fits that description and if you change the meaning of a commonly used button it will result in errors of the form I just raised.
However, I don't think that removes the need for a "reject" button, for reasons I outline here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Rev...
At the DC meetup yesterday someone used the explanation "Pending changes is an approval of a particular _state_ of an article, not an approval of _changes_ to an article." Unfortunately, we've loaded up the UI with "_changes_" style terminology, and the changes explanation is attractive until you realize that it's not really possible to have a system which approves _changes_ and also maintains a single merge-free linear editing history.
So my take on this is that people are confused because we've obfuscated the software in the name of clarity, and one part of the confusion is that the system is a review system for single changes.
One result of this confusion is that people believe there needs to be a REJECT button and that one can even be consistently and meaningfully defined for all cases but that isn't the only result of the confusion. For example, many people have been thoroughly confused by the behaviour governing subsequent edits by a reviewer, the (lack of) need to approve ever contributing edit that went into a good final state, and unawareness of the risk of specifically approving bad intermediate states just because the final state is good. (This last risk results in the problem that unapproving a version may cause a bad version to be displayed, and the above proposed increase in UI complexity by only allowing the unapproval from particular diff screeens)
You would propose to change the operation of the software to align better with the user's misunderstandings— that a special reviewer-reject is _needed_ above, beyond, and distinct from the regular editing tools— I'd rather we try to make the software less confusing so that it's obvious that the regular tools do what people need and want.
On Sun, Jun 27, 2010 at 9:59 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Moreover, you've selectively linked one of several discussions — when in others it was made quite clear that many people (myself included, of course) consider a super-rollback "undo everything pending" button to be highly undesirable.
Someone asked me off list to provide an example, so here is one:
http://en.wikipedia.org/wiki/Wikipedia_talk:Reviewing#What_gets_flagged_and_...
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
On 27 June 2010 21:07, Rob Lanphier robla@wikimedia.org wrote:
On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton thomas.dalton@gmail.com
wrote:
I suggest eliminating the option of review multiple
edits with a single click, unless they are all by the same user. [...]
Once you've done that, the issue you raise goes away.
I think it actually gets worse. What should the reject button do in the case that the reviewer is looking at A1 and P1?
It would function as "undo". In the event that the edit cannot be undone, it fails gracefully. The software can't be expected to do everything successfully.
I had forgotten that "undo" might possibly actually do something useful in this context. That said, let's recap what has happened so far.
You start with accepted revision A1, and have pending revisions P1, P2, and P3. Once the user rejects P1, lets assume that that creates a new pending revision P4 that is the result of that undo. Now what? If they then review the diff between P1 and P2, they might mistakingly accept P2, even though it still contains the delta between A1 and P1. We could ask them to review the diff between P1 and P4, but that's now an aggregate of the P1P2 delta and the P2P3 delta, sans the A1P1 delta.
I just don't think there's a clean way to reject an intermediate pending revision. Accepting? Sure, wonderful, that will work well. There's a reasonably strong argument for encouraging acceptance of intermediate revisions as part of the review process (so long as it always involves comparison to the latest accepted revision). But encouraging undo on intermediate revisions leaves things in a really weird place.
Rob
On Sun, Jun 27, 2010 at 6:59 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Again— I must ask where there is evidence that we are in need of tools to increase the _speed_ of reversion actions on pages with pending changes at the expense of the quality of those determinations? Feel free to point out if you don't actually believe a bulk revert button would be such a trade-off.
I'm willing to consider a more conservative implementation. How about the newly added alternative C? http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision...
I think making "accept"/"unaccept" into a single toggling button is the right thing to do.
Because of page load times by the time I get the review screen up someone has often approved the revision. If I am not maximally attentive will I now accidentally unapprove a fine version of the page simply because the button I normally click has reversed its meaning?
"Unaccept" seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting "unaccept".
Furthermore, because of the potentially confusing result of "unaccepting" something, I'd even recommend only making it possible
when
looking at the diff between the penultimate accepted revision and the
latest
accepted revision, which is documented in this request: http://www.pivotaltracker.com/story/show/3949176
That sounds good to me. Though the review screen which you'd visit with the intent of reviewing a change fits that description and if you change the meaning of a commonly used button it will result in errors of the form I just raised.
With a confirmation screen, I think we could actually leave it enabled in most contexts, since the reviewer would need to look at the diff before confirming.
You would propose to change the operation of the software to align
better with the user's misunderstandings— that a special reviewer-reject is _needed_ above, beyond, and distinct from the regular editing tools— I'd rather we try to make the software less confusing so that it's obvious that the regular tools do what people need and want.
I think we probably need to agree to disagree on this point, assuming you read the Spolsky article and still come away with the same conclusion. For anyone else who is interested why I feel the way I do, this is the article that I'm referring to ("User Interface Design For Programmers" by Joel Spolsky): http://www.joelonsoftware.com/uibook/fog0000000249.html
...which I referenced in my longish reply here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Rev...
Rob
On Sun, Jun 27, 2010 at 11:11 PM, Rob Lanphier robla@wikimedia.org wrote:
I just don't think there's a clean way to reject an intermediate pending revision. Accepting? Sure, wonderful, that will work well. There's a reasonably strong argument for encouraging acceptance of intermediate revisions as part of the review process (so long as it always involves comparison to the latest accepted revision). But encouraging undo on intermediate revisions leaves things in a really weird place.
And that's in the cases when the undo is even possible. If there are three unreviewed edits P1, P2, P3 in order, it may be impossible to undo P2 without simply reverting to P1, which loses the content of P3. That is a situation we do not want to encourage.
I view all this as a strong reason not to have an "reject" button.
- Carl
On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier robla@wikimedia.org wrote:
"Unaccept" seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting "unaccept".
I had the impression that "unaccept" does not add a new revision to the page, it simply removes the db entry that the revision in question was "accepted". Is that wrong?
There are two reasons why that ''should'' be the behavior:
(1) If I go back and "unaccept" a revision from two days in the past that was mistakenly accepted, I should not have to edit the page again to restore the previous content.
(2) "Accept" does not add a revision to the page, and "unaccept" should only undo what "accept" does. That is, the sequences "accept => unaccept " and "unaccept => accept" should be able to be iterated as many times as desired, leaving everything in exactly the same state apart from log entries.
- Carl
On 28 June 2010 12:19, Carl (CBM) cbm.wikipedia@gmail.com wrote:
On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier robla@wikimedia.org wrote:
"Unaccept" seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting "unaccept".
I had the impression that "unaccept" does not add a new revision to the page, it simply removes the db entry that the revision in question was "accepted". Is that wrong?
That's correct, but from the point of view of someone only viewing accepted versions it will be like a revert.
On 28 June 2010 04:11, Rob Lanphier robla@wikimedia.org wrote:
I had forgotten that "undo" might possibly actually do something useful in this context. That said, let's recap what has happened so far.
You start with accepted revision A1, and have pending revisions P1, P2, and P3. Once the user rejects P1, lets assume that that creates a new pending revision P4 that is the result of that undo. Now what? If they then review the diff between P1 and P2, they might mistakingly accept P2, even though it still contains the delta between A1 and P1. We could ask them to review the diff between P1 and P4, but that's now an aggregate of the P1P2 delta and the P2P3 delta, sans the A1P1 delta.
I just don't think there's a clean way to reject an intermediate pending revision. Accepting? Sure, wonderful, that will work well. There's a reasonably strong argument for encouraging acceptance of intermediate revisions as part of the review process (so long as it always involves comparison to the latest accepted revision). But encouraging undo on intermediate revisions leaves things in a really weird place.
Ah... you're right. I hadn't thought things through carefully enough. Ok, how about alternative D?
D:
1) Display diff between A1 and P1. 2) P1 is rejected. Nothing happens to the database at this point, the rejection of P1 is just remembered somewhere. 3) Display a diff between A1 and "P2 minus A1P1 delta" (that can be created temporarily using the undo feature) 4a) If that diff is rejected, display a diff between A1 and "P3 minus A1P2 delta" (or equivalently, "P3 minus A1P1 delta minus P1P2 delta"). 4b) If that diff (in 3) is accepted, display a diff between "P2 minus A1P1 delta" and "P3 minus A1P1 delta". 5) Continue in what I hope is the obvious fashion, because I'm thoroughly confused! 6) Create a revision equal to that latest accepted pseudo-revision and mark it as accepted.
This will be a mess to program (and no, I'm not volunteering!), but it should be very intuitive for the reviewer. If at any time the undo feature can't create one of the pseudo-revisions (the ones in quotes), you just fail gracefully.
What do you think?
PS The aspirin is in the second drawer on the left!
On Mon, Jun 28, 2010 at 8:13 AM, Thomas Dalton thomas.dalton@gmail.comwrote:
Ok, how about alternative D?
D:
- Display diff between A1 and P1.
- P1 is rejected. Nothing happens to the database at this point, the
rejection of P1 is just remembered somewhere. 3) Display a diff between A1 and "P2 minus A1P1 delta" (that can be created temporarily using the undo feature) 4a) If that diff is rejected, display a diff between A1 and "P3 minus A1P2 delta" (or equivalently, "P3 minus A1P1 delta minus P1P2 delta"). 4b) If that diff (in 3) is accepted, display a diff between "P2 minus A1P1 delta" and "P3 minus A1P1 delta". 5) Continue in what I hope is the obvious fashion, because I'm thoroughly confused! 6) Create a revision equal to that latest accepted pseudo-revision and mark it as accepted.
This will be a mess to program (and no, I'm not volunteering!), but it should be very intuitive for the reviewer. If at any time the undo feature can't create one of the pseudo-revisions (the ones in quotes), you just fail gracefully.
What do you think?
Hi Thomas,
I think this may be the way we could have done this if we were designing the feature from scratch (and it may be something to consider for a major rewrite, should we embark on that), but given the scope of changes we should probably make at this point, I'm guessing we'll probably need to table this particular suggestion.
In general, I think you're touching on what is (what I think) is the really common desire here, which is that if people go through the trouble of reviewing a diff, and it's bad, they want some way of flagging a delta as bad, rather than implicitly rejecting it through jumping through some hoops. However, as Gregory would point out, that's just not the way the software is currently designed. I think we should still figure out the best way(s) to accommodate this desire, but I hesitate to go so far as adding a new flag in the database for rejected revisions.
It wouldn't hurt to document this as an alternative for a possible redesign, though.
PS The aspirin is in the second drawer on the left!
Thanks, I'll need it ;-)
Rob
wikitech-l@lists.wikimedia.org