Tighter rate limits on reviews

Currently the software-imposed rate limit on NPP reviews is one review per 3 seconds, applying indiscriminately to both articles and redirects. I wonder if we should impose tighter reviews on reviews of articles, and if so what it should be. This would require a phab task, and admins, bots, and account-creators are currently exempt from all rate limiting. * Pppery * _{in solidarity} 15:32, 25 July 2026 (UTC)

I'd support enforcing a lower rate applied to reviewing articles. One article per minute? Cheers, SunloungerFrog (talk) 16:07, 25 July 2026 (UTC)

It takes well under a minute for an experienced patroller to review, for instance, a species stub or a geo stub where notability is evident. While plenty of reviews take more than a minute (most of mine do) a minute would an annoying obstacle for a large number of easy-to-review new articles. Dclemens1971 (talk) 12:31, 27 July 2026 (UTC)

It would of course be possible to code a rate limit allowing larger bursts, like 10 articles per 10 minutes (Not saying this is a good idea per se, just presenting it as an option) * Pppery * _{in solidarity} 16:01, 27 July 2026 (UTC)

Tbh, I think this is another version of # NPP Guideline Proposal Regarding AfC Drafts. But then, it is very disappointing to see that we ended up thinking about enacting something that would affect every other user who do not perform problematic reviews. Vanderwaalforces (talk) 16:41, 25 July 2026 (UTC)

One of the problems about #NPP Guideline Proposal Regarding AfC Drafts, #Rapid reviewing, this looks like a problem (and perhaps this) is that it is asking NPP reviewers how to police themselves, including some who do burst reviewing. This runs too close to involved editing IMHO. It would be good to hear from many who are not NPP. Ldm1954 (talk) 17:13, 25 July 2026 (UTC)

@Pppery This is probably possible, (I will check) in the mean time, you should file a phab ticket! Sohom (talk) 18:25, 27 July 2026 (UTC)

I know it's technically possible. But I don't see a point in filing a phab ticket until we get consensus it's a good idea. * Pppery * _{in solidarity} 18:26, 27 July 2026 (UTC)

Fair, for what it's worth, I would support this as well! Sohom (talk) 18:33, 27 July 2026 (UTC)

I support it as well Ldm1954 (talk) 19:32, 27 July 2026 (UTC)

Could those of you supporting rate limits please specify what exact limit you are supporting? * Pppery * _{in solidarity} 19:54, 27 July 2026 (UTC)

To reinforce my comment above, I'm not a fan given that experienced reviewers can complete a straightforward review in well under a minute (as seen at the report linked in the section below). Any batched rate to allow bursts should allow for the pace of a skilled reviewer reviewing a straightforward article, probably 20 seconds. Dclemens1971 (talk) 18:41, 27 July 2026 (UTC)

Agreed. Apart from the ones you mentioned above, other very quick reviews include disamb pages or microstubs on politicians or professors. Something like 10 to 20 seconds isn't bad, and it's certainly better than the 3 seconds (apparently?) currently being allowed. JTtheOG (talk) 20:37, 27 July 2026 (UTC)

I would also support 10 or 20 seconds, since either of these would be an improvement on 3 seconds and would be unlikely to inconvenience any reasonably careful reviewer. Dionysodorus (talk) 13:54, 28 July 2026 (UTC)

I feel like to some extent this is something we should be expecting users with an advanced permission like NPP to be checking themselves on, a hard rate limit seems like it could cause more problems than it would solve. If anything, overly fast reviewing is an easy way to flag that someone needs to be taking more care in their reviews. Would it would be possible to set up a bot that could warn people (once) about fast reviewing if they do it too fast multiple times, or something like that? A talk page message is kind of an annoying and public way to warn people about something like that, but the core issue here is careless reviews, and I think this fix may just end up depriving us of data that can be used to spot when that issue is happening. 🌸⁠wasianpower⁠🌸 (talk • contribs) 20:06, 27 July 2026 (UTC)

Yeah, I think I lean more towards a bot than disabling the ability to do quick reviews at a software level. The bot could warn a person up to 3 times, and also post on a page monitored by NPP coordinators or admins, or something like that. Then if the person knows what they're doing and ignores the bot, so be it, that's an option. But it could also let a newer reviewer know that they are reviewing improperly and help them correct their behavior and avoid a boatload of drama and mass unreviews. –Novem Linguae (talk) 20:36, 27 July 2026 (UTC)

I'd be opposed to a software ratelimit, but I think a bot that monitors NPP review speeds would be perfect. Could also be applied to AfC reviews. – LuniZunie_(talk) 23:22, 27 July 2026 (UTC)

@LuniZunie, @Novem Linguae This would require publishing non-public (read: NDA) data though (the reviewing part is fine, but when somebody visited a page is non-public data) and I'm going to be a bit squeamish about us publishing that sort of thing publicly. What about a warning (or if we want to be more forward) similar to WP:NPPHOUR that reminds you that you are going to fast if you say review 3-4 pages in quick succession? Sohom (talk) 23:44, 27 July 2026 (UTC)

Would it be possible to do an abuse filter? Something similar to filter 249 but for NPP reviews? Could just be set to log edits. – LuniZunie_(talk) 23:46, 27 July 2026 (UTC)

You could, tho I think putting it into software is probably easier and faster than making PageTriage AbuseFilter compatible. Sohom (talk) 23:52, 27 July 2026 (UTC)

I worry that a software limit would create unexpected issues that are annoying to deal with. Such as mass undeleting of pages which would require all the pages to be rereviewed, which would be incredibly annoying to handle if the rate limit was something like a minute. – LuniZunie_(talk) 23:57, 27 July 2026 (UTC)

Hmm, I can do a log only filter, lemme see Sohom (talk) 00:00, 28 July 2026 (UTC)

mw:Extension:AbuseFilter/Rules_format Apparently action will require One of the following: edit, move, createaccount, autocreateaccount, delete, upload, stashupload. I'll check what it needs MediaWiki side. Sohom (talk) 00:06, 28 July 2026 (UTC)

I disagree that there is non-public data involved. The bot can simply use the date and time the article was marked as reviewed, which is stored in the public database replicas and in Special:Log. –Novem Linguae (talk) 01:39, 28 July 2026 (UTC)

I see what you mean now, lemme check Sohom (talk) 04:17, 28 July 2026 (UTC)

This is what I was thinking as well, it may lead to some false positives but that’s an advantage of a soft warning from a bot. 🌸⁠wasianpower⁠🌸 (talk • contribs) 13:30, 28 July 2026 (UTC)

Since we are discussing a bot to monitor and warn hasty reviewers, we should be more specific about what review speed should trigger a warning. For example, should it be 4 or 5 reviews in 30 seconds, or two bursts at that speed? We should also discuss whether certain page types, like disambiguation, stub, or species pages, should be excluded, and if there are any other factors that should be counted or ignored. – DreamRimmer ■ 15:13, 28 July 2026 (UTC)

Emergency measures to handle a huge backlog

If the backlog gets above about 30,000, I plan to RFC allowing unreviewed articles to get auto-reviewed (fall off the back of the queue) after 6 months. We need to avoid a situation where we can never reach zero backlog again, because this is very de-motivating for reviewers. And I suspect the articles in the back are difficult to review ones that fall into a GNG gray zone (the easy accepts and easy declines quickly get handled, the ones with complicated sourcing and/or complicated notability are the ones that end up in the back and NPPs procrastinate reviewing them). Anyway, initial thoughts on that? Is this a reasonable solution to a queue greater than 30,000, or am I way off base? –Novem Linguae (talk) 00:25, 16 August 2026 (UTC)

I think that's entirely reasonable. If an article has been in the queue for six months, I'd hazard that quite a few reviewers will have looked it over and not found a clear reason to delete, so let's just let them be. Practically, it makes no difference, because the article will already have been indexed by search engines for three months by then anyway (I think?). It might be worth tagging such articles with a new hidden category in case people wanted to go delving into them later on. My only concern would be in the nuts and bolts to ensure that longstanding redirects that are turned into articles don't somehow accidentally get auto-reviewed immediately. Cheers, SunloungerFrog (talk) 11:27, 18 August 2026 (UTC)

I would definitely add those articles to a hidden category, I wouldn't want them to slip completely off the radar. Skarmory (talk • contribs) 02:07, 19 August 2026 (UTC)

I'd say a year is more fair. In solidarity, Dafootballguy (Want to talk?) 02:56, 21 August 2026 (UTC)

Thank you for all your suggestions, Novem Linguae, bit unfortunately the situation appears to be deteriorating day by day. As far as I can see, we have now jumped up to well over 31,000 - so some kind of action is urgently required. About a year ago. we managed to get down to a more reasonable 8,000. Can we not somehow rally more support to get things moving again. I am particularly concerned with women's biographies. At 1,546, I don't think it has ever been higher. Perhaps an emergency message to all those authorized to review new pages would help.--Ipigott (talk) 11:43, 21 August 2026 (UTC)

We will be sending out a mass message to NPR's shortly for our regularly scheduled backlog drive. Three of these go out a year. I guess we could mention the high backlog in this message, but I doubt it would make much more of a dent than normal. –Novem Linguae (talk) 01:04, 22 August 2026 (UTC)

