"Reject" button for Pending Changes

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

"Reject" button for Pending Changes

Rob Lanphier-4
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_button

...along with a lot of confusion about "unaccept":
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_issues#Unable_to_click_unaccept
http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#Unaccept_on_Ernest_Hemingway
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_work

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_Revision

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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Aryeh Gregor
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier <[hidden email]> 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.)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Thomas Dalton
In reply to this post by Rob Lanphier-4
On 27 June 2010 19:48, Rob Lanphier <[hidden email]> 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_for_reviewing_multiple_edits)
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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Gregory Maxwell
In reply to this post by Rob Lanphier-4
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier <[hidden email]> 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?

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier-4
In reply to this post by Thomas Dalton
On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton <[hidden email]>wrote:

> On 27 June 2010 19:48, Rob Lanphier <[hidden email]> 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_for_reviewing_multiple_edits
> )
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Thomas Dalton
On 27 June 2010 21:07, Rob Lanphier <[hidden email]> wrote:

>> The guidance for reviewing multiple edits
>> (
>> http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_for_reviewing_multiple_edits
>> )
>> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier
In reply to this post by Gregory Maxwell
On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell <[hidden email]>wrote:

> On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier <[hidden email]> 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_Revision

Rob
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier
In reply to this post by Thomas Dalton
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton <[hidden email]>wrote:

> On 27 June 2010 21:07, Rob Lanphier <[hidden email]> wrote:
> >> The guidance for reviewing multiple edits
> >> (
> >>
> http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_for_reviewing_multiple_edits
> >> )
> >> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Thomas Dalton
On 27 June 2010 23:16, Rob Lanphier <[hidden email]> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Gregory Maxwell
In reply to this post by Rob Lanphier
On Sun, Jun 27, 2010 at 6:04 PM, Rob Lanphier <[hidden email]> wrote:

> On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell <[hidden email]>wrote:
>
>> On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier <[hidden email]> 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_Revision


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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Gregory Maxwell
On Sun, Jun 27, 2010 at 9:59 PM, Gregory Maxwell <[hidden email]> 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_what_does_not

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier-4
In reply to this post by Thomas Dalton
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton <[hidden email]>wrote:

> On 27 June 2010 21:07, Rob Lanphier <[hidden email]> wrote:
> >On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton <[hidden email]>
>  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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier-4
In reply to this post by Gregory Maxwell
On Sun, Jun 27, 2010 at 6:59 PM, Gregory Maxwell <[hidden email]> 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#Alternative_C



> > 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_Revision

Rob
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Carl (CBM)
In reply to this post by Rob Lanphier-4
On Sun, Jun 27, 2010 at 11:11 PM, Rob Lanphier <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Carl (CBM)
In reply to this post by Rob Lanphier-4
On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Thomas Dalton
On 28 June 2010 12:19, Carl (CBM) <[hidden email]> wrote:

> On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier <[hidden email]> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Thomas Dalton
In reply to this post by Rob Lanphier-4
On 28 June 2010 04:11, Rob Lanphier <[hidden email]> 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!

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Reject" button for Pending Changes

Rob Lanphier-4
On Mon, Jun 28, 2010 at 8:13 AM, Thomas Dalton <[hidden email]>wrote:

> 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?
>


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 mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l