Wikipedia talk:Pending changes/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Community Wishlist - Pending Changes Improvement

Hi guys,

You may be interested in the Community Wishlist Partial Pending Changes item.

In short, PC is very difficult to handle on an article once multiple editors have made multiple edits - lots of reviewers who don't have time for more than a bulk yes/no leave it for another to do the breakdown. This proposal aims to help resolve that.

There's plenty of us and PC is used on increasingly many mid/high activity pages so any support and getting the word out would be appreciated.

Nosebagbear (talk) 09:47, 17 November 2018 (UTC)

Ooh, sweet! I was actually working my way up to starting something like that here, or at least posting a topic asking other reviewers to submit their own pain points, to sort of compile a collective list of widely agreed-upon issues. But it sounds like somebody beat me to it, and I am happy to be a mere contributor. I have a good-sized list, though I'm sure some are already there.

• The impossibility of reviewing changes in long articles when you, as an outsider, have no frame of reference (since the wikitext diff view is comically devoid of sufficient context, and the Visual diff view invariably times out before displaying the changes)
• The impossibility of reviewing table-data edits in articles of any length, because of the same context issues
• The impossibility of reviewing changes that consist of nothing but uncited numerical updates to statistical data, on articles that are PC-protected despite being nothing but clear WP:NOTSTATSBOOK violations anyway
• The impossibility of reviewing changes on non-article pages (project pages, mostly), where the standard editorial rules don't apply, and we (as uninvolved reviewers) have no possible frame of reference to determine what rules we should apply

  (I even brought one of those up on the Talk page, and seem to have persuaded at least one of the involved editors to abandon PC protection in favor of an automated level)

• And this isn't even getting into the really-obvious ones. Like how reviewing an article's PC queue becomes exponentially more complex and difficult as the number of edits, and especially editors, grows. Or how the hardest reviews to process properly are the ones with a dozen bad edits, but one half-good one nestled somewhere in the middle — because even though it's really easy to state exactly what you want to do, it's an absolute nightmare to execute it via the existing interface/workflow...

...Yeah, long story short I am definitely interested in that wishlist. Thanks! -- FeRDNYC (talk) 16:41, 19 November 2018 (UTC)

Indeed - there are a few things that stop PC being an efficient system but I felt listing them all risked a rather complicated proposal. Hopefully if it squeaks in they'll have an ask round for some more details.

What we really need now is some more extensive canvassing without being irksome - any bright ideas (other language wikis etc) please have at it Nosebagbear (talk) 18:03, 19 November 2018 (UTC)

@Nosebagbear: I suppose going around and visiting all of the articles in the PC review queue, just to vandalize them with pending edits containing info about the survey, in order to get the attention of other PC reviewers... that would probably be frowned upon, huh?