And maybe as I suggested earlier we could have one full drive in September followed by a separate full drive in October even if this has not yet been included in the drive schedule.--Ipigott (talk) 08:40, 22 August 2026 (UTC)

I don't feel this section is getting enough engagement. I've created a new section at #NPP backlog is now over 30,000. RFCBEFORE for emergency measures RFC, and I will cross-post a link to that section in some other places. Let's move discussion down there. –Novem Linguae (talk) 09:14, 22 August 2026 (UTC)

Idea 1: automatically mark articles with no review for 6 months as reviewed

This talk page section shall serve as the WP:RFCBEFORE for a major change to the NPP process that I want to RFC soon. The goal of this RFCBEFORE is to make sure we are RFCing the best solution so that the future RFC does not devolve into a discussion about other solutions, which would hinder building consensus around a single actionable solution.

Problem - The NPP backlog (number of unreviewed mainspace articles) has gone over 30,000 for the first time in many years (or possibly ever). This level of unreviewed articles is so high that it is probably not possible to ever achieve zero backlog again unless some kind of major change is made.

In my opinion, the ability to achieve zero backlog is important for reviewer morale and to avoid NPP becoming an endless backlog. Endless backlogs tend to become stagnant and neglected. I think we can all agree that NPP is important and that we do not want it stagnating, lest the quality of the encyclopedia suffer. NPP is am important defense against COI/UPE, AI, obviously unsuitable articles (CSD), non notable articles, machine translations, articles at the wrong titles, unsourced articles, etc.

Proposed solution - I propose we program PageTriage to mark unreviewed mainspace articles as reviewed automatically after 6 months. I think this would be simple to implement on the technical side (we could fix phab:T412014, then insert code into this cron job), and very helpful for reducing the backlog to levels that could be eliminated with backlog drives.

I have observed that articles that are obviously good and obviously bad get reviewed quickly, and that articles that are in a notability gray zone are the ones that languish and end up in the back of the queue. I think letting these gray zone notability articles get marked as reviewed by the software so that NPPers can focus on more egregious articles is an acceptable tradeoff.

How old is the oldest unreviewed article? - Some good data to inform our decision might be where the back of the NPP queue is. That is, what is the oldest unreviewed article? This is complicated to calculate because of phab:T412014, which basically boils down to needing to track articles by "added to queue date" instead of "article creation date", which will require some engineering work. Tracking by "article creation date" is how we do it at the moment, and it is flawed because very old articles get added to the NPP queue when they get un-WP:BLAR'd. These un-BLARs clutter the back of the queue, making it hard to see where the true back of the queue is (i.e. how many months behind we are).

Until phab:T412014 is fixed, we can approximate this with quarry:query/108517. From that query, we can see that the # of articles for each month goes to consistent double digits (like 10 months in a row double digits) on Nov 2023 (33 months), triple digits on June 2025 (14 months), and quadruple digits on Oct 2025 (10 months). One of those should be the true back of the queue, depending on what quantity of articles you think represents the shift from BLARs to regular articles.

This means that we are somewhere between 10 months and 33 months behind in our reviewing. The changes I propose above would mark many of these old articles as reviewed, leaving only articles that are 0 to 6 months old as unreviewed. This would leave 20,632 articles unreviewed, and mark about 11,106 as reviewed. 20,632 is a lot, but is much more likely to be solved with backlog drives than 31,738 unreviewed articles.

Why this solution instead of something else? - As an NPP coordinator for several years, I have tried many things to increase reviewers and reviews. There is no magic bullet. In practice, only two things have affected the backlog graph in a noticeable way: super reviewers who somehow maintain both quality and high volume, and backlog drives. The former is just luck when they show up and these folks will eventually burn out, and the latter we can only schedule so many backlog drives before folks start burning out so I limit us to 3 backlog drives a year. These techniques do not require an RFC. However I think we are at the point where we need a stronger measure, thus the idea and RFC proposal above.

I keep notes on other ideas and solutions at User:Novem Linguae/Essays/NPP reform notes. Other ideas can range from autopatrolling more people, to recruiting more NPPs, to other things. Many have been tried and found to be not as effective as super reviewers, backlog drives, and emergency measures. Also, I am concerned that examining other ideas will prevent the RFC from reaching a consensus due to too many ideas floating around. I am hoping that the solution I chose above about automatically marking articles older than 6 months as reviewed ends up being the most popular so that we can have a clear and decisive path forward.

Related discussion - Wikipedia talk:New pages patrol/Reviewers#Emergency measures to handle a huge backlog

Thoughts? Thanks a lot. Looking forward to your feedback. –Novem Linguae (talk) 09:13, 22 August 2026 (UTC)

Notified: Wikipedia:Village pump (proposals). –Novem Linguae (talk) 09:16, 22 August 2026 (UTC)

I think that this is a good idea, and would support it. @Novem Linguae is this solution contingent on fixing phab:T412014? I ask because there were problems earlier in the year with that ticket and we rolled back the solution then, and because of that, it's unclear to me that it's obvious what the necessary engineering work is and that it's likely to succeed.

As a possibly easier-to-implement alternative in the short term, I'd suggest a manual, one-off exercise that uses the quarry query to derive a list of >6 month enqueued articles (excluding recent un-redirects) and then a script to mark those as auto-patrolled. That would reduce the immediate backlog in time for the forthcoming September drive, and ease the pressure on the continuing solution. I will reiterate that I think we should add such auto-patrolled items to a hidden category for future investigation if necessary. Cheers, SunloungerFrog (talk) 09:46, 22 August 2026 (UTC)

is this solution contingent on fixing phab:T412014. Yeah, we probably should. Without fixing T412014, we can't tell the difference between BLAR'd articles and articles enqueued a long time ago, so we would accidentally mark recently BLAR'd articles as patrolled, creating a loophole that UPE's could exploit.

The proper technical solution to that ticket is to add a new SQL field such as ptrp_enqueued, and corresponding code that fills in that field properly. Then we could sort by it, filter by it, etc, getting accurate data about how long an article has been in the queue.

I do like your idea of having a bot do it. That would help crowd source the work to someone else, since I am already quite swamped with wiki programming work. –Novem Linguae (talk) 10:02, 22 August 2026 (UTC)

For what it's worth, quarry:query/108532 selects a list of articles whose creation date is older than six months, but filters out any that have edits within the last six months that are tagged as mw-removed-redirect. That should, I think, reduce or remove the risk that we mark a recent article creation over a redirect as auto-patrolled. Cheers, SunloungerFrog (talk) 10:35, 23 August 2026 (UTC)

I'm not an NPP reviewer but I remember reading a proposal about splitting the patrolling process so that rather than one editor having to review all parts themselves, they can tick off one part and then the page automatically becomes patrolled when each of those criteria has a tick (or maybe two ticks) from editors. Did that ever get anywhere? Also, I think that autopatrolled criteria can be lowered; I am not eligible as I've only written 21 mainspace articles (1 converted from redirect so xTools says 20) and I think it's a little silly that my created pages need patrolling when the backlog is this big. (in solidarity), JacobTheRox^{(talk|contributions)} 08:44, 24 August 2026 (UTC)

It's being discussed below at #Blue-sky proposal for NPP process. –Novem Linguae (talk) 08:48, 24 August 2026 (UTC)

Do we have a sense if we granted WP:AUTOPATROLLED to some prolific article and redirect creators; how much this might reduce the backlog? ~ In solidarity 🦝 Shushugah (talk) 09:49, 22 August 2026 (UTC)

Novem Linguae has some notes on the effect of changes to autopatrolled at User:Novem Linguae/Essays/NPP reform notes § Emergency plan points 3-5, particularly 5. Cheers, SunloungerFrog (talk) 09:53, 22 August 2026 (UTC)

I'm not sure as well if a user is granted autopatrolled, whether their existing non-patrolled articles will be patrolled automatically. To my understanding, autopatrol happens at creation in mainspace or when moved to mainspace, so if that doesn't happen with their non-patrolled articles, should PageTriage or a bot patrol those? Tenshi! (Talk page) 13:03, 22 August 2026 (UTC)

Granting lots of autopatrol won't retroactively mark articles as reviewed. We'd need a bot. –Novem Linguae (talk) 18:50, 22 August 2026 (UTC)

• I agree with the "there is no magic bullet" statement. But I am somewhat uncomfortable with "leave it there for X months" approach until other measures have been taken. I do not know what has been tried, so a list of failed attempts will be useful. Have you considered 3 different bots that detect copyvio and if 2 agree automatically send the article to draft? That may cut back on the backlog. How about approving an article if 3 users with good background (eg no blocks and X edits) approve it? I looked at the list and saw the fascinating page CDC logic module which looks very good. If myself and 2 other users agree on that can we pass it? Yesterday, all my dreams... (talk) 12:57, 22 August 2026 (UTC)

  I think that last idea could really increase the number of NPPers. At least to me, the gate of having to request a perm is kinda nerve wracking, you're asking an authority figure to review your entire course of conduct and tell you if you've made too many mistakes. ^MetalBreaks_AndBends (One for all) 18:29, 25 August 2026 (UTC)

