Extension talk:FlaggedRevs/Specifications/Reject Pending Revision

Exercise extreme caution with the "reject" button.

(portions of this conversation copied from en.wikipedia.org)

The reject button on the review page was added to the software at the last minute. ... it was previously expected that everyone would use the history to undo bad edits just like they always have, but it was realized that a reject button would make things easier in the common case. Unfortunately the reject button has some consequences which were unintended when dealing with multiple edits: See Bugzill 23987 for my request to remove the reject button when there are pending changes by multiple authors and the rationale. --Gmaxwell (talk) 03:36, 16 June 2010 (UTC)

No "reject" button has been added yet. Do you mean "unaccept"? "accept"/"unaccept" just work on the right-sided (newest) revision on diff pages. Aaron Schulz 03:44, 16 June 2010 (UTC)

Okay then I must come from an alternative universe where there was a reject button in addition to the accept which rolled back all the pending revisions. Have you ever visited this alternative universe? --Gmaxwell (talk) 03:53, 16 June 2010 (UTC)

Howie wanted such a button, but it wasn't added yet. Aaron Schulz 03:54, 16 June 2010 (UTC)

It appears that I read the specification and then later ass_u_me_d the un-approve button did exactly that. Egg on my face. Fantastic. On the plus side, my misunderstanding seems to have resulted in a good reason why it shouldn't be implemented in a particular way, so it's not all bad. Thank you for the clarification. --Gmaxwell (talk) 03:57, 16 June 2010 (UTC)

I was opposed to the button before because it encourage "approve or REVERT IT ALL" which is often bad. I'll show your bug report to Rob and Howie. I didn't even think of that specific case before. Aaron Schulz 04:00, 16 June 2010 (UTC)

Hi Gregory and Aaron, I definitely want to make sure we implement this feature right or not at all. I believe both of you are opposed to any sort of dumbed-down model, but I think it's important to understand that people are coming to this with very entrenched biases, and it's probably going to be easier to change the software than it is to change the grey matter in every user that encounters it. If you have time, I'd strongly encourage both of you to read the first two online chapters of User Interface Design For Programmers by Joel Spolsky. If you don't have time, I'll give you the most important excerpt:

"To make people happy, you have to let them feel like they are in control of their environment. To do this, you need to correctly interpret their actions. The interface needs to behave in the way they are expecting it to behave. Thus, the cardinal axiom of all user interface design: A user interface is well-designed when the program behaves exactly how the user thought it would. As Hillel said, everything else is commentary. All the other rules of good UI design are just corollaries."

Spolsky goes on to explain that it's really important to develop a "user model" in addition to a "program model", where you really try to figure out what's going on in the typical user's head, totally independent of how the software works. He then describes an example of creating an HTML editor which has to deal with the problem that people often think of images and text in a single document, even though HTML treats them as separate things:

"You have two choices. You can try to change the user model. This turns out to be remarkably hard. You could explain things in the manual, but everybody knows that users don't read manuals, and they probably shouldn't have to. You can pop up a little dialog box explaining that the image file won't be embedded, but this has two problems: it's annoying to sophisticated users, and users don't read dialog boxes, either (we'll take more about this in Chapter Six).

"So, if the mountain won't come to Muhammad ... your best choice is almost always going to be to change the program model, not the user model. Perhaps when they insert the picture, you could make a copy of the picture in a subdirectory beneath the document file, so that at least you can match the user's idea that the picture is copied (and the original can be safely deleted).

He then explains the various ways to go about the problem and encourages you to figure out how different people think about the problem. Then concludes: "The popular choice is the best user model, and it's up to you to make the program model match it."

Back to Pending Changes. The software currently works with a binary model (accepted: true or false) whereas most people I've encountered at least seem to clearly have a three-state model in mind ('accepted', 'rejected' and 'unreviewed'). It's going to take a lot of diagrams and retraining to get people off of that model. While changing the vocabulary back to "checked" or "unchecked" might help, I strongly suspect we're going to have an easier time figuring out how to accommodate the typical way of thinking about the problem.

Now, Gregory makes an extremely good point in the example in bug 23987, and generally about being very careful. I agree we're going to have to be exceptionally careful in designing this user interface. But, I also think we're going to need to figure out how to let people sensibly reject revisions, or else we're going to have an unending stream of frustrated users. We shouldn't be wedded to this proposed design, but I think we should strive to align the user interface with users' expectations.

So, I've gotta do some more thinking about this and discussing it with folks, and I hope you do the same. Let me know if you come up with ideas for how to make this work the way you think people will expect it. Thanks! -- RobLa 06:41, 16 June 2010 (UTC)

Unfortunately I didn't see this comment until today because it wasn't written until an hour after the pointer to it was added on enwp, alas.

I don't believe that you are correctly describing the current model of the software. The users approve a "state" of an article, a summation of all contributions up to some point in time, and the software displays the most recent of those approved that states to the public. This is not an especially difficult thing to understand: an implicit understanding of an an article-as-a-state has long been an absolute requirement for anyone editing Wikipedia in a non-trivial capacity, since it's something that you have to deal with any time you want to partially revert a change or cope with the very common case of an undo failure. The state model is especially obvious to anyone who has dealt with revision deletion... and I've seen no significant confusion arising from the state-model in the context of revision deletion.

Armed with the understanding of PC promoting a particular article version to a "publication visible" status the natural user model and the software model come into agreement.

In short, we're dealing with confusion we invented because of our effort to use press-friendly names which avoided talking about multiple versions of an article and instead focused on describing this as an editorial gate over single revisions. Opps.

The reason that we implemented a state-review system rather than a change review system is because true change review isn't possible without accepting that there would be a branched editing history which required human intervention to merge. Not only would bifurcated history dramatically increase the complexity of the Mediawiki revision control system, it could be reasonably expected that good changes would be frequently lost simply because no one would take the additional manual effort to merge them. It was and is a non-starter.

In the context of the above usability discussion our choice is not "user model" or "program model" it's "program model" vs "a lame imitation based on the user's misconception of a program model other than the one in use".

Above all else software should strive to be unsurprising. Even if we were to agree that users really wanted a change-approval model over a state-approval model, we can't actually have a change approval model... all we can do is approximate it poorly, and when that approximation falls down it will result in unexpected and surprising behaviours which will be impossible for the user to understand because we've encouraged a mental model which is fundamentally different from the operation of the software and incompatible with our operating goals.

Instead we should try to make the state-approving model clear, then try to conform the software to the users expectations of a state-approving model. This is clearly a viable path because our contributors must already understand a state oriented model for their other editing activities.

Cheers.--Gmaxwell 02:25, 28 June 2010 (UTC)

Include ability to give a reason

A "reject this edit" button would make it a lot more convenient to do reviewing. I think it's important to be able to give a quick one-line reason why the edit is being rejected, especially in cases other than obvious vandalism. This will help contributors know why their edits were problematic, avoid subsequent arguments on talk pages, and reduce the appearance of arbitrariness and unthinking bureaucracy. Thanks! -- Beland 15:53, 7 July 2010 (UTC)