On Sun, Jun 27, 2010 at 6:04 PM, Rob Lanphier <[email protected]> wrote: > On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell <[email protected]>wrote: > >> On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