• I'm not entirely convinced that this would be a good thing. It may be that if the backlog were lower that would make its elimination seem more feasible and might therefore make reviewers more motivated – but equally might it not be the case that, if the articles vanish from the backlog after six months anyway, that demotivates reviewers by making their task seem more pointless? Why should a reviewer bother to mark, say, a four or five-month old article as reviewed if it's going to disappear off the list a month or two later anyway? And more generally, why should a reviewer care about carefully scrutinising articles if articles are constantly being marked as reviewed without scrutiny all the time? I think that a measure of this kind might make the whole task seem even more Sisyphean than it currently does.
  In my view, the real problem lies in the inefficiency of our processes, which all prioritise thoroughness and consensus over speed, as though editors' time was an infinite resource. What I think may be needed is a reform of AfC (so that AfC reviewers are expected to apply NPP criteria to new pages and these are then kept off the new pages feed), of draftification (so that new editors cannot simply move seriously sub-standard articles that are draftified back to mainspace with minimal changes, but actually have to go through AfC), of deletion (so that certain types of substandard article can be speedy deleted more easily?), and of the NPP process itself (to see if there are any ways in which we could actually simplify the process of reviewing and make it easier for people to take up, thereby attracting more reviewers). But I realise this is a tall order. Dionysodorus (talk) 13:32, 22 August 2026 (UTC)

  AfC reviewers already apply the NPP criteria. If an AfC reviewer follows the review instructions, then there should be no reason for NPP to not accept an article. So, I'm not sure what you mean. But otherwise, I agree with your proposal. Kovcszaln6 (talk) 14:11, 22 August 2026 (UTC)

  AfC reviewers apply a lower standard in practice.--Boynamedsue (talk) 11:06, 24 August 2026 (UTC)

  I think this is debatable. The folks that don't do WP:BEFORE at AFC (i.e. expect all GNG-passing sources to be in a draft, otherwise they decline the draft for notability) but do do it at NPP could arguably be applying a higher standard. Although not doing WP:BEFORE at AFC is controversial in itself. When discussed on WT:AFC one time, there was a significant number of respondents that thought that AFC needs to do WP:BEFORE. –Novem Linguae (talk) 19:41, 24 August 2026 (UTC)

  I agree with the first point. If articles roll off after 6 months, we don't really need NPP at all- the backlog can be kept in check without any patrolling. Zzz plant (talk) 14:24, 22 August 2026 (UTC)

  For those who are wary of the proposals to auto-review some articles that have been in the queue for a long time, I'd ask what is the practical difference between an unreviewed article in the queue, and an unreviewed article that has been removed from the queue?

  • Both are indexable by search engines (that happened after 90 days of creation)
  • Neither are eligible for draftification (WP:DRAFTNO)
  • Both have, in effect, become part of the encyclopedia

  The only difference is that an article in the queue might (and that's quite a big might, to my eyes, given that said article has been there for six months already) get analysed by a new pages patroller and marked as reviewed or dealt with in some other way. And all the "dealt with in some other way" (deletion, redirection, merging etc.) options are always open to any editor in any case. I just don't see that the risk of harm to the encyclopedia is anything but low, if not very low. Cheers, SunloungerFrog (talk) 07:26, 25 August 2026 (UTC)

  All good points. I'll also note that this "old-article autoreview" will be logged somewhere and, if folks want, this can be made into a nice-looking daily/weekly report. -MPGuy2824 (talk) 07:39, 25 August 2026 (UTC)

  So they're essentially just moved to a different backlog which is even less likely to receive attention? I personally don't see the benefit in this since someone who likes the idea can just set the new pages feed to show articles starting at 90 days old and for them it will be as though the older ones were reviewed, but this can be assessed in the actual RfC rather than in the current workshop/pre-workshop limbo. lp0 on fire () 08:17, 25 August 2026 (UTC)

  Such articles would not be on a backlog. They would just be in the encyclopedia, like the seven million plus other articles. And as for receiving attention (from a new pages patroller), they haven't received any significant attention for the last six months. I don't mean for this to sound as argumentative as it probably does, but I am genuinely curious about what specific, meaningful harm to the encyclopedia might be perpetrated that could not be fixed by ordinary editing by all our editors. Cheers, SunloungerFrog (talk) 08:56, 25 August 2026 (UTC)

  I do take your point; with such backlogs at AINB, CCI, and CAT:PROMO it seems somewhat over the top to be worrying about articles just because no one has checked that they aren't AI, copyvios, or obvious UPE. But that's an argument for reducing NPP to just a check for G3 and V to be handled as part of regular RCP, which I don't think anyone here supports. The reason I think it's helpful to keep NPP separate from regular editing is that most people, when thinking about how to improve an article, won't think of deleting the article entirely. For the few who would, it's helpful to know that someone else who understands PAG has already determined that the article should exist. lp0 on fire () 09:47, 25 August 2026 (UTC)

  As far as I can see, the whole point of NPP is that articles are checked for notability and for a moderate level of acceptability, and the "reviewed" tag signifies that that has in fact happened. If the "reviewed" tag is ultimately applied to articles regardless of whether they have been reviewed, I think this would undermine the purpose of the tag (since it would no longer serve to guarantee that the article has, in fact, been reviewed), and I think it could serve to discourage rather than to motivate reviewers (since why should anyone review an article carefully if it is soon going to be marked as "reviewed" regardless?).

  As for it being harmful, well, presumably we all agree that it is beneficial for articles to be carefully checked by reviewers (given that we are commenting on this page...), and surely there are some cases in which the skipping of such a check would be harmful, for instance because it would allow incorrect, unsourced, libellous, or copyright-violating material to remain in the encyclopaedia, until it just happens to be detected by another editor (which might not happen for a very long time if at all – and that's assuming that this editor actually knows how to deal with such problems, which many editors who aren't NPP reviewers probably don't). In my view, even a very backlogged review process is probably better than a review process that skips some of the most problematic articles that nobody knows how to deal with, and I think the best place for problematic articles that can't easily be sorted out is probably in the queue, where there is at any rate a chance that an NPP reviewer might come along and give them proper scrutiny later. Dionysodorus (talk) 10:45, 25 August 2026 (UTC)

  I suppose I disagree that articles that have been in the queue for six months are the "most problematic" articles. Surely the "most problematic" articles are those that are obvious attack pages, copyright violations, completely unsourced, clear LLM generations etc. which we already deal very well with by NPP colleagues working the front of the queue? And that articles that have been there for six months are quite unlikely to display those problems? Cheers, SunloungerFrog (talk) 11:12, 25 August 2026 (UTC)

  I don't think clear LLM generations are any more harmful than LLM generations that are difficult to detect; both are prohibited. Likewise, translationvios aren't any less bad than blatant copy/paste copyvios. Any article whose sources are largely in a language not many reviewers speak is probably going to reach the back of the queue unless there are really obvious problems of the sort that would qualify for G11 or G15. lp0 on fire () 11:24, 25 August 2026 (UTC)

  When I said "problematic", I meant problematic in the sense of "trickiest to deal with" rather than in the sense of "causing the greatest problems". Of course you're right that blatant attack pages etc. are the very most important priority that must be dealt with quickly, and articles of that kind are going to be dealt with equally effectively by reviewers working the front of the queue regardless of what is happening at the back of the queue. But that doesn't mean that we can assume that the articles at the back of the queue don't have serious problems that amount to harm to the encyclopaedia: on the contrary, as someone who usually patrols the back of the queue (when I have time to patrol at all), I think they often do, but it's just that the problems are often ones that are tricky and time-consuming to deal with. Dionysodorus (talk) 11:26, 25 August 2026 (UTC)

  NPP seems to me to be a recognised and accepted quality control procedure, and an article marked "reviewed" bears at least some semblance of semi-official approval. Indeed, "why should anyone review an article carefully if it is soon going to be marked as 'reviewed' regardless?" According to our guidance, articles that haven't been reviewed are apparently no longer hidden from search engines [after] 90 days elapse anyhow—if that's the primary concern, so I'm not sure I fully grasp the point of automatically marking them "reviewed" after [x] months. -- Cl3phact0 (talk) 12:40, 25 August 2026 (UTC)

  the point: as @Novem Linguae originally said:

  • the ability to achieve zero backlog is important for reviewer morale
  • to avoid NPP becoming an endless backlog. Endless backlogs tend to become stagnant and neglected.

  Cheers, SunloungerFrog (talk) 14:46, 25 August 2026 (UTC)

  I'm not trying to be obstinate. I got that part—the part I don't see is how lowering the standard by automatically granting "reviewed" status after a pre-set time period (and thus effectively removing the implicit underlying seal of quality) achieves this in the long run. -- Cl3phact0 (talk) 15:18, 25 August 2026 (UTC)

  I think really whether this is a good idea or not might depend on how it works in practice. If the effect of cutting off the back of the queue were actually that it became possible to get the backlog down near 0 at every drive, so that in reality articles very rarely fell off the back of the queue, I think that would be great, and I would be all in favour of it – provided, that is, that any articles that did fall off the back of the queue were tagged or categorised in some way, so that it is possible to see that this is the case.

  But my fear is that this might not actually happen, and we might end up with a position where the backlog is in effect continuous and unclearable, with items constantly being added to one end of the backlog and falling off the back like a conveyor belt, and with there still being a few thousand articles in the backlog after each drive. If the backlog were like that, there would be very little to incentivise anyone to review any given article carefully because it would eventually be removed when it gets to the end regardless, and I think that this would be much more demoralising than the current situation. Dionysodorus (talk) 15:49, 25 August 2026 (UTC)

• I don't have a strong opinion about setting a point at which articles fall off the feed, but I will push back on the idea that they fall into a grey area of notability. During backlog drives, I tend to patrol the back of the feed, and I tend to find that the articles there more often than fail our notability guidelines, but demonstrating that sufficiently to bring an AfD requires a lot of work, often digging through non-English-language sources or trying to assess purported offline sources. They're just a lot more work for reviewers, which is why they've been left alone. Perhaps that means they should fall off the feed, but I don't think they're generally in a grey zone. I am sympathetic to the idea that an insurmountable backlog can be discouraging to reviewers. Here's my big question: do we have fewer active reviewers, or are we getting more articles than before? If the former, big problem for our current model. If the latter, I would suspect it's likely a result of AI-assisted article creation, which is the big inflection point in terms of making it easier for people to submit new articles. If the latter situation is true, what our reviewers need is (1) better tools to identify potential LLM-generated content that should be quarantined for reasons other than notability and (2) policies that make it easier to draftify/quarantine AI slop without going through a time-consuming AfD process. G15 has made the latter easier, but still not perfect. As a reviewer, I don't mind reviewing content written by human writers. What I don't like is having to spend many of my limited human minutes or even hours reviewing/cleaning up/nominating for deletion/other applicable processes content that an editor added to the encyclopedia with little to none of their own human effort. That's demoralizing, and if LLMs are driving an increase in the content our reviewers have to evaluate, we need to tackle that problem. Dclemens1971 (talk) 14:23, 22 August 2026 (UTC)

  ...often digging through non-English-language sources This is something that I've noticed at AfC, and I wouldn't be surprised if the same issue is present at NPP: a lot of the older pending articles are skipped over because their sourcing is either unfamiliar, offline, or not in English. For the former, we could encourage reviewers who've analysed the reliability of sources they come across to then submit suggestions to WP:NPPRS and cite unseen, to save future reviewers having to put in the same time and effort of determining reliability of obscure sources.
  I don't have a solution for offline sources (and it's become a lot more difficult to AGF on them thanks to LLM hallucinations), but I did have an idea i was going to share at WT:AfC that would also help at NPP.
  Currently, WP:AFCSORT is based on ORES data, which sorts them based on topics; that's great for helping reviewers find drafts on subject areas they're familiar with. We should, however, also sort submissions based on the language of their sources, using the |language=foo parameter found in citation templates. That way our multi-lingual reviewers are able to easily find submissions in which their talents would most valuable. I don't have the technical know-how to create such a system, so throwing it out here for anyone interested to steal and run with. In solidarity, nil ^nz 23:56, 23 August 2026 (UTC)

  Honestly, at this point when I see offline sources with no Google Books or Archive.org link, I find they are more likely than not to be hallucinations. Made-up ISBNs and all. Dclemens1971 (talk) 00:02, 24 August 2026 (UTC)

• I'm only throwing this out because of the desperate situation and because I view an RFCBEFORE as a "no bad ideas" phase. I somewhat agree with the concerns raised by Dclemens that the assumption of a grey area of notability for older articles may not always be correct. I realize this would be a lot to implement on a technical level, but I wonder if we could somehow split the queue into two parts: one part checking for notability, and one part checking for everything else (copyvio, AI, promo, undisclosed translation, etc etc). Notability is the hardest to assess and I believe also something that a lot of NPPers dread getting "wrong" even though reasonable people can disagree on whether a given subject meets notability. So if we have a queue that checks for everything else, we can be reasonably certain that after a given amount of time we could tag an article with "maybe notability issues" and leave it be without a big concern. My thought is that in times of huge backlogs, some reviewers could speed through Queue 1 (everything except notability) and leave the notability review untouched in complex cases, leaving another reviewer or an automated process to complete that step. I realize this would be a decently big technical lift, but wanted to throw it out as an idea to see what people thought. 🌸⁠wasianpower⁠🌸 (talk • contribs) 15:00, 22 August 2026 (UTC)

  It would be very helpful when looking at an article to know if the only thing left to assess is notability or if I have to do the full NPP check. Dclemens1971 (talk) 16:08, 22 August 2026 (UTC)

  Personally, I think a lot of this backlog could be cleared by simply... not caring that much about notability. NPP is here to get the real horrors off the site, to make sure nothing is breaking important policies, to tag and sort articles in useful ways - it's not here to be the notability police. Obviously, NPRs should be checking for notability in a general way. Something that is obviously or even probably non-notable should be removed or challenged. But if reviewers would simply mark the "grey-notable" articles as reviewed, that would cut down hugely on the time spent here. Let the "local" editors handle whether those articles should exist or not. NPP should just be the really basic QA. In solidarity, asilvering (talk) 16:27, 22 August 2026 (UTC)

  So let’s say a 75% chance of notability. I also think that if a reviewer comes across an article and tag it as probably not notable, then they should just mark it as reviewed instead of leaving it there hanging. Vanderwaalforces (talk) 16:31, 22 August 2026 (UTC)

  Yes, I would say this is sensible in all cases that aren't a) obvious enough that you really ought to just AFD them or b) BLPs. In solidarity, asilvering (talk) 23:43, 22 August 2026 (UTC)

  Quoting WP:NPP under "Notability", The core purpose of NPP is to check if an article is suitable and appropriate for inclusion. If that's no longer going to be the case (and I'm open to that outcome), then revising NPP's stated purpose is a bigger discussion than when to roll older articles off the NPP queue. Dclemens1971 (talk) 16:48, 22 August 2026 (UTC)

  If the expectation was to tag questionable notability, rather than to fully investigate the article and see it through to its proper end, that might speed up reviews without abandoning the stated purpose. Doing a full BEFORE to either AfD or accept-without-issues is time consuming; at AfC I find it a real relief that I can review just based on what's in the article without having to take on the burden of checking for additional sources. ~ le 🌸 valyn (talk) 02:39, 23 August 2026 (UTC)

  @Wasianpower Building off of this, it may be simpler to create a new user permission (maybe call them New Page Scanner?) for Wikipedians to mark articles as "scanned" for AI/Copyvio/other issues outside of notability. NPSers would have the ability to mark articles as "checked" on the toolbar. They wouldn't be removed from the queue, but NPPers could see that the article has been checked for non-notability related issues already. EaglesFan37 (talk) 16:46, 22 August 2026 (UTC)