(...KIDDING! I'm almost definitely 100% mostly kidding. Probably.) 😇 -- FeRDNYC (talk) 10:17, 20 November 2018 (UTC)

@FeRDNYC: - see that just makes people stubborn! What you need to do is add a 2nd unhelpful edit to every pending change that's positive and a useful edit to every pending piece of vandalism. That won't irritate people at all. Obviously. Nosebagbear (talk) 18:31, 20 November 2018 (UTC)

Somehow accepted only part of review queue

So, this is confusing. My understanding was, Pending Changes review involved accepting or rejecting only the latest change in the pending queue for an article — an all-or-nothing thing. (See previous discussion, in fact.)

But it seems that, earlier today, I somehow managed to not do that at all. I appear to have reviewed and accepted only one of the three edits that were pending at the time I reviewed the article. (Aoi then came along and accepted the remaining two — much appreciated, as I was still staring at the queue in total in confusion, trying to figure out how only some of the changes I thought I'd already accepted were again listed as pending.)

You can see from the edit timestamps that all three edits were made well before I reviewed any of them. Here are the lines for my review and Aoi's review from the Advanced review log:

• 2018-11-21T19:44:46 Aoi (talk · contribs) reviewed a version of Democratic Party presidential primaries, 2020 (changes reviewed) (revision: 2018-11-21T09:17:13)
• 2018-11-21T17:01:59 FeRDNYC (talk · contribs) reviewed a version of Democratic Party presidential primaries, 2020 (changes reviewed) (revision: 2018-11-20T19:37:22)

You can also see from the article history that the first of the three originally-pending edits (by Alanmyron) is listed as accepted by me, the following two by Aoi. ...Does anyone have any ideas how I even managed to do that? Because, if accepting partial pending queues (or even just individual edits, when they're at the front of the queue) is something we can take advantage of, that could be really useful when working through large sets of pending edits. -- FeRDNYC (talk) 01:12, 22 November 2018 (UTC)

@FeRDNYC: Thanks for bringing this up -- I did not even realize that I had only accepted some of the pending edits. I'm curious to know how this happened as well; I agree that being able to accept only certain edits could be really useful when multiple edits get backed up in the queue. Aoi (青い) (talk) 01:23, 22 November 2018 (UTC)

@Aoi: Oh, no, you didn't at all -- you accepted all of the (two) changes pending at the time, a completely normal review. I'd previously reviewed the article when it had three pending changes, and somehow accepted only the first one of them. (And I have no idea how!) -- FeRDNYC (talk) 02:43, 22 November 2018 (UTC)

My (North8000) 12/14/18 edit and reversion of it

Hello Nosebagbear (and others)

The original paragraph read: “Acceptance of an edit by a reviewer is not an endorsement of the correctness of the edit. It merely indicates that the edit has been checked for obvious problems as listed above.”

I changed it to: “Acceptance of an edit by a reviewer is not an endorsement of the edit. It merely indicates that the edit has been checked for obvious problems as listed above.”

With the following edit summary: “Removed qualifier to broaden the statement of what acceptance does not imply. What is not imp[lied goes far beyond just "correctness" “

You reverted with the following edit summary. “GF edit - but I would say we are endorsing one aspect at least - that it isn't vandalism (we're endorsing the reason it was protected). That is separate from endorsing the correctedness (whether factual or phrasing etc) of it.”

First, expanding on my original reasoning, I think it needs reinforcement that such acceptance is not the same as acceptance of an edit. I’ve seen many cases where a routine problematic edit was not given normal scrutiny because it had already been reviewed and accepted by somebody (but, only a “pending changes review) , where in fact it was reviewed ONLY for “obvious problems” delineated on this page. Now on to your edit summary for the reversion. First, I agree with what you said in your edit summary, (except for the implied statement that I’m discussing next) but IMO it does not support the reversion. The reason given was implying that my change removed saying “we are endorsing one aspect at least” but in fact that is clearly stated in the sentence which follows: That the acceptance "indicates that the edit has been checked for obvious problems as listed above.””

Sincerely, North8000 (talk) 20:52, 14 December 2018 (UTC)

@North8000: - Hi there. Sorry, I did read the whole edit but you're quite right that the second sentence covers that nicely. I can only blame the aftereffects of last night's Christmas social - please go ahead and redo your suggested edit. Nosebagbear (talk) 23:24, 14 December 2018 (UTC)

Cool and thanks. Sincerely, North8000 (talk) 14:33, 15 December 2018 (UTC)

Village pump idea lab discussion on merging reviewer role with others

For everyone's information, there is a discussion on merging the pending change reviewer role with other user groups at the Village pump idea lab. isaacl (talk) 16:35, 20 December 2018 (UTC)

Q: Why are some changes accepted or reverted with a single click and some have an additional page of confirmation

Apologies if this isn't the place to ask, I'll strike and move it if directed to a better one. I'm fairly new to the tool and am wondering why some changes are accepted with a single click, and sometimes there's an additional confirmation page. Thanks! Elfabet (talk) 12:31, 2 May 2019 (UTC)

Proxy IP Pending changes blocks

After the question of school blocks was recently raised at Wikipedia:Requests for adminship/HickoryOughtShirt?4, a question was asked at the idea lab Village Pump about whether instead of blocking Proxy IPs, such as at schools or libraries, if they should be subject to pending changes instead to filter out vandalism from constructive edits (Except for those owned by the Church of Scientology, per Wikipedia:Requests for arbitration/Scientology. The reasoning behind the proposal is that while blocking such IPs prevent vandalism, it also blocks out any constructive edits from such IPs, which there are, and pending changes would give them a fair chance at making constructive edits while blocking out vandalism. Any thoughts on this, and whether such a proposal would be technically feasible? Thanks for your input. DrewieStewie (talk) 16:24, 1 May 2019 (UTC)

I think it'd be a useful change. I'm concerned it might fill our backlog to a mile high, though. Or maybe monitor it for a percentage of vandalism vs. constructive edits for a while and toggle the filter via that reading? I don't know nearly enough to comment on the technological feasibility of such an implementation. Elfabet (talk) 12:03, 16 May 2019 (UTC)

Pending change review fails to recognize edit conflicts

The review process fails to recognize partial edit conflicts, and passes through a reject even if an intervening edit by another editor has taken place since the review process started. This should be fixed by altering the review pending edit process to employ standard edit conflict procedures.

In this case at Paris, two pending edits by Wkedit004 (talk · contribs) were under review by me. I examined them using the pending change review process, decided that each of the two needed to be reverted, and added an explanatory message in the pending review input box explaining the reason for each (one was about POV statements; the other was about the incorrect replacement of the word manufacture), and hit the Submit button. While I was going through the process, SiefkinDR (talk · contribs) addressed the POV issue and reverted that one (here), unbeknownst to me. (I fully agree with their revert, which was for the exact same reason that I wished to revert it.) I must have hit the submit button right afterward, as the hour and minute on our two edits are identical.

SiefkinDR's submit was accepted, as well it should have been, because it came in first. However, my submit was also accepted, and it should not have been, because my input text, which was added to the process-generated edit summary, was now inaccurate, being based on a situation in the article which no longer existed. Someone doing a diff between SiefkinDR's edit and mine (diff) would see a diff rejecting "POV statements" in the edit summary which were incorrect; they would appear to attribute a simple replacement of the word "manufacture" as "POV", which is ridiculous. No "POV statements" existed at the point of my submit; they had already been taken care of. This Submit should not have been allowed to proceed.

The review process should have rejected my submit with an edit conflict notice, and required me to reload the current version, reexamine the new situation, and rewrite the review summary if a reject was still needed based on the new evidence. The current behavior of the review process is incorrect, and should be fixed. Mathglot (talk) 18:49, 9 September 2019 (UTC)

Seems right - if it can't be fixed sooner, we need to add it to this year's attempt to fix Pending Changes into the top 10 at the wishlist. Nosebagbear (talk) 18:53, 9 September 2019 (UTC)

• This is not a problem with Pending changes, it's the default Mediawiki behavior and the extension that handles the conflict interface. Basically "edit conflict" occurs only when the software tried and could not resolve the issue itself. Imagine a page with these three lines:

  Line A

  Line B

  Line C

• Then you open the editor and remove Line A and Line C. In the intervening period before you save, another editor removes Line C. Then there's no conflict here, the software is able to handle this. What normally happens is that you, (the second editor to save) you're actually only removing Line A from your revision. That's it.
• Imagine another page with these two lines:

  Line A

  Line B

• You open the editor and remove both Line A and Line B. Before you save another editor removes also Line A and Line B. By your logic, the software should report edit conflict to you when you now try to save, but that's waste of time and (inefficiency in terms of the software). So the correct thing to do (and what you'll see if you test above examples) is the software will just silently resolve the issue. It will show you the conflict interface when it fails to resolve it. What you're proposing is, unfortunately going backward. – Ammarpad (talk) 19:54, 9 September 2019 (UTC)

You're right that the edit conflict resolution procedure resolved the problem: that can be seen in the part of the revert edit summary cleverly constructed by the process: "Rejected the first 2 text changes (by Wkedit004) that followed revision 914752473 by El C:", that is, it explicitly recognized that it was not rejecting the subsequent revert by SiefkinDR. (Let's ignore the fact for now, that it only rejected one, and not "2 text changes" in that revert; that's small potatoes.)

However, that only means that the locus of the problem is perhaps not the edit conflict resolution procedure, but there is nevertheless still a problem that needs to be addressed. Consider the following scenario:

1. Unconfirmed User:DevilTroll comes to Boris Johnson, and makes five edits, containing POV, violations of BLP, massive OR, vandalism, and finally, a typo, where they change colour to color (not necessarily in that order).
2. User:GoodIntent sees this on the queue, begins reviewing. Makes up a detailed edit summary mentioning POV, BLP, OR, and V by name. Doesn't mention the typo in the summary; it hardly seems worth it amidst all the serious problems.
3. User:FastTypist comes along moments later, edits the article outside the RPC process (possibly without clicking Undo), spots all the same things, quickly writes it up, and reverts the POV, BLP, OR, and V. In a sign of AGF towards DevilTroll (and maybe because FastTypist is a Yank), they leave "color" in place, even though the majority of the article is in UK English. They hit Submit, and DevilTroll's edits are all gone, with the exception of color, which remains.
4. User:GoodIntent completes the process moments later, hits Submit. The RPC process appends GoodIntent's comment to the RPC-autogenerated version, creating the following edit summary:

   "Rejected the first 4 text changes (by DevilTroll) that followed revision 987654321 by PreviousUser: Reverted your blatant POV, BLP violations, Original Research, and vandalism in four sections of the article. Keep it up, and you're headed for a BLOCK."

5. User:StillKindaNew comes along, notices what seems to be a long and rabid edit summary by User:GoodIntent for a change that is listed as "+1" byte from the previous version, and does a diff, to see what caused all the commotion. StillKindaNew sees from that diff, that GoodIntent merely changed the word color to colour. StillKindaNew takes GoodIntent to ANI, in their very first posting there, for misleading edit summaries, biting the newbies, lack of good faith, and casting aspersions at other users for things they never did. This seems like a slam-dunk.
6. More experienced users at ANI point out what actually happened. StillKindaNew embarrassed and put off. GoodIntent embarrassed, grumpy, and annoyed, but realizes it's not really StillKindaNew's fault; wary about doing any more pending change reviews. Experienced users grumpy about yet another pointless discussion at ANI.

The problem may not be in the edit conflict resolution procedure, as it seems to have correctly resolved the conflict, as you pointed out. However, in that case, the problem is in the RPC process, which must not allow the procedure to continue, without a review of the edit summary. Failure to do this, means blind-siding the good-faith user into making a Submission without all necessary information, and subjecting them to at the very least, misunderstanding, appearing foolish, or possibly malevolent. That cannot be the desired outcome in a case like this. Mathglot (talk) 21:12, 9 September 2019 (UTC)

Hmm, it seems your problem is with the edit summary because it referenced something (that was removed in earlier revision, unbeknown to you). Since you understand my explanation of the edit conflict, I hope you'll understand that, there's no way for the software to know the relationship between the edit summary and the content you're removing. The only solution (that would work for you) was for the software to not save your edit (and reports edit conflict, so that you can amend your edit summary?) but I already showed why this is going backward in terms of the software's capabilities. There was no "conflict." There was nothing to hinder saving your edits.

..it explicitly recognized that it was not rejecting the subsequent revert by SiefkinDR

The software was able to detect the revert by SiefkinDR because it can detect intermediate reverts, but it could not know the relationship of what he reverted and your edit summary. Only human can do that. To understand this more, imagine your edit did not have any edit summary.

However, I can agree with you that there's a problem (which may or may not necessarily be because of your case). In fact there are several problems with the Flagged review extension to the extent that its further deployment to any Wikimedia wiki is now halted. Worse more, is that even removing the extension is not easy. (I know there are many people on English Wikipedia who wish it could be disabled). And to be fair, even me, I shy away from any page where there's several unreviewed revisions plus reverts, intermediate edits and whatnot; it's a total mess there.

The issue you described above can only be remedied with WP:AGF and simple discussion now; until such time when the software can read edit summary which says "remove 3 words" and compare it with the actual edit which adds 5 words and reject the edit with the message: " Error: edit not saved, your edit summary is not accurate description of the edit". I will leave you to guess when this will happen. – Ammarpad (talk) 21:57, 9 September 2019 (UTC)

Yes, the problem is an edit summary, now invalid, due to intervening activity that I wasn't aware of. I understand your PoV entirely, because I have been involved in sw dev as well as the biz/functional side of things. Part of the problem when discussing such issues, it's that it's easy for conversations to become muddy or at cross-purposes, as one shifts hats from simply discussing functionality (it ought to work *this* way; it ought not to work *that* way), to commenting on design elements (*this module* is at fault; *that module* ought to be improved). I'm guilty of this, and probably started out all wrong at the top, saying what "PCR" "fails to do", or what "edit conflict procedure" ought to do. I shouldn't have done that.

Can we both take off the dev hats, and try a reboot? A more appropriate way to portray this, is by user experience: "I was using PCR, and had an unexpected and unfortunate result, when another user came along in the interim, and saved before I did. What can we do to improve this process?" and then see where that leads. I don't dispute anything you say above, it all sounds right to me. (As to the "guess when this will happen", my reply is: "around the time that MT is accurate.") It may well be that other procedures or constraints might improve that situation. I need to think about it.

My first thoughts, are wondering if allowing Pending review to automatically revert all contiguous edits by a user is part of the problem or not. As you say, you shy away from those. Have to think some more about this. In the meanwhile, would be interested in your thoughts, both with your UX hat, as well as your Dev hat (in highly contrasting colors and shapes, of course; I'm thinking maybe, a black, Lincoln top hat or "Freddy" (from My Fair Lady) formal gray for the UX hat, and a tricolor plush harlequin or Cthulhu hat (or take your pick) for the dev hat). Let me know. Thanks, Mathglot (talk) 23:01, 9 September 2019 (UTC)

Proposal to improve visibility of "Accepted" comment

I would like to propose a change to the pending review process or software, in order to improve the visiblity of comments entered in the summary field when accepting a pending change. Besides the fact that not exposing the comment hurts transparency, it also can lead to avoidable disruption in some cases.

When reviewing pending changes, I always leave a comment, whether I accept or revert changes. Currently, reverted changes are exposed in the History after the undo, as any revert would be. However, accepting changes merely triggers a modification to the already existing history item that is under review: where before, the history item had a brief bracketed indicator at the end of the summary line from [pending review] to [accepted by Username].

Sometimes, accepting a change is not a slam-dunk, and requires some thought, and one would like to expose the reasoning behind it. Here is one IP edit that could possibly be questionable, but which I accepted, under a rationale that is not visible at the edit summary for that change. In order to prevent WP:Review warring (oughta be a section somewhere in MOS), I felt the need to explain the acceptance, which I did in this dummy edit immediately following. However, not everyone knows how to do that, plus it's cumbersome to do so and many will avoid it for that reason.

We need to have some easy method of exposing the acceptance comment, either directly, or one click away. Currently, following an acceptance, the word accepted in the history tag of the accepted pending change is wikilinked to the revision permalink for that item. However, this is useless information as it simply duplicates the permalink underlying the timestamp for the edit, and imparts no additional information. What I'd like to see, is the following:

Proposal: for accepted revisions that have no "accept" comment, unlink the word accepted and make it plaintext. for accepted revisions that have an "accept" comment, link the word to the log that contains the comment. I know I've seen this log somewhere, but I can't find it now. That would make the tag in the history look like this: [accepted by Username ] .

Alternative UX: sometimes it's hard to see a link that's only one word long. To make it more obvious when there is or isn't an accept comment, add another token (why, reason, log, or some such) to the acceptance tag, and link that, instead. Thus, no-comment acceptances would have three words ([accepted by Username]), and commented acceptances would have four: ([accepted by Username (reason) ]). In this alternative, you could keep the duplicate wikilink underlying accept as it is now, if desired. Mathglot (talk) 20:27, 13 April 2019 (UTC)

Hm; given the section above this one, I wonder if this would be better placed at VPP? Maybe I should move it? Mathglot (talk) 21:07, 13 April 2019 (UTC)

I would just suggest skipping VPP etc. and file a task in Phabricator instead, as this seems like a common-sense proposal. You might check there to see in fact if there is a proposal there already. --Izno (talk) 21:42, 13 April 2019 (UTC)

Tracked in Phabricator
Task T232380

Good idea, thanks. Done. Mathglot (talk) 17:52, 18 September 2019 (UTC)

Confirmed editors's edits not always automatically accepted

I've noticed recently that some edits by long-term editors are showing up pending review when it should be automatically accepted (they didn't edit on top of a pending review edit). Anyone know what's going on? Schazjmd (talk) 00:38, 10 December 2019 (UTC)

@Schazjmd: phab:T233561 DannyS712 (talk) 01:32, 10 December 2019 (UTC)

Thanks, DannyS712! Schazjmd (talk) 01:42, 10 December 2019 (UTC)

I noticed a few more edits by long-term editors that I had to review ([1][2][3]). Not sure if this is within the scope of the Phabricator report mentioned above. – Lord Bolingbroke (talk) 19:52, 13 March 2020 (UTC)

Tool for pending changes

Hi, is there any tool to speed up reviewing pending changes, or do you have to do it with the backlog manually? — Yours, Bᴇʀʀᴇʟʏ • ^Talk∕_Contribs 13:02, 8 April 2020 (UTC)

Scope of pending change reviewing

There is a discussion at Reviewing Pending Changes that could use more input. PackMecEng (talk) 14:14, 10 June 2020 (UTC)

• New RFC on the subject at VPP here. PackMecEng (talk) 15:19, 13 June 2020 (UTC)

Autoconfirmed user's edit requires review

I recently edited an article where one of my edits (of 10 in a row to the same article) was marked as needing review. My edits still show up on the latest version of the page but I found it odd as it was a short edit (+7bytes) and was among a few marked as minor. Do random edits by autoconfirmed or confirmed users get marked as needing review simply to ensure that they are not vandalizing? The page is not protected. This is the edit. https://en.wikipedia.org/w/index.php?title=Lansing_School_District&oldid=985021946 Aenet1405 (talk) 19:36, 23 October 2020 (UTC)

Aidan1405, Yeah not seeing pending changed protection on that page so not sure why they would need to be reviewed. PackMecEng (talk) 19:42, 23 October 2020 (UTC)

PackMecEng, I was also a little confused and surprised because I had edited that page a few times before and after with none of those edits being marked as needing review. Aenet1405 (talk) 23:00, 23 October 2020 (UTC)

Why I am being caught up in this?

See: [4]

I have over 10,000 edits and am obviously extended-confirmed, let alone autoconfirmed. Why is the system doing this? Crossroads ^-talk- 23:25, 28 January 2021 (UTC)

@Crossroads: if someone before you has made an edit that trips the PCR, then that one has to be reviewed first to avoid being included into the list. Nosebagbear (talk) 23:51, 28 January 2021 (UTC)

Yeah, but that didn't happen in this case. There were none unaccepted before me. It just didn't accept mine for unclear reasons. Crossroads ^-talk- 04:26, 29 January 2021 (UTC)

I've also seen the behaviour that Crossroads describes on occasion; I've just accepted this edit, for example, which should have been accepted automatically. I'd previously assumed that it was a rare, tedious, and largely harmless, technical glitch. Wham2001 (talk) 12:29, 29 January 2021 (UTC)

I just accepted another[5] that should have been accepted automatically. There were no other pending edits at the time. Schazjmd (talk) 17:28, 29 January 2021 (UTC)

There's a discussion at VPT but it doesn't seem to have got much traction so far. Wham2001 (talk) 18:41, 29 January 2021 (UTC)

I also just experienced my change being marked pending [[6]], and like Crossroads, have over 10k edits. Might it be because I undid an accepted revision? Dialectric (talk) 03:04, 25 February 2021 (UTC)

Hi Dialectric, I've had this account for almost a year and have over 500 edits (I'm an Extended-confirmed user), but recently have also been finding it weird that my edits made on pending changes pages have not been automatically accepted. Early this month, I was able to make multiple edits on pending changes pages without any problem (they were automatically accepted). But now, they aren't and I have to wait for someone to review them. I'm finding this weird, because I've been able to edit extend-confirmed protected pages and semi-protected pages without any problems whatsoever. Is there a glitch or something wrong with the system (if anyone knows)? Clear Looking Glass (talk) 05:44, 25 February 2021 (UTC)

It also happened to me again after my last complaint. Crossroads ^-talk- 06:56, 25 February 2021 (UTC)

And it happened yet again today: [7] Ridiculous. Crossroads ^-talk- 06:58, 25 February 2021 (UTC)

To me too, just now. Thanatos|talk|contributions 22:36, 25 February 2021 (UTC)

Me too as well. I'm not sure what's going on, but it's pretty frustrating. Clear Looking Glass (talk) 00:08, 26 February 2021 (UTC)

Just happened to me too here. --DB1729 (talk) 01:30, 26 February 2021 (UTC)

Just happened to me again at Intersex. Annoying. Crossroads ^-talk- 06:14, 27 February 2021 (UTC)

It looks like it is quite broken, just accepted six changes like these today. I am going to try to maintain a list here:

They might be useful. ~ Ase1este_{charge-parity}^time 12:21, 1 March 2021 (UTC)

Looks like it's happening quite frequently. I wonder what's going on. I just did an edit here that had to be reviewed. Clear Looking Glass (talk) 07:28, 2 March 2021 (UTC)

I have been tagging reviews that are not autoreviewed properly with the review message. The review log is Special:AdvancedReviewLog. I tag them with the message "(bug: not auto reviewed)". From the looks of it right now, almost half of my reviews are not properly autoreviewed. ~ Ase1este_{charge-parity}^time 09:40, 2 March 2021 (UTC)

@Ase1este: For the record, happened to me there too (extended discussion leading to my edit btw): [8] I think this is the fourth time this happens to me. --Delfield (talk) 17:39, 5 March 2021 (UTC)

For those having the problem who haven't yet followed Wham2001's link above to the village pump discussion, this is a recognized bug, and has an open ticket as of March 5, 2021 - Wikipedia:Village_pump_(technical)#Pending_review_edits - but if you read the fairly messy phabricator discussion(s) linked on that village pump page, where developers are discussing the relevant mediawiki php code, it looks like no one is currently able to fix the bug and no one wants to take responsibility for the pending changes / flagged rev code, which hasn't been maintained.Dialectric (talk) 01:26, 6 March 2021 (UTC)

Greyed-out, inaccessible review buttons

Tracked in Phabricator
Task T278478

The pending changes backlog is currently building up high, which would be a surmountable problem but for the fact we can't do anything about it. The buttons to accept or reject changes are greyed out and unclickable, and the edit summary box has disappeared. I thought at first I might be being slow or something was wrong on my end, but a number of PCRs on Discord brought up the issue, and no one found anything here or at another centralized PCR-related noticeboard. Vaticidalprophet 19:42, 25 March 2021 (UTC)

Same issue. For some reason the link to the special page for tagged pending changes also appears as a redlink. — Berrely • ^Talk∕_Contribs 19:46, 25 March 2021 (UTC)

Can confirm, like Berrely. I was one of the people on Discord who also had an issue with it. Giraffer ^{(talk·contribs)} 19:49, 25 March 2021 (UTC)

A screenshot of the issue. Giraffer ^{(talk·contribs)} 19:53, 25 March 2021 (UTC)

Seems to have been fixed (at least, it's working for me right now; I just accepted a couple of edits...) Wham2001 (talk) 21:33, 25 March 2021 (UTC)

Special:ProblemChanges red link from Special:PendingChanges

Should the link be removed from Special:PendingChanges? ~ Aseleste (t, e | c, l) 13:27, 30 March 2021 (UTC)

Resolved - Looks like the link disappeared. ~ Aseleste (t, e | c, l) 08:26, 31 March 2021 (UTC)

How to only accept a single revision?

Hi. Is it possible to accept only a single edit if there is more than one pending edits, and how to do so? User3749 (talk) 09:01, 31 March 2021 (UTC)

You can only accept one or several edits which immediately follow already accepted edits.--Ymblanter (talk) 19:25, 31 March 2021 (UTC)

Ymblanter so do you mean that I have to undo the edits that I want to revert first and then accept the rest of the edit? User3749 (talk) 17:18, 4 April 2021 (UTC)

No, the result should not depend on whether you revert first and accept next or vice versa.--Ymblanter (talk) 17:42, 4 April 2021 (UTC)

Reviewing from mobile

Is it possible for us to review from a mobile device? As of now, I cannot review from mobile. Is there any way to do it? I expect an answer. Thank you. Ken Tony ^{Shall we discuss?} 08:48, 19 June 2021 (UTC)

Ken Tony, I expect an answer comes across as a little unfriendly: this isn't the tax office. In short, though, yes, you can review from a mobile by using the desktop site. There's a link at the bottom of each article which switches to the desktop view. Whether it's possible from the mobile editor I don't know, but somebody else may. Best, Wham2001 (talk) 19:54, 19 June 2021 (UTC)

Oh thanks Wham2001. Mate don't take that 'I expect an answer' sentence in an unfriendly way. I added that with a friendly mind. if you were not happy with the inclusion, I'm sorry for that. Ken Tony ^{Shall we discuss?} 19:58, 19 June 2021 (UTC)

Ken Tony, no worries – good luck getting reviewing on mobile working! Wham2001 (talk) 20:01, 19 June 2021 (UTC)

Thank you Wham2001. Ken Tony ^{Shall we discuss?} 07:39, 20 June 2021 (UTC)

Not processing

Sometimes, when I review and publish some edits from Special:PendingChanges list, the reviewing is not being processed and it will be still there in the list. Is there any way to fix it? Ken Tony ^{Shall we discuss?} 13:25, 24 June 2021 (UTC)