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