• I don't think letting articles automatically roll off after 6 months is a good idea due to BLAR, having to undo all of an NPPers reviews due to suspected NPP abuse, etc. I do think that granting more users autopatroller would help. I can go through Wikipedia:Database reports/Editors eligible for Autopatrol privilege and nominate several users for autopatrolled (however, this database hasn't been updated since March 12th for some reason, so not sure how helpful it actually will be). I do think that @wasianpower's queue splitting idea, if possible to implement, would be great. EaglesFan37 (talk) 16:36, 22 August 2026 (UTC)

  I don't think letting articles automatically roll off after 6 months is a good idea due to BLAR. We can fix phab:T412014 to prevent issues with this. After the proper fixes, BLAR'd articles would be considered by their enqueued date, not their created date.

  having to undo all of an NPPers reviews due to suspected NPP abuse. Same point as above. Once phab:T412014 is fixed, we can make sure that re-adding something to the queue resets the enqueued date.

  this database hasn't been updated since March 12th for some reason. That report hasn't been updated because WMF got rid of the Community Tech Team, and their bot makes the report. @MusikAnimal (WMF), would you be willing to share the link to the source code that generated Wikipedia:Database reports/Editors eligible for Autopatrol privilege? Is it just SQL queries, or is it more complicated than that? If the former, we could probably rewrite it to use {{Database report}}. –Novem Linguae (talk) 19:02, 22 August 2026 (UTC)

  @Novem Linguae I thought it could be related to that, but I thought that had happened in May, not March. EaglesFan37 (talk) 20:28, 22 August 2026 (UTC)

  Ah, fair. The report probably broke before COMMTECHGATE and no one mentioned it in the right place until now. COMMTECHGATE does make it unclear who is responsible for fixing it though. –Novem Linguae (talk) 20:38, 22 August 2026 (UTC)

  Per the user page the source is this script. My guess is that the breakage is related to the categorylinks query in maintenance_count() which was affected by the linktarget migration around around that time. taavi (talk!) 11:36, 23 August 2026 (UTC)

  m:User:Community Tech bot is the go-to for where these bot tasks will go. Wikipedia:Database reports/Editors eligible for Autopatrol privilege is too complex to migrate to Template:Database report, so I volunteered to move it to MusikBot, which as Taavi points out is where the code lives anyway. The suspicion that the linktarget migration was at fault is correct, and it is now Fixed.

  I agree phab:T412014 is the core issue. Until that's resolved, I'll maintain the aforementioned DB report. — MusikAnimal ^talk 23:31, 26 August 2026 (UTC)

