On Sun, Jun 27, 2010 at 6:04 PM, Rob Lanphier <robla(a)robla.net> wrote:
On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell
<gmaxwell(a)gmail.com>wrote;wrote:
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier
<robla(a)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_Re…
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.