Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 6:59 PM, Gregory Maxwell 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/fog000249.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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton wrote: > On 27 June 2010 21:07, Rob Lanphier wrote: > >On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton > 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for June 21, 2010 - June 28, 2010 Status changes this week Bugs NEW : 121 Bugs ASSIGNED : 6 Bugs REOPENED : 17 Bugs RESOLVED : 81 Total bugs still open: 4580 Resolutions for the week: Bugs marked FIXED : 42 Bugs marked REMIND : 0 Bugs marked INVALID: 9 Bugs marked DUPLICATE : 9 Bugs marked WONTFIX: 11 Bugs marked WORKSFORME : 8 Bugs marked LATER : 3 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component UsabilityInitiative 10 Site requests 7 LiquidThreads 6 Vector Skin 5 Page rendering 3 New Bugs Per Product MediaWiki 22 Wikimedia 10 MediaWiki extensions29 Wikipedia Mobile2 Top 5 Bug Resolvers conrad.irwin [AT] gmail.com 11 agarrett [AT] wikimedia.org 9 roan.kattouw [AT] gmail.com 6 sam [AT] reedyboy.net 5 hartman [AT] videolan.org 4 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 9:59 PM, Gregory Maxwell 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 6:04 PM, Rob Lanphier wrote: > On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell wrote: > >> On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier 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
[Wikitech-l] Self-determination of language versions in questions of skin?
Hello, I'm a member of the German language Wikipedia community and have a question that no-one could give me a definite answer to so far. I hope someone here can answer it, or point me to where I should go to get a definite answer. The question is, what level of self-determination do the 260 language versions of Wikipedia have as to the design of their user interfaces (skins)? Can individual wikis choose independently modifications of their skins, and which of the available skins to use as the default for unregistered users, or is this controlled centrally by the Foundation? For backgrund, this question arose after the German language Wikipedia (de.wikipedia.org) was switched from Monobook to Vector as the default skin on the 10th of June 2010, resulting in considerable criticism from the community. On the more sober side of the debate, it was asked whether it would be theoretically possible to return to Monobook as the default skin, at least for some time until the biggest known issues with Vector have been fixed. Under the theoretical scenario that a majority voted for a return to Monobook as the default skin, would it be possible at all to switch it back? Or would the Foundation not permit that? The question seems to be a very fundamental one and I would also appreciate insights into the big picture. How independent are the language versions? To what degree can they govern themselves and to what degree are they bound by decisions made centrally by the Foundation? Thanks, Martin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On 27 June 2010 23:16, Rob Lanphier 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 1:12 PM, Thomas Dalton wrote: > On 27 June 2010 21:07, Rob Lanphier 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 12:12 PM, Gregory Maxwell wrote: > On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On 27 June 2010 21:07, Rob Lanphier 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 12:06 PM, Thomas Dalton wrote:
> On 27 June 2010 19:48, Rob Lanphier 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Broken validation statistics
On 27 June 2010 20:34, Gregory Maxwell wrote: > Reviewing the logs I am unable to find even a single article with a > wait anywhere near that. > > Can you find one? I'm not sure which logs to review. The "Advanced Review Log" doesn't distinguish between edits by new registered users and edits by anons, and only the latter are included in the statistics (why is that, by the way?). There also isn't an easy way to see how long it took to review (you have to calculate it manually for every row). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Broken validation statistics
On Sun, Jun 27, 2010 at 3:24 PM, Thomas Dalton wrote: > What's broken about it? It seems very odd to me that the mean is an > order of magnitude greater than the 95th percentile, but otherwise it > all looks fine. I suspect there are a few invalid data points messing > with the mean - perhaps pending changes is being turned off on > articles while there are unreviewed edits and they are counting as > being unreviewed for ages? (Or perhaps only if PC is turned back on > again for that article and they are eventually reviewed days after > being made.) > > If that is the problem, then I would suggest disallowing turning off > PC on an article with revisions still pending. Alternatively, turning > off PC could automatically approve any pending changes. Reviewing the logs I am unable to find even a single article with a wait anywhere near that. Can you find one? By day two or so it was showing an average of several days during some hours. Some people speculated that in cases where no edits had been made since PC was activated it was simply taking the time between the prior two versions or something like that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Broken validation statistics
What's broken about it? It seems very odd to me that the mean is an order of magnitude greater than the 95th percentile, but otherwise it all looks fine. I suspect there are a few invalid data points messing with the mean - perhaps pending changes is being turned off on articles while there are unreviewed edits and they are counting as being unreviewed for ages? (Or perhaps only if PC is turned back on again for that article and they are eventually reviewed days after being made.) If that is the problem, then I would suggest disallowing turning off PC on an article with revisions still pending. Alternatively, turning off PC could automatically approve any pending changes. On 27 June 2010 20:19, Gregory Maxwell wrote: > Is anyone working on fixing the broken output from > http://en.wikipedia.org/wiki/Special:ValidationStatistics ? > > I brought this up on IRC a week-ish ago and there was some speculation > as to the cause but it wasn't clear to me if anyone was working on > fixing it. > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Broken validation statistics
Is anyone working on fixing the broken output from http://en.wikipedia.org/wiki/Special:ValidationStatistics ? I brought this up on IRC a week-ish ago and there was some speculation as to the cause but it wasn't clear to me if anyone was working on fixing it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On 27 June 2010 19:48, Rob Lanphier 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 2:48 PM, Rob Lanphier 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] "Reject" button for Pending Changes
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