• Support, although I would be happier with 1 year at first. I think this is a reasonable proposal, much better than some I have seen here which (to me) look to be too hasty. I would like to know roughly how many would 6month, 12month and perhaps 9month remove from the queue. Ldm1954 (talk) 12:03, 23 August 2026 (UTC)

  Comment, as I just looked at some of the very old Academic's pages. One was a redirect that had been overwritten. It was reported as being from 2021, but in reality was a July 2026 page.

  I would still like to know how many 6/9/12 months would clean up. Ldm1954 (talk) 19:54, 24 August 2026 (UTC)

  quarry:query/108532, which excludes articles with any recent (< 6 months) edits where a redirect has been removed - thus avoiding the un-redirect problem - indicates that:

  • a cut off time of 6 months would remove 9577 unreviewed articles from the queue
  • 9 months, 5193 unreviewed articles
  • 12 months, 2266 unreviewed articles

  Cheers, SunloungerFrog (talk) 07:03, 25 August 2026 (UTC)

  Based upon this I am in favor of either 9months (being conservative) or 6 months. Ldm1954 (talk) 10:42, 25 August 2026 (UTC)

• I took a look at phab:T412014 (the enqueued-date field this idea depends on). The December patch changed the feed to sort by ptrp_reviewed_updated instead of creation date. That column can hold last edit at enqueue time, review timestamp, or AfC submission timestamp. The patch changed how one place read the column, not how any place wrote it. That's not evidence a real fix is hard, just that it needs its own column. We (moderator tools team) could build that column and submit the schema change request. It's tagged Essential-Work and has sat unowned since February; I'll get it queued for engineer time next week.
  So far as I know, the existing 30/180-day purge job just silently drops the tracking row. I think SunloungerFrog's and Skarmory's idea for an "aged out" status is a safe way to build it regardless of what age threshold this lands on. PageTriage already logs like this when a page gets patrolled through core's patrol feature instead of the toolbar. We could do the same thing here, but with a new log entry type.
  JSherman (WMF) (talk) 03:47, 25 August 2026 (UTC)
• Support longer – I am getting back into NPP at a fortuitous time it seems. Having a solid background for the basic ideas does not help me with what I see at the end of the queue. There are articles at the oldest end which are challenging to review, and are clearly so as these articles are still there after having probably been looked at by many NPPers. Maybe by the time September ends begins, I can be stronger and be willing to give these more questionable articles a review.--☾Loriendrew☽ ☏(ring-ring) 16:55, 25 August 2026 (UTC)
• Oppose as missing the forest for the trees. Having potentially problematic articles not on the backlog and a "shorter backlog" isn't actually better than having a longer backlog. ~ A412 ^talk! 17:12, 25 August 2026 (UTC)

Idea 2: autopatrol more people

I do see enough pushback in the above section that I think we should discuss some other actionable ideas. Here's one. Should we instead RFC something related to autopatrolling more people?

Keep in mind that in the past, an RFC actually took away autopatrol from a bunch of trusted users (Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 7D Remove autopatrolled from default toolkit). So this may not be a passable RFC due to community sentiment.

Also, a previous analysis I did indicates that autopatrolling just admins wouldn't make a big enough dent in the backlog -- we'd need to autopatrol a much bigger group, such as all editors with >10,000 edits. –Novem Linguae (talk) 19:06, 22 August 2026 (UTC)

• I would support this, for all editors with >10,000 edits, and probably even e.g. for all editors with >6,000 edits. Of course experienced editors may produce bad articles, but on the whole they are not where the focus of NPP needs to be.
  I think that the conclusion of the RfC linked above makes quite good sense, since it is probably right that people voting on admin candidates ought not to be swayed by the suitability of the admin to be autopatrolled. I don't think that that RfC need necessarily imply that the community ought to be opposed to extending autopatrolled to editors above a certain number of edits, since that is a different issue. Dionysodorus (talk) 20:03, 22 August 2026 (UTC)
• I can support this as well. I'll be nominating a few prolific creators for autopatrol rights in the coming days to kick things off. JTtheOG (talk) 20:23, 22 August 2026 (UTC)
• Oppose. Unfortunately I have seen articles by authors with > 10k edits that had serious issues. Ldm1954 (talk) 12:05, 23 August 2026 (UTC)
• Oppose (as suggested) – I agree with the above, 10k is a little low. Trust is gained, so there should be a strong time commitment as well. Let me throw out 20k edits and 2 years of editing. There is too much WP:GAMING to reach count–based milestones as is, something so potent should be given after seeing how a user can operate over time. For those that have proven to be capable, even at lower counts, they can be manually granted AP, either through request or be granted via magical sprinkling (as I was, is that even still allowed?)--☾Loriendrew☽ ☏(ring-ring) 16:02, 23 August 2026 (UTC)
• Could work with more relevant criteria perhaps One idea that has come up in the past is to automatically nominate editors meeting certain thresholds (a certain very high ratio of undeleted articles, no warnings for copyvio, BLP vio or AI misuse). That would put a temporary burden on admins, but might be worth it. I wouldn't even be opposed to automatically granting under these conditions.
  If we go for a very strong widening (e.g. 2 years and X edits), I can maybe support this if we combine this with a sample of articles from autopatrolled folks being put in the queue (10%). In solidarity, —Femke (talk) 🐦 18:52, 23 August 2026 (UTC)
• Neither for or against at this stage, but at a minimum there should be a provision that they've had x number of page creations patrolled first – for example, many recent changes/anti-vandal patrollers can hit 10,000 edits within their first ~6 months, without having ever created an article (aside from maybe redirects), and i don't think we should be granting them autopatrolled without anyone having ever reviewed their creations first. Whilst I'd trust them on issues like notability and BLP, other issues like WP:CLOP are more an issue, especially for experienced editors with less practice in content creation. In solidarity, nil ^nz 00:07, 24 August 2026 (UTC)
• Oppose. Like Ldm, I know many people with tens of thousands to hundreds of thousands of edits who either are under some sort of article creation restriction (AfC), or have other issues (copyright, AI, verification) which preclude them being given AP. We do need a solution here, but this one is too reckless and there is no real point edit-count wise where this isn't an issue. I would maybe support some sort of auto-grant for people with evidence of high-quality creations (for example, AP is granted if someone has created a GA/FA with a certain percentage of authored content). Lynch44 00:36, 24 August 2026 (UTC)

  I believe there is a work-around to auto-denying something: if someone is sanctioned, they can be granted then immediately ungranted. IIRC, this is used to prevent things like extended-confirmed. ☾Loriendrew☽ ☏(ring-ring) 00:54, 24 August 2026 (UTC)

• Support extending autopatrolled. Agnostic on the exact threshold. Mccapra (talk) 20:56, 24 August 2026 (UTC)
• Support extending AP. I would even sooner support massively loosening the AP criteria to "25+ articles and no CSD-worthy problems" (so for articles, approximately no A7-level notability, CV, or LLM problems) than support idea 1. ~ A412 ^talk! 17:24, 25 August 2026 (UTC)
• Comment: I have brought this topic up at Wikipedia:Village pump (idea lab)#Automatically grant certain users with autopatrolled rights. CostalCal (talk) 01:23, 26 August 2026 (UTC)
• Not sure about this. I got autopatrolled after an NPPer suggested it. Assuming this is a common practice, it is probably being given to those whose work probably doesn't need to be checked. If it is not common practice, is there some way to encourage it? CMD (talk) 02:46, 26 August 2026 (UTC)
• I don't think this is a good idea; high edit counts do not mean competency. If there's any automatic criteria, it should be based on amount of articles created without being deleted, with an additional criteria that all of those articles have been reviewed by NPP. I wouldn't be opposed to lowering the requirements to apply for autopatrolled, but I don't think automatically granting it is a good idea, especially based off pure edit count. Skarmory (talk • contribs) 03:11, 26 August 2026 (UTC)

  I like this idea. Ideally, I feel that autopatrolled shouldn't really be a status you're aware of as an article creator. Ignoring the technical reality of the user right, the ideal situation imo would be something like if (>=10 NPP reviewed articles) AND (Deletion/Merge rate <= 5%), then don't add the new article to the NPP queue. Practically speaking, that feels quite bot-able: one database with human-reviewed article count and a running deletion/merge rate for each article creator, and have the bot auto-review any new articles by those editors if they meet the criteria. Cheers, Suriname0 (talk) 21:15, 26 August 2026 (UTC)

Workshop?

If our discussions here don't arrive at an obvious answer, we might need to do an RFC workshop phase, and then RFC a ton of ideas and see which one(s) happen to pass. This would be similar to Wikipedia:Administrator elections/October 2024/RFC workshop. This will be my plan if one of the ideas above doesn't emerge with a lot of support. It could also be a good way to solicit additional actionable ideas. –Novem Linguae (talk) 19:10, 22 August 2026 (UTC)

I think you already know that the workshop will be as peaceful as the Palio di Siena but will take much longer. In the meantime how about 3 different bots that detect copyvio and if 2 agree will send the article to draft. That requires no palio, and will probably have to happen anyway. I will say no more. Good luck. Yesterday, all my dreams... (talk) 05:27, 23 August 2026 (UTC)

Right now 250 unreviewed articles are marked as having a possible copyright issue. This is less than 1% of the total backlog of 32K. Your solution involves coding 2 additional bots using completely different logic, but will not make much of a dent to the backlog. -MPGuy2824 (talk) 05:32, 23 August 2026 (UTC)

Also, copyvio is one of the few issues NPP looks for which aren't addressed by draftifying, so this wouldn't actually reduce the backlog at all. lp0 on fire () 06:01, 23 August 2026 (UTC)

I guess the idea of reducing the number of new articles created is still totally off the table? Levivich (talk) 02:06, 24 August 2026 (UTC)

If we do a workshop phase, could certainly propose something like this. There's a whole category of measures we could consider if folks are willing to shift some editorial responsibility from reviewers to article authors. For example, getting rid of WP:BEFORE would have the effect of requiring all GNG-passing sources be cited in the article, speeding up reviewing. –Novem Linguae (talk) 03:13, 24 August 2026 (UTC)

Lots of tradeoffs here, but in an environment where we have so many incoming articles, I think it could be reasonable to expect page creators to include sources that validate notability in their articles before they are eligible for mainspace. Dclemens1971 (talk) 03:15, 24 August 2026 (UTC)

A slightly less severe measure might be to allow draftifying without a BEFORE-style search, but if someone else objects then require a full search as normal. This would be dicey because draftifying can have the effect of avoiding impartial scrutiny, but the other way of looking at that is it reduces the workload on editors. Another idea would be that for GNG (and similar guidelines like NBIO and NORG), a BEFORE is only required if at least one GNG-passing source is provided. At that point we kind of end up with "expand A7" which could also be an option but I'm not sure because I've never really used A7 much. Anyway, these are all ideas we could discuss in a workshop phase. I agree that a workshop on a dedicated talk page followed by a mega-RfC is probably the way to go with this. lp0 on fire () 04:36, 24 August 2026 (UTC)

That's how draftification works now. There's no requirement for a BEFORE when draftifying if it meets one of the conditions of WP:DRAFTYES, and a contested draftification preempts further draftifying without an AfD or similar consensus. Dclemens1971 (talk) 13:19, 24 August 2026 (UTC)

Sorry, wasn't very clear. There's no requirement for a BEFORE when draftifying due to a COI, the article being machine-generated, or significant quality issues, since establishing notability wouldn't fix the problem. However, it's also fairly common to draftify due to lack of apparent notability, in which case I think a BEFORE would generally be expected (opinions might well differ on this though, so the guideline should probably be clarified either way). Formalising that this is allowed without a BEFORE would be one option for reducing the burden on reviewers. lp0 on fire () 21:49, 24 August 2026 (UTC)

 You are invited to join the discussion at Wikipedia:New pages patrol/2026 backlog discussion/RFC workshop. –Novem Linguae (talk) 23:45, 26 August 2026 (UTC)

Blue-sky proposal for NPP process

A bit of a blue-sky suggestion – but what if NPP worked something like this? (I am creating a separate section for this purpose, since although it is partly intended to make it easier to reduce the backlog it is a separate suggestion, and I do not wish to confuse the discussion above.)

Reviewers should first consider whether the article meets any criteria for speedy deletion: if so, they should tag it appropriately and move on to a different page.

Assuming the article does not meet the speedy deletion criteria, NPP reviewers would have six flags to use (rather than the single "reviewed / unreviewed" flag that they currently have):

• notable / of uncertain notability / not notable
• of acceptable quality / requires cleanup before being marked as reviewed / of unacceptable quality
• no copyvio / possible copyvio / clear copyvio
• not promotional / possibly promotional / clearly promotional
• no translation or translation correctly attributed / possible unattributed translation / unattributed translation
• no AI-generated text / possible AI-generated text / clear AI-generated text

Once all six flags are set to the desired values ("notable", "of acceptable quality", "no copyvio", "not promotional", "no translation or translation correctly attributed", and "no AI-generated text"), that article would be automatically flagged as "reviewed" and removed from the New Pages Feed.

This approach would make it much easier for new reviewers to get into reviewing, since the new reviewers would not have to think about everything at once: it would be perfectly possible for a new reviewer just to go through checking for notability and nothing else, or to go through looking for AI-generated text or whatever. This would be much simpler and perhaps more fun for new reviewers than having to learn and apply the complex processes at WP:NPP independently, and would also mean that reviewers who were not fully knowledgeable about Wikipedia policy or who were uncertain about what approach to take on a particular page would not just have to give up and move on to a different article: rather, they would be able to make a partial contribution, and would gradually gain in confidence. We would then have more reviewers participating in the process, which would help the backlog to go down.

This approach would also actually improve the thoroughness of the process, because it would mean that we could be sure that pages were only being flagged as "reviewed" once someone has at least nominally checked for all six flags. At present, I am sure that there are many reviewers who do not in fact remember to check for all these things, but this would give reviewers an instant reminder of what they are supposed to be checking for in each individual case.

The New Pages Feed could be configured in such a way that it can be searched according to the flag values with which an article has already been flagged. This would make it possible for reviewers (probably more experienced reviewers) to go through articles that have been flagged with one of the undesirable values, and to take the appropriate action (such as a deletion nomination, or a draftification, or a copyvio report, as the case might be). Since individual experienced reviewers could specialise in handling articles with certain types of problems, it would be potentially be quite easy for reviewers experienced in a certain type of action to handle a lot of cases all at once, again helping to reduce the backlog more quickly.

Also, if we had a process like this, it would be possible for us to see what the main issues in the backlog actually are: for instance, is it mostly articles of uncertain notability, or cases of possible AI use, or what? If we had that information, and could say (for instance) "there are four thousand possibly AI-generated articles in the queue that it is difficult to get through", we could then identify why it is especially difficult to get through those articles, and consider in a targeted way how we might adapt our policies to address this, rather than having to think about the backlog as an undifferentiated mass that we can find no better way of reducing than just cutting off any article that is more than six months old. Dionysodorus (talk) 16:18, 22 August 2026 (UTC)

I think this is an excellent idea. It would save us a lot of time in accidental "double patrolling", where multiple reviewers check the same things unnecessarily. In solidarity, asilvering (talk) 16:23, 22 August 2026 (UTC)

I haven’t finished reading, no, obvious copyvio should be speedied (not marked as reviewed); clearly promotional should be speedied as well, not marked as reviewed. All of those points are currently being handled by one template or the other. Vanderwaalforces (talk) 16:24, 22 August 2026 (UTC)

@Vanderwaalforces: As I said at the start of my comment, "Reviewers should first consider whether the article meets any criteria for speedy deletion: if so, they should tag it appropriately and move on to a different page." That is to say, it is a key part of what I am saying that any article that is eligible for speedy deletion should simply be speedy deleted (just as you say) and should not be reviewed at all. The only pages that would be flagged as "clear copyvio" or "clearly promotional" on the above scheme would be ones where this is clear in the reviewer's opinion but not so patently obvious as is required for speedy deletion.

If what I am suggesting were ever made into a guideline or policy, the phrasing of the relevant policy page would of course need to be carefully phrased to explain much more clearly exactly what is meant by each flag value: my above post is just a rather general and approximate suggestion that would need to be refined. Dionysodorus (talk) 16:31, 22 August 2026 (UTC)

@Dionysodorus You’re right on track, I just wanted to make sure. Vanderwaalforces (talk) 18:33, 22 August 2026 (UTC)

It would be a big change, but I like the idea in theory. To build on it, I think in most "clearly problematic" cases the article should be able to go straight to exiting the queue (one way or another). So I'd suggest something more like the following:

• no copyvio / possible copyvio / tag for G12
• not promotional / possibly promotional / tag for G11
• no AI-generated text / possible AI-generated text / draftify probable AI-generated text / tag for G15
• no translation or translation correctly attributed / possible unattributed translation / draftify unattributed translation
• of acceptable quality / tag for cleanup / draftify for unacceptable quality
• notable / tag for uncertain notability / draftify for notability / PROD / AfD

It takes several thumbs-up for an article to make it to 'approved', but only one major thumbs-down to fail a review. Some of the "possible" options are worth having to avoid the problem of duplicated work & as 'breadcrumbs' for reviewers who will evaluate the other aspect; it might also work to let folks tag those issues and mark the article as 'tagged' for them. ~ le 🌸 valyn (talk) 01:08, 23 August 2026 (UTC)

No need to draftify unattributed translations; just add the attribution yourself (or tag G12 if incompatibly licensed). lp0 on fire () 06:07, 23 August 2026 (UTC)

I think something like that would still have most of the benefits that I outlined, and might be preferable in terms of not leaving definitely problematic articles in the queue (although as Ip0 says the option for the unattributed translation ought to involve attributing, not draftifying). But on the other hand, I think that there might be something to be said for my original version, i.e. where the flagging is kept separate from the action taken on the basis of the flagging. After all, the actions that reviewers take are slightly more varied than just a clear one-to-one correspondence with specific problems. It might be better to keep the two separate, in such a way that the instructions for the review process have three stages: (1) check for speedy deletion criteria, (2) flag the article using the six flags, (3) if confident to do so, take action on those flags. That would be less messy than having the flags carry specific actions with them, and would mean that inexperienced reviewers can still flag the article in a way that reflects their true judgement e.g. that the article is certainly not notable even if they don't feel confident to make an AfD nomination or whatever. Dionysodorus (talk) 10:38, 23 August 2026 (UTC)

My original version might also be more straightforward and user friendly. For instance, I can imagine a version of the page curation tool with six buttons that cycle through the different options when a reviewer clicks on them, cycling through green ("fine on that criterion") through amber ("possibly problematic on that criterion") to red ("clearly problematic on that criterion") and then back to grey ("no value entered"). Something like that could be really easily handled by the very most inexperienced reviewers, giving them something to do even if they don't feel comfortable making their own AfD nominations, whereas something like what LEvalyn proposes above would be more complicated and more like the current process in terms of the knowledge it requires even inexperienced reviewers to have and in terms of the responsibility it requires them to take for potentially controversial actions. Dionysodorus (talk) 10:44, 23 August 2026 (UTC)

This would be hugely helpful. When I open up an older article, I can often see that other reviewers have touched different parts of it, but the workflow expects me, if I mark it as reviewed, to have checked every criterion myself. A mechanism to allow us to collaborate on reviews and not have work lost or duplicated would be excellent. Dclemens1971 (talk) 16:50, 22 August 2026 (UTC)

I love this idea; I've only been using my NPP rights to patrol redirects for a while now, as doing a full new page patrol is in my opinion one of the hardest tasks to do on Wikipedia, and trying to do a number of them exhausts me. Splitting up the workload into more manageable chunks would be huge, and it would absolutely get me to try patrolling articles again. Skarmory (talk • contribs) 02:42, 23 August 2026 (UTC)

Support we may need to do some tweaks but I think this would be a great approach. I focus a lot on notability but am nowhere near as good as others at spotting AI generated text. Mccapra (talk) 10:07, 23 August 2026 (UTC)

I think that some method of enabling partible reviewing would be very helpful (see also my previous comments at Wikipedia talk:New pages patrol/Reviewers/Archive 53 § Investigating the cause(s) of backlogs. The pessimistic side of me wonders how long it might take to implement the six flags: it would be quite a considerable code change to the Page Curation extension. Cheers, SunloungerFrog (talk) 10:22, 23 August 2026 (UTC)

I agree. It'd be hard to code into PageTriage. We'd probably have to create a config variable with all the various settings, then find some place to store all those values in the SQL database (or create a place), then add code that does the appropriate logging, then add code that loops through the config variable and creates those check boxes in the "mark as reviewed" flyout. And that'd just be the minimum viable product -- what if you wanted to unreview just one thing? This would be several weeks of engineering time I think. These changes would also have effects downstream, i.e. we'd have to re-think how we award points in backlog drives, and reprogram backlog drive bots. –Novem Linguae (talk) 17:26, 23 August 2026 (UTC)

@Novem Linguae: I was thinking not so much in terms of making this appear in a flyout. For this to work well, I think what would ideally be needed is a set of six new buttons in a column to the left of the existing column, each of which cycles through green-amber-red-grey? And then if they are all set to green the existing reviewed button would automatically light up green; and if the reviewed button was set to green the six new buttons would all automatically go to green as well. If it were hidden away in a flyout I don't think it would really achieve anything, because it would just become a recondite element of the existing system rather than an easy and intuitive way for inexperienced reviewers especially to participate. Dionysodorus (talk) 19:54, 23 August 2026 (UTC)

Special:NewPagesFeed would also need updating to add filters for the new review states. –Novem Linguae (talk) 20:14, 23 August 2026 (UTC)

• Support: Simplification of the tagging options is an excellent idea.--Ipigott (talk) 15:10, 23 August 2026 (UTC)

• Comment, quite dubious I would be OK with this provided that the current review structure is retained for those who want it. My standard approach is to tag either or both inline or at the top, and/or edit. I think there is much more that can be done when reviewing articles than these 6 very simple tags, and in many cases should be. I am concerned that we are throwing out the baby with the bath water here, and I don't want to compromise the quality of NPP reviewing. I would definitely want to wait a few more days (at least a week) to see if the current drop in unreviewed continues. Ldm1954 (talk) 15:36, 23 August 2026 (UTC)

  I don't think anything that I'm suggesting would prevent thorough reviewers from correcting the articles that they review, from adding tags, from considering issues with the article other than the six listed, etc. It would just change the mechanism for marking articles as reviewed, in such a way that an article is flagged separately for each of these considerations rather than all at once. Dionysodorus (talk) 15:49, 23 August 2026 (UTC)

  Wouldn't you just be able to review anything still? If one of the six boxes is left unchecked, the article will still be in the queue, and you can do as much work as you want on it. Once you're comfortable with where the article is, check off all the remaining boxes.

  I also don't agree that this would compromise the quality of NPP reviewing. It allows editors who specialize in different parts of reviewing to focus on those individual parts, instead of having to be a jack of all trades.

  It's also worth noting that we don't have to stick with these six criteria. It also might be nice to have some sort of message box where notes can be left for future reviewers, since we can't do that in the same way that AFC reviewers can put a comment at the top of the draft. The best we currently have are maintenance tags, but that doesn't get across whether part of the article has been cleared. Skarmory (talk • contribs) 18:03, 23 August 2026 (UTC)

  Do add your support for phab:T388095 which is exactly about this kind of messaging among NPP colleagues. Cheers, SunloungerFrog (talk) 19:40, 23 August 2026 (UTC)

  Indeed, there could be a check box for all six (or whatever) components allowing a reviewer to sign off on all at once. Many articles are non-problematic and we should retain an option for a reviewer to easily review everything. Dclemens1971 (talk) 19:24, 23 August 2026 (UTC)

  Indeed the existing "reviewed" button could just be left in place, and it could be not only that if you turn all six new buttons to green the "reviewed" button goes green, but also that if you turn the "reviewed" button to green the six new buttons all go green; it could work both ways. Dionysodorus (talk) 19:42, 23 August 2026 (UTC)

• Would setting up a page where we have a bunch of old unreviewed articles, and a list of criteria that any reviewer can check off manually, be a good test run to see how this works in practice? Given how much engineering time is needed for the suggestion, I think doing some very early test runs would be a good idea. Skarmory (talk • contribs) 18:17, 23 August 2026 (UTC)
• I like this idea a lot, people have different competencies. Gnomingstuff (talk) 19:06, 23 August 2026 (UTC)
• Support with tweaks - Agree with all the comments above regarding the advantages. However, for articles that are an 'easy pass' we would now need to check six boxes rather than just press a button. There are other instances where having checkboxes is unnecessary such as marking articles sent to AfD as reviewed. We look for a different set of criteria when reviewing certain types of articles such as dab pages, so some of the checkboxes wouldn't be applicable. The same is true for redirects. I would suggest the checkboxes were in addition to the existing 'mark as reviewed' button, not instead of. (Perhaps the checkboxes could be put in a new section 'Partial review' in the curation tool?)
  Adding a checkbox for referencing is IMHO a necessity.
  'Of acceptable quality' is very broad and possibly open to interpretation. Maybe it needs defining in more depth, even if its just a note by the button saying check for x, y, z.
  Looking at it from another angle, it might be a way of providing feedback automatically to the article creator or other interested editors if the current state of the checkboxes was displayed as a matrix on the talk page. --John B123 (talk) 23:20, 23 August 2026 (UTC)

  We could keep the current review button and have it turn all six boxes green if clicked.

  I agree that the criteria probably should be workshopped, which is one of the reasons I suggested doing test runs; there should be a way to mark down other concerns with articles, and we can see what common concerns pop up and what criteria are less necessary. Skarmory (talk • contribs) 23:40, 23 August 2026 (UTC)

• So far I like the ideas of splitting up the review checklist and of having “tag for notability and mark reviewed” to be standard procedure for borderline and low-risk articles. _signed, Rosguill ^talk 00:09, 24 August 2026 (UTC)
• Support for the idea overall. One thing I would add is that if an article is notable but needs cleanup or is somewhat promotional, it can still be tagged and marked as reviewed. Otherwise, these articles could just sit in the NPP queue forever. - The9Man ^Talk 08:20, 24 August 2026 (UTC)

  I think it needs to be the case that all the flags should be green before the article is marked as reviewed: otherwise, the system would be confusing and not intuitive for inexperienced reviewers. I think however that we would need to write the instructions for reviewers in such a way as to make it absolutely clear that articles can be marked as green for any of the criteria as soon as the problem has been addressed (e.g. through tags), or in cases where the problem is not so serious that it ought to prevent the article being removed from the queue. Dionysodorus (talk) 08:59, 24 August 2026 (UTC)

• Support. Many of the articles that languish are the borderline notability and possible LLM use cases that many do not want to single-handedly sign off on. ~ A412 ^talk! 17:28, 25 August 2026 (UTC)
• Support prototyping/experimenting. This is a really interesting idea. Even without getting everyone on board or integrating multiple checkboxes into the Curation Toolbar, we could prototype this concept with a template that NPP (and AfC?) reviewers could optionally add to the talk pages of articles they've partially reviewed. I'm thinking of templates like Template:DYK checklist and Template:DYK review checklist, which are simple to fill out. Dreamyshade (talk) 06:33, 26 August 2026 (UTC)

  I think having this prototyped plus having a hub somewhere that editors can find partially reviewed articles would be a great idea. I know nothing about template design, but I'd be willing to help however possible. Skarmory (talk • contribs) 18:07, 26 August 2026 (UTC)

  @Skarmory Got a prototype started on test.wikipedia.org: Template:NPP checklist and Template:NPP_checklist/testcases. I don't know anything about templates either, but I have a LLM coding tool, and it's just meant to be a demo; hopefully somebody with actual skills could revise/rebuild it if people want something like this. Most important challenge is not even a code thing: how to phrase the template fields? See Template:NPP checklist#Usage - for example, "copyvio = y" sounds like "yes, there's a copyright issue", but my intent is to allow people to type "y" to say "yes, likely complies with copyright policy". Dreamyshade (talk) 01:35, 28 August 2026 (UTC)

  This would probably need to go on the talk page of articles, rather than on the main page. Someone would probably want to develop a user script so that reviewing could be done quickly and efficiently.

  I agree that "copyvio" is too vague. You can just make the template parameters longer to solve the problem. "checked_for_copyvio", "checked_for_X", etc. –Novem Linguae (talk) 02:28, 28 August 2026 (UTC)

  Definitely for talk pages! And yes, I figure somebody could make a userscript to make it easy. I put in the longer labels and that helped, thank you. Thinking I should also switch the output from phrasing like "Free of copyright violations: " to "Checked for copyright violations: ". Dreamyshade (talk) 02:49, 28 August 2026 (UTC)

  Looks pretty good to me, though I would add an entry that's "Checked for LLM use". Further additions can be done as this is tested and common additions to the comment field pop up. Would it be a good idea to move this to English Wikipedia now? Skarmory (talk • contribs) 03:18, 28 August 2026 (UTC)

  That's why I drafted 6.2 in the RFC workshop, to hopefully get consensus on adding an LLM-check step to the NPP flowchart, which would endorse adding that step to the checklist template as well. I don't think we'd need to wait for the RFC to test an optional template, but I do want to make sure it's decently usable (not confusing/unclear) before people start trying it on real article talk pages. Try it on a test article on test.wikipedia.org and see what you think? You can use this test article and its talk page. Dreamyshade (talk) 04:25, 28 August 2026 (UTC)

  I made up a few comments on the test article talk page; seems good to me. One thing I did there that I'd probably do in practice as well is edit the previous checklist instead of creating a new one to avoid talk page clutter.

  I didn't have in mind having the checklist template be equivalent to the NPP flowchart (mainly because the suggestion this comment thread sprouted out of had different criteria), but that's reasonable enough, and would make more sense to a new reviewer. Skarmory (talk • contribs) 06:01, 28 August 2026 (UTC)

  I think each person should do their own checklist because that fits the convention of a talk page comment - it's basically just a structured comment. Might also be a helpful historical record to see what a person said they checked when monitoring new reviewers or evaluating potentially suspicious reviewers. Dreamyshade (talk) 06:30, 28 August 2026 (UTC)

  adding an LLM-check step to the NPP flowchart. I would oppose adding more steps to the NPP flowchart, because this would make reviewing more complicated and therefore would slow down reviewing and therefore would make the backlog worse. Also, this is already kind of covered by the mandatory step "check for CSD G15", and the optional step "place maintenance tags". –Novem Linguae (talk) 07:03, 28 August 2026 (UTC)

Move reviewed pages needing work out of the NPP queue

Another idea, which could perhaps work alongside some of the proposals above: once an NPR has actually reviewed an article and identified the issue, should it necessarily remain in the NPP queue?

For example, if I review an article, think the subject is probably notable but the article requires cleanup, has promotional wording, or needs better sourcing, I can tag those issues. At that point the article has technically been reviewed; it just hasn't been fixed.

Perhaps there could be a separate "reviewed - needs attention" queue for these pages. The article would leave the main NPP queue with the relevant maintenance tags intact, while CSD/PROD/AfD/draftification would continue to be used where appropriate.

This would make the NPP backlog more accurately represent pages that have not actually been reviewed yet, rather than also including pages which an NPR has already assessed but wasn't comfortable marking as reviewed because they still need work.

It may also reduce duplicated effort, where a second reviewer later goes through essentially the same assessment only to reach the same conclusion. - The9Man ^Talk 09:44, 25 August 2026 (UTC)

In general, according to current guidelines those articles should be marked as reviewed. Tagging isn't even required, it's an optional step (though one I would recommend if, well, the issues are already identified). I usually watchlist those articles though. Alpha3031 (t • c) 01:30, 26 August 2026 (UTC)

If a page is a notable topic, should be a standalone page, has at least one source, and doesn’t have any BLP violations, LLM content or copyvio, then tag that sucker for whatever other improvement is necessary and mark it as reviewed! Dclemens1971 (talk) 01:48, 26 August 2026 (UTC)

i do not agree with this. In many cases I think it is appropriate to tag, send a message to the page creator and see if they will improve it as an alternative to draftification. It does require more work, but in my experience ~50% of editors listen and you end up with a much improved article.

Most pages I have seen with one or two sources are full of either or both original research and opinions. Quality matters. Ldm1954 (talk) 02:01, 26 August 2026 (UTC)

We as reviewers can personally choose to do more than the NPP checklist requires, but we cannot insist or expect that other reviewers do more than the NPP checklist requires. Dclemens1971 (talk) 02:07, 26 August 2026 (UTC)

To mark as reviewed or not

I've noticed in the past and its also apparent from this discussion, there are two different schools of thought on marking articles with issues as reviewed. Some will tag and then mark as reviewed, others will tag but not mark as reviewed. Does marking as reviewed mean the article has been reviewed irrespective of any issues found or does it mean the article is acceptable to be in mainspace.

There are also comments that suggest notability is the primary concern and others that suggest notability is just one of several things to be considered.

Obviously consistency between reviewers should be a goal but beyond that suggestions in this discussion sway towards on viewpoint or the other. To move forward with possible ways to reduce the backlog I think we need to agree on when we should be marking articles as reviewed as this may have a significant bearing on the feasability of suggestions. --John B123 (talk) 06:37, 26 August 2026 (UTC)

I think that marking as reviewed means that, in the reviewer's eye, the article is acceptable to be in mainspace. Not perfect, not complete, but good enough: see Wikipedia:Editing policy § Wikipedia is a work in progress: perfection is not required. And that notability is just one of several things to be considered. As @Asilvering said above, NPP is here to get the real horrors off the site, to make sure nothing is breaking important policies, to tag and sort articles in useful ways - it's not here to be the notability police. Obviously, NPRs should be checking for notability in a general way. Something that is obviously or even probably non-notable should be removed or challenged. Cheers, SunloungerFrog (talk) 07:00, 26 August 2026 (UTC)

Adding maintenance tags is an optional part of the NPP flowchart, so is unrelated to marking as reviewed. Wikipedia:New pages patrol#Reviewing articles states that the fundamental things to check off before marking as reviewed are copyvio, CSD, draftification check, notability, and the article being at the correct title. –Novem Linguae (talk) 07:11, 26 August 2026 (UTC)

un-BLAR and REFUND

Looking through the back of the queue, there are many articles that have been un-BLARed and at least one that has been deleted by PROD and then REFUNDed. Being old articles these are beyond the scope of NPP and should not be in the queue. I'm not sure just marking them as reviewed to remove them from the queue would be appropriate as this would imply the articles have no issues whereas previous editors wouldn't have BLARed them without reason. Is there a way to remove them from the queue without marking them as reviewed? Can anybody workout a database query to provide the number of these articles? --John B123 (talk) 06:59, 26 August 2026 (UTC)

I don't see why these should be removed from the queue, and no, there's no way to remove them without marking as reviewed. If your issue is that they should be listed by the date they were un-BLARed/undeleted, this is phab:T412014. Un-BLARing an article is common UPE behavior so definitely shouldn't make it exempt from NPP. lp0 on fire () 07:13, 26 August 2026 (UTC)

Take for example One-Eyed Monster, it was created on 24 June 2011, BLARed on 25 January 2026 and the BLAR reverted on 23 August 2026.My 'issue' is that this is a 15 year old article and is beyond the scope of new page patrol. An article being recreated by a UPE after a BLAR is a different situation to a revert of a BLAIR. John B123 (talk) 22:15, 26 August 2026 (UTC)

You can ask for database queries at WP:QUERY. Please give them very specific criteria such as "number of mainspace articles that are currently marked as unreviewed that were a redirect within the last 30 days and are not currently a redirect".

I'd say that any article that was BLAR'd then reverted back to an article probably doesn't need a full NPP review, just enough of an NPP review to make sure that un-BLARing it was reasonable, and a check to make sure its content wasn't replaced with UPE slop. –Novem Linguae (talk) 07:13, 26 August 2026 (UTC)

@John B123, quarry:query/108624 probably does what you want. It selects all unreviewed articles with a creation date over six months ago and with one or more edits in the last six months that have been tagged as mw-removed-redirect. At the moment, that returns a count of just over a thousand articles created from redirects in the queue. Cheers, SunloungerFrog (talk) 07:34, 26 August 2026 (UTC)

@SunloungerFrog: Thanks, that's useful. --John B123 (talk) 22:18, 26 August 2026 (UTC)

Discussion at Wikipedia:New pages patrol/2026 backlog discussion/RFC workshop

 You are invited to join the discussion at Wikipedia:New pages patrol/2026 backlog discussion/RFC workshop. –Novem Linguae (talk) 23:45, 26 August 2026 (UTC)