Wikipedia talk:New pages patrol/Reviewers/Archive 45

This is an archive of past discussions about Wikipedia:New pages patrol. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 40

←

Archive 43

Archive 44

Archive 45

Archive 46

Archive 47

→

Archive 50

Often I'll see page creations in draft space that are identical to this, or that started like that and then have been gradually changed. It seems like they have found an example article or template somewhere, load it in the edit window, save the page, then go back and replace the placeholder text with text about the subject they want to write about. What I want to know is - where is that coming from? It's not the placeholder text that appears when you use the article wizard. There are approximately 3,000 pages that use that, or portions of it, mostly in userspace or draft space, but I can't find the gadget or tool they are using to load that. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:42, 21 July 2022 (UTC)

It comes from {{Biography}}. DanCherek (talk) 20:52, 21 July 2022 (UTC)

Beat me to it! Yes, I've seen folks paste in the template and not realize they have to subst it. Chris Troutman (talk) 20:54, 21 July 2022 (UTC)

Thank you both! ~ ONUnicorn^{(Talk|Contribs)}problem solving 21:23, 21 July 2022 (UTC)

I've seen this scenario play out three times:

1. An old article somehow gets into the new pages feed (in two cases it was because of a history merge operation and in one case it was due to a vandal moving a page out of mainspace and the user reverting the vandalism not having autopatrolled)
2. A new page reviewer draftifies the article
3. I revert the draftification since we're not supposed to draftify old articles

So, a reminder to everyone here: make sure to check the history properly before draftifying articles found at the back of the queue. * Pppery * _{it has begun...} 13:04, 24 July 2022 (UTC)

With the backlog, we're also seeing quite a few articles now that are over 90 days old. Which is annoying, 'cos on a few occasions now I've reached for Twinkle's nice red Draftify button just to check and find they're older than three months. Grr! Best Alexandermcnabb (talk) 14:15, 24 July 2022 (UTC)

Hi folks - I'm a statistician and fellow NPP member and I'm curious to learn more about how we are tracking the size of the backlog. In particular I'd like to research the volume of articles flowing into and out of the backlog each day in hopes of coming up with an estimate of what it would take to permanently reduce the size of the backlog and keep it hovering as close as possible to zero. Yes this may sound crazy but I think it's a good exercise at the very least if nobody has done it yet. (Clearly the answer is more reviews and/or reviewers, but how do we calculate how many?)

So my specific question is - does anyone know how to pull a list of timestamps for articles both when they are **entering** and **exiting** the queue? Paradoxsociety 00:07, 23 July 2022 (UTC)

I have had it in the back of my mind to ask for better statistics, such as the number of in and out per day (both article and redirects separately). I don't believe this is readily available at present. All we currently "track" is the total article backlog. That is recorded twice a day I believe (there is a link on the reports section). You can get a count of the redirect backlog from the pages feed. Improving this would be nice, but there are probably higher priorities right now. MB 03:47, 23 July 2022 (UTC)

I used to use Quarry to take 'snapshots' of the queue back when we were trying to bring it down from the high of 20-25k in 2017. It gave a good visual description of the queue. Did require a bit of work but was pretty useful IMO. For example [1] shows the backlog as it existed on 28 Jan 2018. I don't think there is any easy way of retroactively doing this, I had to run queries on Quarry to get snapshots on the day. As far as your specific question, I feel like it would be possible to query 'articles under 6 months old', 'date created', and 'date reviewed' in some meaningful manner to get the info that you want, since all of these metrics are in public logs. I'd ask on WP:QUARRY if you have an idea of what you want and someone can help with the code. — Insertcleverphrasehere^{(or here)_{(or here)(or here)}} 18:47, 23 July 2022 (UTC)

If you looked at it that way, over time, with 1% fewer reviews, our backlog would be ~40,000 and with 1% more reviews our backlog would be at ~0. In reality, the rate of reviews changes in response to the backlog (and other things) To keep the backlog low, we need happy reviewers who stick around and respond as needed. Right now the reviewing process is painful for most people and they just grin and bear it and many just pitch in when the barn is on fire. North8000 (talk) 11:32, 25 July 2022 (UTC)

Maybe the key is to figure out how to make it less painful/more fun.

I think the fun part of NPP is finding an article that isn't very good but has potential and working to improve it, but that is time consuming and if the focus is the backlog then people feel the need to tag the issues and move on quickly rather than doing the fun part.

I also think there is an unhealthy focus right now on deletion/spam. Yes - the point of NPP is to keep that stuff out and it does need to be kept out - but the idea of "fighting a demoralizing losing battle against a never ending flood of literal garbage" is rather unappealing for most people.

This needs to be about improving the encyclopedia - that's how you get people involved. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:54, 25 July 2022 (UTC)

The discussion was at Wikipedia:Articles for deletion/1996 Chorley Borough Council election. Besides the normal reasons, I took this one there requesting substantial discussions which could provide useful guidance. This was a typical "all stats" article (meaning it had an intro sentence or 2) for a medium sized area (~107,000 people) that is not a state/province or a country, with no shown GNG-type sources (albiet where it could be argued that they might exist) The discussion was substantial and was open for over 5 weeks. Closed by a highly experienced admin. The result was delete. Sincerely, North8000 (talk) 13:30, 26 July 2022 (UTC)

One interesting thing to do is first read the closing statement, then read the "save" rationales. I believe that none of the "save" !votes had policy backing. — rsjaffe 🗣️ 15:27, 26 July 2022 (UTC)

If there's one thing for us here to learn, I think that it's to always keep policy and guidelines in mind before these things get out of hand. I'm not advocating being overly tough, but to keep them in mind. This makes one of several blocks of articles which grew big while clearly not complying with policies and guidelines. People start doing large blocks of these as an activity. then a few get kept at AFD by "because there's lots of articles like that" arguments. And then maybe get added at the wp:outcomes essay and then people quote the essay as evidence of a consensus which overrides policy and guidelines, despite the essay itself clearly saying to not use it in that way. This happened at train stations. I don't know what's next on elections, this was just one where I requested a very thorough discussion. North8000 (talk) 17:58, 26 July 2022 (UTC)

The mind boggles. There are gazillions of “East Cupcake Council election” articles sourced to stats. I’m going to need a longer retirement. Mccapra (talk) 20:12, 26 July 2022 (UTC)

I think that a gradual approach is to start with just dealing with new articles. And the convince folks that are doing these to redirect their energies. For example to build one nice "East Cupcake Elections" article instead of an article on each of East Cupcake's 50 elections. North8000 (talk) 20:39, 26 July 2022 (UTC)

WHAT IF...our techs could create a script that will prevent an editor from executing publish changes if the material contains a copyvio? Perhaps a copyvio prevention tool would work similar to the way the blacklist tool works; i.e., preventing material from being added. I'd appreciate your thoughts before I add this to our wishlist. Atsme 💬 📧 10:46, 24 July 2022 (UTC) Adding - I just read a comment by SandyGeorgia at WP:ANI Tangential discussion on possibility of a Copyvio algorithm, and she mentioned a bot possibly called Corenbot, that checked every new article. I wonder if she's thinking EranBot, which is a tool that DanCherek brought to my attention in this comment? 11:21, 24 July 2022 (UTC)

I don't think AI technology is good enough to use a strategy of blocking the edit completely. Let's say you're writing a stub about a professor and you include a bibliography of their works. An article that is mostly the names of their papers will set off Earwig with a very high percentage, but is not a copyright violation. Also, any edit to an old article will also set off the copyright detector, because people will have copied from Wikipedia over the years. If we did something like this, we'd need to two two things:

1) Only do this check for new article creation.

2) Make the edit a warning that they could click through rather than a full stop.

Another practical limitation is that copyright detection is A) slow and B) expensive. Earwig takes like 30-60 seconds to load, and is sometimes down (and it is down because it ran out of credits for the day). The reason for both A and B is that it uses a search engine API to grab random snippets of the article and search for those chunks. Search engine APIs are a performance and cost bottleneck.

It may be possible to run another AI on top of Earwig and train it to have a very low false positive rate. Training an AI to have a very low false positive rate was done with User:ClueBot NG, the most successful AI on Wikipedia. In general, AI works by "training it" with humans giving a yes/no answer, and then it adds data to a "yes" dataset and a "no" dataset, and then it invents algorithms to pass all the "yes" testcases and fail all the "no" testcases to the best of its ability.

Just my two cents. Hope it helps. –Novem Linguae (talk) 13:13, 24 July 2022 (UTC)

Thanks, Novem - I think the AI technology actually is advanced enough. We already know machines learn fast, depending on what humans teach them; therefore, it is more likely that limitations are HI-based, not AI. The latter is my AIP (Anything Is Possible) way of thinking, but rest assured, it is only dangerous in early morning, and wanes substantially as the day progresses. It is gone by Happy Hour, which can occur at any time of the day.^[FBDB] But seriously, either both of your suggestions are great!! Perhaps the authors of prior scripts/code (EranBot + Earwig) could put their heads together with you, Danny & the other brilliant techs working for WMF (or possibly our own dedicated team of super-duty techs once our proposal is granted), and can actually make this happen. I know Rome wasn't built in a day, but they didn't have super computers back then, or the need to develop faster, more capable and user friendly software. FB is dabbling in it, and we know WP has their big toe in the deep end, so why not give it a try? Just think about the resources such a tool will free-up, not to mention all the other suggestions on the wish list! Atsme 💬 📧 13:54, 24 July 2022 (UTC)

SandyGeorgia was referring to User:CorenSearchBot, which last edited six years ago (contributions). "The source code can be perused here, but it's not pretty." Yup, not at all pretty :( – wbm1058 (talk) 14:59, 24 July 2022 (UTC)

Yes, thanks; carry on :) SandyGeorgia (Talk) 17:01, 24 July 2022 (UTC)

From User talk:Coren/Archive/2016/May:

Hey Coren, as you may have noticed, CorenSearchBot has been down since April 2nd. Is there anything that the Community Tech team can do to help CorenSearchBot migrate to the new API? I put some notes for you at phabricator:T131169. Kaldari (talk) 19:18, 11 April 2016 (UTC)

The bot lost access to Yahoo's index, so they made the new Google Search API available for use from Tool Labs.

...but I'm not sure whether Coren ever transitioned his code to use the new Google Search API :-(

I'm afraid that until we find a workable alternative to the search engine we used, we're CSB-less even on English Wikipedia. :-( — Coren ^(talk) 20:09, 1 May 2016 (UTC)

So I'm not sure how helpful the source code would be, even if it could be found somewhere... wbm1058 (talk) 15:30, 24 July 2022 (UTC)

Wikipedia:Bots/Requests for approval/CorenSearchBot (approved August 2007). Part of the infrastructure that supported this is still hanging around:

• User:CorenSearchBot/config
• User:CorenSearchBot/manual
• User:CorenSearchBot/exclude
• User:CorenSearchBot/requests
• User:CorenSearchBot/results
• User:CorenSearchBot/allies
• User:CorenSearchBot/request to google

Templates were moved from Coren's user space

(User:CorenSearchBot/pageincluded, User:CorenSearchBot/pageincludes, User:CorenSearchBot/wikipage)

(User:CorenSearchBot/notice-pageincluded, User:CorenSearchBot/notice-pageincludes, User:CorenSearchBot/notice-wikipage)

Someone was concerned about this bot's editing. CorenSearchBot seems to have become over-elaborate and may be causing problems.

CorenSearchBot is temporarily out of order. As of approximately July 20, 2011 Yahoo (the service currently used by CSBot and a number of other copyright assessment bots) no longer allows searching by automated processes via a free web interface. Discussion is now ongoing to find a replacement search engine, but until those conclude the bot is not functional and no longer processes requests. (More details can be found on the maintainer's talk page).

Aha! Source code from August 2007 — wbm1058 (talk) 16:11, 24 July 2022 (UTC)

I just noticed that the CorenSearchBot BRFA mentioned another copyvio bot, User:Wherebot, which was blocked in November 2007 because it was malfunctioning (contributions) – wbm1058 (talk) 16:34, 24 July 2022 (UTC)

CorenSearchBot used to compare newly created pages to a web search, and reported the results at Wikipedia:Suspected copyright violations for copyvio patrollers to go through. As wbm1058 points out, it stopped being active in 2016. That same year, CopyPatrol was launched with EranBot, which compares new pages and large additions of text to existing pages in mainspace and draftspace using Turnitin's plagiarism detector. So CorenSearchBot has since been completely superseded by this new system. The Turnitin detection works pretty well (though, like Earwig, each plagiarism check uses a Turnitin credit, and we don't have an infinite number of those), but it does require the human review at CopyPatrol just because there's so many possible scenarios that need different responses – copyvio that should be removed, un/attributed quote, un/attributed copying within Wikipedia, un/attributed translation, false positive, simple reverts, restoring previously removed content, etc. DanCherek (talk) 17:05, 24 July 2022 (UTC)

Thanks. – wbm1058 (talk) 20:17, 24 July 2022 (UTC)

• Ah hah!! Speaking of bots, see User:Eubot. Correct me if I'm wrong, but User:Eubot#Spring 2006 suggests to me that articles were being created by bots as far back as 2006. Perhaps Warofdreams would be kind enough to fill us in on some of the details that possibly may help WMF techs create some of the suggestions I made relative to copyvio, copyediting, corroborating/adding RS, rooting out hoaxes, etc. Atsme 💬 📧 01:13, 27 July 2022 (UTC)
  • @Atsme: See Wikipedia:History of Wikipedia bots. Bots were creating articles as far back as 2001–2002. They were a significant factor in bootstrapping Wikipedia into becoming what it is today. – wbm1058 (talk) 01:27, 27 July 2022 (UTC)
    • Wow, well, there you have it. Thx for that info, wbm. One would think WMF would know about this, and would have been actively trying to lessen the burdens on volunteers who are practically begging for relief of these backlogs. Atsme 💬 📧 02:18, 27 July 2022 (UTC)

See Wikipedia:Village_pump_(policy)#Message_to_Author_When_New_Article_Is_Draftified. MB 03:06, 27 July 2022 (UTC)

One of the reviewers User:Bruxton has moved an article I was working on to draft space giving the reason as "I unable verify any of the references." But they are all cited in the article? I logged in to work on the article and saw it was moved again even after I did everything the previous reviewers asked for (added at least 2 citations - I added 4, with inline references to a 5th study I haven't been able to find yet). The books are not all available in a publicly accessible way, is it then not allowed to use them in the article? I have read the information that was given me and I think the article is ready but it was moved again. what can I do about it? Moonspiel (talk) 09:44, 28 July 2022 (UTC)

Could you please link to the article/draft in question? -MPGuy2824 (talk) 10:15, 28 July 2022 (UTC)

It's currently at Draft:Perrissona Gappit case where I submitted it for additional review. Moonspiel (talk) 10:17, 28 July 2022 (UTC)

Seems to be genuine and the sources are good. The lede is absolutly terrible and needs to be expand. The lede should always have location and dates. There is no info it it at all. scope_creep^Talk 10:44, 28 July 2022 (UTC)

IMO the article complies with wp:not and wp:notability and that is sufficient to exist in mainspace. The inability to verify the given references is not a valid reason to say otherwise. That said, the article in such terrible shape that it really isn't an article. Besides the "no lead" issue, the whole article is written like somebody just making some comments rather than presenting the topic. In short, the article does not cover the topic. So, while IMO the article is technically OK to exist in mainspace, why not work on it in draft some more and then move it / get it moved? North8000 (talk) 11:47, 28 July 2022 (UTC)

@Moonspiel: Despite being technically eligible for mainspace, IMO no reviewer is going to want to be the one to OK that non-article for mainspace. What do you think about working on it in draft space and then moving / getting it moved to mainspace? I'd be happy to get pinged for the move then if you wish. North8000 (talk) 14:01, 28 July 2022 (UTC)

It's not mandatory by any means, but I'd also consider online versions of those sources - they DO exist. There are links to Kieckhefer's work here, for instance! No harm working on it in draftspace, as per my colleagues above. Best Alexandermcnabb (talk) 12:41, 28 July 2022 (UTC)

And page 32, though not 33, is available on Google books and verifies Perrussone Gapit. "I am unable verify any of the references" seems an inappropriate grounds on which to draftify: presumably the reviewer would not accept any article based on print sources - books or newspapers - but has to see websites? Hmm. @Moonspiel: while you are still working on an article, the {{under construction}} template is helpful as it tells reviewers just that, and the lead needs to summarise the article (particularly, to have geographical context). PamD 13:19, 28 July 2022 (UTC)

The Ref 3 doc is available and you can verify all of it. Its in German right enough, but it is verifiable. scope_creep^Talk 14:24, 28 July 2022 (UTC)

Here is the document: page 107. It is all valid scope_creep^Talk 14:30, 28 July 2022 (UTC)

• Comment. Good morning all. Thank you all for the comments. My own opinion was that there was no harm in having the editor continue to work on the article. I know that it might cause consternation on the part of the OP to have the article moved to draft - I see they were upset with another reviewer who moved a different article to draft telling them not to do it again. Any reviewer is welcome move the article back to main space at any time. Thank you all for your hard work in this section of the project, and I apologize that I have caused editors extra work with my action. Bruxton (talk) 14:41, 28 July 2022 (UTC)

Howdy folks. I was recently asked to be the NPP technical issues coordinator and I happily accepted. MB and I are going through the old PageTriage bug reports and feature requests. PageTriage is the software that pops up the NPP toolbar on the right of your screen. There's a ton of old bug reports and feature requests, and some are outdated. Anyway, are there any bug reports and feature requests that jump to mind that you think we should prioritize? Feel free to name one or two issues that are important to you, to get them on our radar. Thanks. –Novem Linguae (talk) 08:42, 14 July 2022 (UTC)

• As a relatively new NPP reviewer, I have fallen foul of a bug in the AfD option three times. The AfD process is started but the tool doesn't complete it properly. I have had to re-edit the article to manually add the deletion tag on the article (plus edit summary) and edit the article's deletion discussion page to add the recommended code ("{{subst:afd2 ..." etc). This occurred most recently (yesterday: 13 July 2022) in relation to Susan Ruth Kamunya. Thanks Paul W (talk) 09:33, 14 July 2022 (UTC)

  Do you get any popups when you experience the AFD bug? If so what do they say? –Novem Linguae (talk) 21:03, 14 July 2022 (UTC)

  Sadly, no. The initial outcome is a deletion tag that includes a lot of italicised text. When it first happened to me, I didn't know it was faulty (but wondered why it didn't immediately appear in that days's AfD listing) - another editor (User:JPxG) kindly fixed the problem and alerted me to it. Paul W (talk) 09:26, 15 July 2022 (UTC)

• Why can’t the NPP tool use Twinkle (or the Twinkle code) for everything Twinkle does. That way, we’re reducing the maintenance effort for NPP and using a code base that’s heavily used and well-maintained. Then place the NPP effort on all the other components’ bugs. — rsjaffe 🗣️ 11:16, 14 July 2022 (UTC)

  Unfortunately this one is harder than it looks and would likely require dozens of hours of dev time on both codebases. The problem has to do with tightly coupled code. –Novem Linguae (talk) 20:23, 14 July 2022 (UTC)

  I guess it’s too late to state that tight coupling is considered a “code smell” in many programming environments. — rsjaffe 🗣️ 20:29, 14 July 2022 (UTC)

  Hmm. One simple implementation of this would be to just have clicking certain PageTriage buttons (such as the "tag" button) pop up the Twinkle tag window. Now that I'm talking this out, that might be an idea worth exploring. Eliminating code duplication would be a win for maintainability, and this would also fix the AFD bug. One complication would be that the user would have to have the Twinkle gadget turned on and fully loaded. Another complication would be that we'd lose Special:Log page curation logging of deletion and tagging actions, and notification tray notifications to the article creator. –Novem Linguae (talk) 20:43, 14 July 2022 (UTC)

  Twinkle Is already aware of NPP and has options pertaining to marking pages reviewed. Perhaps that other functionality could be added to it. — rsjaffe 🗣️ 05:33, 15 July 2022 (UTC)

  Removing tagging and deletion icons from the tool and just having reviewers use Twinkle could also help with the icon spacing issue. It would also remove those “dangerous” buttons from the interface which could improve the Ux (I.e., if I needed to do something about the article other than approval or wiki love, I’d move to Twinkle—conceptually, that seems clearer to me, and would be great for people who already use Twinkle for non NPP purposes). — rsjaffe 🗣️ 07:49, 15 July 2022 (UTC)

• The message box under "Mark as Reviewed" should have the language adjusted to say " Add a message to Talk page for the creator and/or other Reviewers. This message will also be posted to the creator's talk page" This would better match the message left on Article Talk page when using and also hopefully encourage reviewers to use the feature on difficult articles, you know the ones we all skip over repeatedly. Slywriter (talk) 11:58, 14 July 2022 (UTC)

• I have two requests. 1. Move the “mark as reviewed” tickbox from just above the “add tags” button to the right of it. It is easy to hit both together on a touch screen interface and separating them would prevent this. 2. Add “orphaned” to the common tags list. I’ve never got the curation toolbar to do AfDs properly but I think we should either fix it or strip that functionality out. Mccapra (talk) 12:43, 14 July 2022 (UTC)

  #2 would be easy to implement by putting in an edit request at MediaWiki:PageTriageExternalTagsOptions.js. Making this comment as a note to myself to do this, after testing the adjusted code. –Novem Linguae (talk) 20:25, 14 July 2022 (UTC)

  I have problems with the touch interface too. Consider increasing the vertical spacing. — rsjaffe 🗣️ 20:33, 14 July 2022 (UTC)

Woo hoo! Tick box has moved! Thank you! Mccapra (talk) 07:59, 29 July 2022 (UTC)

• The list of unfulfilled bugs and features is at Open Phab requests replete with a handy table made by MB and Novem Linguae that includes the Phab tracks. It might be best to start by listing the items in the table in order of reviewers' priority rather than start requesting new features. That's why this thread has been opened in order to obtain feedback. New patrollers might not be familiar with the history of NPP and its long road to development and further upgrades. No one here would want to go back to the ancient page patrolling system which some of us have been around long enough to remember. On a more personal note, I would be against reverting to Twinkle for all or any of the features of the Curation tool. In my opinion a compact system for patrolling and controlling the quality of new articles is paramount to the ultimate quality of the encyclopedia. Therefore, as the post-2012 system was a salaried WF development (albeit with a great deal of direct collaboration with us), the effort should be to persuade them to continue to maintain and improve it rather than burden the volunteers with it, even if it means rewriting the MediaWiki extension from the ground up. One of the days the system will want to be adopted by other language Wikipedias that don't use Twinkle. Kudpung กุดผึ้ง (talk) 21:36, 14 July 2022 (UTC)

My own experience is having AFD on it malfunction many times. Usually the AFD page not getting created, or getting created without the contents. I started to try to ask about it here and the experts just said use Twinkle. North8000 (talk) 22:56, 14 July 2022 (UTC)

This is a long list of things that are quirks/hurdles for newcomers to overcome but then are fine after one gains experience. Let me know if you want me to list those. North8000 (talk) 23:01, 14 July 2022 (UTC)

North8000. Sure. Feel free to list them if they are software issues you'd like us to prioritize. –Novem Linguae (talk) 21:32, 15 July 2022 (UTC)

OK here goes....."list of things that are quirks/hurdles for newcomers to overcome but then are fine after one gains experience":

• Lack of nuts-and-bolts documentation on how it works / what it does. I don't mean coding-level stuff, I mean user level stuff...like "this is specifically what happens when you click this". In other words, the missing real manual at the curation tool info.
• Some way to turn it on. Right now the only way I know is to go to the page feed via page curation and look at articles that it lists. For example, to use it to un-mark a reviewed article.

• Sometimes the "message bar" default is at "message the reviewer" and if you don't watch for that you end up messaging yourself instead of the editor. I don't know why that even exists, but it should never switch to that automati9cally.
• Switch off or bring a warning screen up for "message the creator" when the "creation" was more than a year ago. Inevitably on those the "creator" is like somebody who created a redirect 10 years ago and not the actual creator which converted the redirect into an article 3 months ago. Or have it go to the person whose action turned the "reviewed" flag off.
• Have the creator in the page feed be the person whose action turned the reviewed flag off, not the one who originally created the article. So if "person A" created it as a redirect 10 years ago, and "Person B" changed the redirect into an article 3 months ago, we see the info on "Person B" not the info on "Person A"

Sincerely, North8000 (talk) 13:13, 16 July 2022 (UTC)

• The list is not really long but it obviously contains some requests that are more important and/or urgent than others. The ultimate aim is to convince the WMF rather than the self-appointed 'policy controllers' at Phab that they really should be completed as soon as possible, and that the work should be done by paid devs and not expected to be carried out by community volunteers who are already at breaking point. Theoretically the WMF works for us and not vice versa. Some of the requests go back 10 years and are not complex to implement. It should not be too difficult for reviewers to make a top 10 list of priorities, based not only on their personal preferences, but on what they believe is most important for NPP. Twinkle is not an option, Triage/Curation was based explicitly on the premise that it should be compact and not force patrollers to dash around all over the site to find a function they need, and we should not be expected to go back to the pre-2012 NPP system..Kudpung กุดผึ้ง (talk) 23:48, 14 July 2022 (UTC)

• As noted by Slywriter above, and previously by li'l ole me, it would be nice to expand the 'add message' functionality to include another contributor (maybe a drop down of contrbibutors? Shouldn't be too long with newish articles - and it's already there in the 'Wikilove' option...) other than the creator, for instance where redirects have been turned into articles. I'd also like that functionality to be open if you aren't tagging the article - so that a note can be shared with the creator/major contributor to improve the page without dropping it on the article talk and where a tag is not necessary. For instance, I find many editors neglect to put a project tag on the article talk page... Best Alexandermcnabb (talk) 05:10, 15 July 2022 (UTC)

Alexandermcnabb, most editors neglect to put a project tag on the article talk page. The newbies don't know about projects, and others are in the firm belief that it's up to the community to finish the articles. Naked URLs and missing cats are more things that annoy me and put me off wanting to patrol. Nobody can really blame them though, under the mantra Wikipedia is the encyclopedia anyone can edit and the WMF's policy that the number of articles is more important than the quality, not enough is done to catch new users and say "Woa! Have you completed all the essential bits of your article before you click 'publish'? Here's a list: ..." Easy enough to do, never been done. Kudpung กุดผึ้ง (talk) 09:44, 17 July 2022 (UTC)

I agree and I agree - and generally find that when I pop 'em a reminder, editors do add project tags... Best Alexandermcnabb (talk) 11:31, 17 July 2022 (UTC)

1. Auto tag & draftify - stubs & articles that have -0- sources, which would include no sections/sub-sections titled References or Sources, and no citations (raw or otherwise). The auto header tag would be citations needed. Once checked and tagged, draftify with a friendly note to the author's UTP advising them that citing RS is required, and suggest they watch this tutorial, or read Wikipedia:Citing_sources, or they can seek mentorship help at WP:TeaHouse.
2. Auto tag stubs/articles that have sources but need citations only.
3. See How AI could help make Wikipedia entries more accurate. There may be something in that article relative to finding/determining hoaxes & accuracy.

My focus is more on automation, and lessening the work load for patrollers, and what they have to do after landing on a new article. I may return to expand my list if anything more comes to mind. Atsme 💬 📧 14:56, 17 July 2022 (UTC)

If someone would like to comment on the notability of List of retracted paleontology papers that'd be welcome. Some discussion happening at Wikipedia talk:WikiProject Academic Journals#List of retracted paleontology papers. My current take would be that this ought to be draftified until at least two sources showing general topic notability are provided. --Elmidae (talk · contribs) 12:06, 29 July 2022 (UTC)

Really, what we need is an article on retractions in paleontology. Just having a list gives no context. I have similar concerns with other list articles where it seems that more effort goes into making a list than goes into making the list have meaning. — rsjaffe 🗣️ 18:54, 29 July 2022 (UTC)

So, I have an idea - User:ONUnicorn/Articles for cleanup. This idea was inspired in part by several discussions here in New Page Patrol, but also on the village pumps, ANI, and the current ArbCom case about conduct in deletion discussions. Please take a look. Does this look like something you as patrollers would use? Would you be inclined to use it instead of draftification? Instead of PROD? Instead of AFD? In conjunction with one or more of those? Do you think it would be workable, an improvement over what we have? Or would it be a mess? Would it get sufficient participation? Would you feel obligated to use it? Would you be confused as to when it is appropriate? Right now it's a very rough idea, and any feedback is welcome. ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:54, 27 July 2022 (UTC)

My concern is that there is already too little participation at AfD, so this would likely not see enough editors to make a difference. ScottishFinnishRadish (talk) 19:01, 27 July 2022 (UTC)

I see the first three problems as almost certainly occurring. — rsjaffe 🗣️ 19:11, 27 July 2022 (UTC)

I think the larger problem is the ill-placed inclusionism of the idea. NPP triages pages already in mainspace. There is no reason to try to "save" junk content. In fact, by improving dreck in the mainspace, even if that were possible, would create a perverse incentive for drive-by randos to just drop junk on our website to clean up. I think WP:Requested articles is a better way for the non-editing readers to indicate which articles they would like to see so our experienced volunteers can do it the right way. Chris Troutman (talk) 19:13, 27 July 2022 (UTC)

Neither for nor against at the moment, but I'll note that Wikipedia:Cleanup, while not used too often, does serve a similar function. -- Tamzin^{[cetacean needed]} (she|they|xe) 19:15, 27 July 2022 (UTC)

I'm not keen on this proposal and agree with teh comments by Chris troutman. -Kj cheetham (talk) 16:39, 1 August 2022 (UTC)

MB and whoever else wants to participate: Wikipedia:New pages patrol/Reviewers#Guidelines for revocation#3 needs clarity but first we need to clarify how The editor has used the permission to gain the upper hand in disputes. I don't see how the rights could possibly give anyone an advantage in a dispute, but I do see how #3 can be used against an editor, inadvertently or otherwise. It is not difficult on WP to become a target of a unilateral decision via the sole discretion of a potentially biased admin. None of us want to believe something like that could happen, but it does, so let's eliminate the ambiguity in #3. Atsme 💬 📧 12:43, 30 July 2022 (UTC)

• Comment Surely, 'the editor has in any way abused the right or used it as leverage in the course of interactions or disputes with other editors'. But you make a good point - in what way could you use the NPP right as leverage in a dispute? "Revert me once more and I'll mark your latest page creation as unreviewed"? I mean, wooOooo... Best Alexandermcnabb (talk) 13:00, 30 July 2022 (UTC)

I don't know if it has actually happened, but as with admin, mis-use of the imprimatur that goes with the role is far more likely/ common than use of the tool. North8000 (talk) 13:35, 30 July 2022 (UTC)

Along the lines of 'Do you know who I am?' - I'd expect to get laughter trying to use NPP as a boss-level status stick! I carry a dustpan, me! Best Alexandermcnabb (talk) 14:28, 30 July 2022 (UTC)

Someone could try to intimidate an editor and say something like "I have the NPP right which means I am an expert in determining notability, so if I say your article does not belong in mainspace do not move it again". I don't see a problem with #3 as written. If the rule itself is abused by a admin, there are venues to deal with that. MB 14:46, 30 July 2022 (UTC)

In which case I'd prefer the wording 'abused the right or used it as leverage', but to be honest it's not a big deal as far as I'm concerned. Best Alexandermcnabb (talk) 15:13, 30 July 2022 (UTC)

I've never seen it happen. I was just commenting on mis-use of the role is more likely than mis-use of the tools. North8000 (talk) 16:13, 30 July 2022 (UTC)

Perhaps revise along the lines of don't mislead the newcomers. To a beginner, any user who reverts/draftifys looks like an Admin. Can also absorb what Rsjaffe suggests removing below. Slywriter (talk) 17:10, 30 July 2022 (UTC)

Actually, #2 is the one I’d like to see revised, as it only refers to being over critical: The editor has demonstrated a pattern of failing to exercise sufficient care when reviewing pages, resulting in new users being offended or discouraged. I'd like the second clause to be removed so that it reads The editor has demonstrated a pattern of failing to exercise sufficient care when reviewing pages. — rsjaffe 🗣️ 16:36, 30 July 2022 (UTC)

It does seem like two separate thoughts mashed into one. Would agree you shouldn't frustrate any editor, new or experienced. Slywriter (talk) 17:10, 30 July 2022 (UTC)

I agree, sufficient care is important to avoid both wrong declines and wrong passes. (t · c) buidhe 18:01, 1 August 2022 (UTC)

Hello all. I'm happy to announce that I wrote some patches that I think fixed the AFD and PROD bugs in the Page Curation toolbar. These bugs have been around for years and are probably the most common bugs that cause people to get fed up with the toolbar and switch to Twinkle. I would encourage folks to try switching back to the Page Curation toolbar for deletion tagging, and let me know if the below bugs are gone, and let me know if I need to fix any additional bugs.

• PROD now writes the reason
• AFD template now only placed on article page one time
• AFD page now created consistently

cc @ComplexRational, Paul W, and Mccapra: –Novem Linguae (talk) 02:12, 29 July 2022 (UTC)

That’s great thank you so much. I’ll try it today. Mccapra (talk) 05:21, 29 July 2022 (UTC)

Tried it out on an AfD and it worked perfectly. Paul W (talk) 14:47, 29 July 2022 (UTC)

Then tried it again, and got another partially malformed AfD (though - I think - not as mangled as before; I only had to partially reconstititute it) Paul W (talk) 18:08, 29 July 2022 (UTC)

@Paul W. You're referring to this right? Can you walk me through exactly what is malformed please? –Novem Linguae (talk) 19:20, 30 July 2022 (UTC)

It was a couple of days ago, but to the best of my memory, I think I was still prompted to add code to the original editor's user Talk page, but when I checked it looked like that had been done. Sorry I can't be more helpful. I will give Page Curation AfD another go when I next spot an opportunity. Paul W (talk) 12:01, 31 July 2022 (UTC)

Great work! Curbon7 (talk) 15:04, 29 July 2022 (UTC)

Thanks for the ping. For some reason, though, my AfD page still did not get created [2]... could it be a lag/cache problem or might there be another outstanding bug? ComplexRational (talk) 15:18, 29 July 2022 (UTC)

@ComplexRational. Thanks for trying it out again and for the diffs. This may be a race condition. Let me work on an additional patch. I'll ping you again when it's ready in a week or two. –Novem Linguae (talk) 19:26, 30 July 2022 (UTC)

I have a patch in code review to hopefully fix the AFD bug mentioned above. New question. Has anybody had problems of any kind with tagging proposed deletion (PROD) since my patch last Thursday? If not I will close the ticket on Phabricator. As a reminder, the problem before was "empty reason". –Novem Linguae (talk) 01:28, 3 August 2022 (UTC)

Alexandermcnabb had a great idea above. Articles should not be searchable in 90 days automatically, but ONLY AFTER they have passed NPP. I think this is actionable, it is probably pretty easy to file a Phabricator ticket tagged with Wikimedia-Site-requests to change $wgPageTriageMaxAge = 365;. Should I create a WP:VPR for this? Is 365 a good number of days to bump it up to? (currently at 90 days) –Novem Linguae (talk) 18:55, 17 June 2022 (UTC)

This is a great idea; by definition, anything still in draft is not ready to be searchable. Chris Troutman (talk) 19:08, 17 June 2022 (UTC)

This isn't about drafts, I think: it's about mainspace articles that haven't been patrolled yet. I think drafts already aren't searchable. Extraordinary Writ (talk) 19:11, 17 June 2022 (UTC)

• I agree that this would be a good idea; hopefully it shouldn't be too controversial. Do you know where the 90-day limit was decided? All I could find was this RfC, which seems to suggest that all unpatrolled pages should be noindexed. Extraordinary Writ (talk) 19:11, 17 June 2022 (UTC)

• I think there are some technical limitations; I remember a similar discussion where it was revealed that the backlog for redirects is capped at 30 days because the page triage system cannot handle the amount of redirects that would pile up in the full 90 days. _signed, Rosguill ^talk 19:31, 17 June 2022 (UTC)

  @DannyS712, would you be able to weigh in on any technical limitations to raising $wgPageTriageMaxAge? Is there some kind of database issue that makes this not as easy as changing a variable? –Novem Linguae (talk) 20:16, 17 June 2022 (UTC)

  I'm not familiar with wgPageTriageMaxAge, sorry DannyS712 (talk) 20:55, 17 June 2022 (UTC)

  @MusikAnimal, would you be able to weigh in on any technical limitations to raising $wgPageTriageMaxAge? Is there some kind of database issue that makes this not as easy as changing a variable? –Novem Linguae (talk) 23:02, 17 June 2022 (UTC)

  @Novem Linguae There's no technical concern with increasing $wgPageTriageMaxAge as far as I can tell. gerrit:356781 points to this discussion which implies it was created for this very reason. — MusikAnimal ^talk 05:35, 18 June 2022 (UTC)

  That was an interesting discussion. It gives the reason for 90 days - a concern that someone could "vandalize" an important article by slipping in a NOINDEX. To mitigate that, NOINDEX is ignored on "old" articles and only works on "new" articles. There was an assumption that articles would be patrolled within 90 days. MB 08:01, 18 June 2022 (UTC)

  That could be handled separately by an edit filter that detects edits introducing NOINDEX in mainspace. MarioGom (talk) 08:30, 18 June 2022 (UTC)

  Hmm. I wonder, how tightly coupled are $wgPageTriageMaxAge and __NOINDEX__? I assumed they were separate, each having their own max duration, but it's possible that their durations are controlled by the same setting. Or maybe a wgPageTriageMaxAge = 365 would place a NOINDEX but then the NOINDEX would still be set to 90 and that would defeat the purpose.

  I also wonder if it'd be technically feasible to go over 365 days. One reason I chose that number is I know that the SQL table pagetriage_log_table only keeps 365 days of data,^[1] and I wonder if going over that might cause problems. –Novem Linguae (talk) 08:51, 18 June 2022 (UTC)

  Ping MusikAnimal. Was wondering if you could weigh in again, if you know offhand. Thanks! –Novem Linguae (talk) 18:05, 18 June 2022 (UTC)

  @Novem Linguae I'm not aware of a time limit on __NOINDEX__, or at least it doesn't seem to be documented. I didn't read all of the lengthy discussion but it seemed at the time, there were separate, unrelated issues where basically NOINDEX wasn't working as expected. That appeared to have been resolved as well. $wgPageTriageMaxAge acts completely independently, judging by the code. — MusikAnimal ^talk 21:40, 20 June 2022 (UTC)

Sources
^ https://quarry.wmcloud.org/query/60628

This makes sense, if it's technically feasible. MarioGom (talk) 19:43, 17 June 2022 (UTC)

Is it possible to have a max age based on categories? BLPs, for instance, shouldn't be indexed at all until reviewed. ScottishFinnishRadish (talk) 19:45, 17 June 2022 (UTC)

The biggest issue may not be technical. This is a quote from Kudpung: "otherwise you'll just have to make an argument at the WMF to extend the un-patrolled period, and believe me, that would be no easy task, even if you have friends there and meet them personally - been there, done that" — Preceding unsigned comment added by MB (talk • contribs) 17:16, June 17, 2022 (UTC)

I'm in favor, if it's technically feasible. Not sure what to do if WMF is problematic, but I'd hope we could work through any issues. Not sure what the issue might be - if it's "that's the way it's always been," then why hide IP addresses that have always been open, eh? Geoff | ^{Who, me?} 21:24, 17 June 2022 (UTC)

• It helps, especially as applicable to PE in that the client can't see the article so no payment will be forthcoming. Atsme 💬 📧 21:30, 17 June 2022 (UTC)

  This is a bandage over a gaping would: the difficulty due to current policies (particularly WP:BEFORE) posed in NPP. But it's better than nothing. — rsjaffe 🗣️ 23:51, 17 June 2022 (UTC)

• I agree, rsjaffe, we still need to patch the hole that allows unsourced articles to slip into mainspace, and also work on a more efficient system for handling redirects. Atsme 💬 📧 00:08, 18 June 2022 (UTC)

  Now that I think about it, changing this will actually help. Right now, no one other than the reviewers has "skin in the game". No one else has an incentive to fix this. With NOINDEX, we can motivate those who care about search engines. Might provide a touch of support to meaningful changes. — rsjaffe 🗣️ 00:14, 18 June 2022 (UTC)

One of my favorite sayings is that deadlines spur action. So would this mean that some patrolling that happens because people are concerned about a page being indexed wouldn't happen or would it allow a more stable operation of the queue before something gets indexed? Best, Barkeep49 (talk) 00:48, 18 June 2022 (UTC)

I've given up on deadlines. I patrol and find 1) stuff that belongs in Wikipedia, 2) bad stuff (e.g., UPE, sockpuppetry, obvious non-notable). Anything in the middle, particularly if it is sports related, I just pass on and let it age out. An interesting thing I did was look at the queue starting 31 days out. articles that are not obviously notable in 1) sports category or 2) foreign-language-reference-supported predominate. — rsjaffe 🗣️ 01:25, 18 June 2022 (UTC)

My intention was that people who WANT their article to get any attention (ie: Search) would ensure the article is in fit condition for NPP to validate them. At that point (and not automatically after 90 days), the article would be searchable and therefore properly 'live'. This both spurs creators to ensure pages are up to par and ensures that pages that aren't are not searchable and therefore limits the need to send articles to draftification (easing the burden on AfC), limits the need to go to AfD except in the most extreme/certain to pass cases and ensures that people aren't searching WP and finding utter rubbish. Additionally, lifting the burden for performing BEFORE on NPP means that the article AS PRESENTED is patrolled - not the notional article that could have been should the creator have actually looked for the sources the article needs - reducing burden on the small number of patrollers and increasing the requirements for the large number of page creators to actually create viable pages. Thanks, Novem Linguae for picking it up. Best Alexandermcnabb (talk) 14:30, 18 June 2022 (UTC)

• @Barkeep49, I'm thinking that if exposure is the main purpose of creating an article, then it holds to reason that if it isn't being seen (indexed), the creator will be incentivized to fix it. OTH, if it's a BOT creation, or one the creator doesn't give a flip about, then it's highly unlikely that (a) it's worthy of inclusion or (b) that the issues will actually be fixed; both of which warrant CSD or PROD. Any article that is notable and worthy of inclusion will be sourced, but let's not waste time on the symptoms and go straight to the root of the problem. An unsourced article never should have made it into mainspace. If we patch that hole, and prevent unsourced articles from slipping through the cracks, a lot of our problems are solved. I'm not sure where the notion of publish it anyway actually originated, but it defies our core content policies, and taxes the very core of NPP volunteerism without fair representation. As rsjaffe put it, the bulk of those who oppose deletion don't have any "skin in the game", or a "dog in the fight". This whole scenario is one of the reasons we need the stats I've asked about – we need a cost vs benefit analysis, so to speak, as it relates to the arguments for keeping unsourced articles that have been denied deletion at CSD & PROD – where did they finally end up? Did they get stuck in the NPP queue – go to AfD and were deleted – or did they actually get published with/without fixing the problems? Crafty editors will also take advantage of redirects to create articles in mainspace without drawing much attention. The redirects, reverts of redirects and those that lead to AfD are another issue – but I sincerely believe it's one we can fix at the root cause - PREVENTION, keep unsourced articles/stubs from ever seeing the light of day. Atsme 💬 📧 14:37, 18 June 2022 (UTC)

  Ultimately if more articles are being made than we have capacity to patrol it's going to be a problem at some point. Pushing out no index would give us more breathing room but not change that underlying issue. So we have to either increase capacity or decrease the number of new articles. So ultimately any increase in the NOINDEX time should be accompanied by some plan to change one of these things. Best, Barkeep49 (talk) 15:20, 18 June 2022 (UTC)

  I'm for decreasing the number of new articles, which is something we can do by heading them off at the pass; i.e. PREVENTION. A BOT could be created to assure each new article going into mainspace has at least 3 citations before it leaves Draft, or is directly created in mainspace, regardless of autopatrolled status. I don't know enough about the "theft" of redirects to address that issue - all I know is that it exists and it's a problem. Wbm1058 can probably explain it far better than I ever could. Adherence to WP:PAG and more CSD & PROD support from our admins will help to self-correct some of the other issues, as will getting more admins trained in NPP reviewing so that fewer CSD & PRODs will be rejected or sent to AfD. Redirects also need attention in an effort to make it more difficult to get a bad article back into mainspace which is another rather substantial prevailing issue. The various discussions at VPP demonstrates where a big part of the issues stem, including ambiguities and misunderstandings of PAGs topping the list. I also noticed that, for whatever reason, some editors don't have a "middle button" - they are either 100% inclusionist or 100% deletionist. What we need are more includelists. Atsme 💬 📧 15:56, 18 June 2022 (UTC)

  @Atsme: I'll give you an example case study – something I caught on my patrols and cleaned up this morning. I won't say exactly how I found it per "beans" though I do have a section on my user page where I list my work queues, and it was something on that list. Untangling the mess there was a time-consuming manual process which would be extremely difficult to automate. My focus has been on occasionally adding more patrols when I stumble across something that wasn't caught by any patrol I try to create a new patrol that finds other cases just like the one I stumbled onto. Aliana was first created 16 December 2007 as an article about an album by Aliana Lohan. This was deleted per Wikipedia:Articles for deletion/Aliana. Aliana was re-created 13 July 2017‎ as a redirect to Eliana via Articles for Creation. That redirect was usurped by OfTheUsername when they started a new article about Aliana, Texas (OfTheUsername later moved Aliana to Aliana, Texas: Proper naming.). That new article had been shuttled back & forth to draft space. I untangled all the crossed wires, and deemed the Texas planned community to not be a primary topic, so I made Aliana a disambiguation. I'm a "middle button" who generally leaves keep/delete decisions about articles like Aliana, Texas to others. But I did note that AIRIA Development Company might have an interest in promoting their planned community which is unlike the other communities listed on Template:Fort Bend County, Texas. I remember riding my bike through places like Crabb and Clodine on my bicycle rides west of Houston in the early to mid 1980s. OMG, Fulshear, Texas is a city with 16,000+ ppl now? I remember that place as not much more than a country corner with a BBQ joint where we ate lunch either during or after our ride (back then it had a population under 600). – wbm1058 (talk) 17:51, 18 June 2022 (UTC)

  It's a can of worms. Atsme 💬 📧 18:27, 18 June 2022 (UTC)

  bro what. I made the Aliana article independently. I don't work for/connected to AIRIA Development company or affiliates or anything. Sorry about the redirection and stuff I tried to make it a draft but then it acted weird. My bad. OfTheUsername (talk) 18:47, 18 June 2022 (UTC)

  Is there a page that shows page creation by user metrics (Daily, Weekly, Monthly)? Perhaps some users could be evaluated and "nominated" for Autopatrol by the community.Slywriter (talk) 15:29, 18 June 2022 (UTC)

  @Slywriter: Wikipedia:Database reports/Editors eligible for Autopatrol privilege maybe? – Joe (talk) 18:36, 18 June 2022 (UTC)

  I discovered that there used to exist an edit filter to flag unsourced new articles, though it was decommissioned in 2012 with the comment "disabling, no real use" (?). There's also a fairly recent unanswered query as to whether the filter should be reinstated. While this wouldn't be a universal solution, I believe (in agreement with the recent post) that warning users who are about to publish an unsourced article would either lead them to add sources or refrain from publishing. The filter also got quite a number of hits before it was deleted, but I believe it preceded ACTRIAL. Would reinstating this filter be at least a partial solution? ComplexRational (talk) 17:10, 18 June 2022 (UTC)

  Interesting discovery. I wonder if it will also catch autopatrolled in mainspace or if it only works at AfC draft to mainspace? It should be a universal catch-all filter. No article should be in mainspace without a minimum of cited RS, even if it's just 2. Could it also catch sources that are unreliable by integrating User:Headbomb/unreliable and maybe even User:SuperHamster/CiteUnseen.js would prove useful? Atsme 💬 📧 17:28, 18 June 2022 (UTC)

  From what I see, the filter's old configuration did not target any specific user groups and was set to work for all mainspace pages, with built-in exceptions for pages that aren't supposed to have sources such as redirects and disambiguation pages. I'm unsure about autopatrolled – but in that case, there could be grounds for revocation of the permission. Regarding the scripts, I doubt they could be implemented in a filter because there's enormous potential for false positives/negatives and there are simply too many cases to cover (someone with more advanced programming skills, feel free to correct me though); reactivating the old filter would simply help in catching the most egregious cases. ComplexRational (talk) 17:53, 18 June 2022 (UTC)

  Quick tech note. The edit filter is computationally expensive and it would probably not be performant to look for more than a short list of the dozen or so most egregious unreliable sources. Which we already have some filters for, e.g. filter 869. –Novem Linguae (talk) 18:12, 18 June 2022 (UTC)

  How is the filter catching no sources? Is it using citation format, or reflist, or something of that nature? Atsme 💬 📧 18:32, 18 June 2022 (UTC)

  @Atsme: It flags any new article that doesn't have any of several character strings that would suggest either the presence of sources or a page not needing sources – this means flagging new pages not having any of <ref> tags, http/https, disambiguation in the title, #REDIRECT, etc. It doesn't discriminate types of sources, only whether any could be present. ComplexRational (talk) 18:45, 18 June 2022 (UTC)

• That 2012 RfC was a result of a couple of meetings I had with Jorm and Erik Möller over the development of New Page Triage, the working name for the new feed and curation software development. Characteristically Oliver Okeyes (WMF), jumped on the bandwaggon before any volunteers could could start the community discussion, and he later continually tried to block development right through to his leaving the community although there was a clear consensus (WereSpielChequers and Scottywong will remember all this).

'No Index until patrolled' was much like Jumpback which Oliver also promised and did nothing about and wasn’t resolved until TonyBallioni stepped in years later and it finally got boxed through at the WishList in 2019. Anyway, Extraordinary Writ, you can all blame me for the 90 days. When I was asked, it's what I suggested thinking it would be enough. A few years later we got ACTRIAL done which greatly reduced the flood of effluent but it wasn't long before the problems with patrollers started.

Per Barkeep49: Ultimately if more articles are being made than we have capacity to patrol it's going to be a problem at some point. Yes, pushing out the 90 days would certainly just be a palliative. First off - and I know you'll all hate me for this - some stats are needed over a sample period: how many articles are kept immediately, how many are draftified, how many are PRODed, how many are CSDd and AfDd? Or did someone do that already and I missed it? Kudpung กุดผึ้ง (talk) 10:23, 19 June 2022 (UTC)

I think that extending the 90 days is beyond logical....knowing what we now know, the short 90 day number defeats the whole purpose of that (good) feature and makes it pointless. North8000 (talk) 10:33, 19 June 2022 (UTC)

The suggestion is not to push 90 days out, Kudpung, but institute 'No review = No Search' as a flat deal and make that public, possibly with some guidance on notability and sourcing that lets new page creators know that their page will not be searchable until it reaches a minimum standard of notability/sourcing and has been patrolled. I'm not sure where stats help in this - we can all see the scale of the problem and this would apply some systemic leverage for creators to focus on sourcing. This also means sub-standard articles aren't 'rewarded' by being searchable after 90 days whether reviewed or not - when right now we have little hope of getting to articles in 90 days. The best stat I can see is the NPP queue and how little we are managing to reduce it! Best Alexandermcnabb (talk) 13:12, 19 June 2022 (UTC)

I think it's quite clear, Alex, that at least Barkeep49 certainly concur that a palliative would not have much effect. One advantage, as the potted NPP history I wrote above is intended to demonstrate, is that the en.Wiki and a few others have since asserted their maturity vis-à-vis the WMF and can now instigate their own controls and policies. 'No review = No Search' as a flat deal is not only an excellent suggestion, but where no amount whipping all the 750 reviewers into action is ever going to work, it's also the only solution. Just do it. It's technically a doddle so just ask at Phab for the switch to be thrown. OTOH, if the Grand Masters of Phab decide you need a community consensus first, you'll have get one. ACTRIAL is a seminal example of changing outdated 'founding principle' policy; we had some very heavy participation and extremely convincing consensus each time we ran a debate for it, but only because our mission statements were armed with a lot of significant stats and very carefully crafted proposals. Now its time for some action. Kudpung กุดผึ้ง (talk) 15:21, 19 June 2022 (UTC)

Now, I can just about get my head around NPP and AfD, and I can even create the odd page (bless him, but it was User:TonyBallioni wot granted me autopatrolled, as you mention him) but this Phab switchy stuff is, to be honest, a bit beyond me. Have you SEEN what a mess I can make with source editing? I'm not sure I'm the person to actually take this one forward, but am perfectly happy to have made the suggestion if others want to activate it - and just as happy to support. But as for anything beyond tinkering with content, I'm really sure it's not my long suit... Best Alexandermcnabb (talk) 15:56, 19 June 2022 (UTC)

I'll open a phab request on this. MB 18:56, 19 June 2022 (UTC)

 Done here MB 23:06, 19 June 2022 (UTC)

Thank you @MB ! :) Alexandermcnabb (talk) 06:59, 20 June 2022 (UTC)

Yes, thank you MB for taking the initiative. Personally, I would have asked for indefinite 'NO INDEX' and see what the WMF offered. It's always better to ask for more and then negotiate down if held against the wall by the throat. That said, if you get 365 days it might just do the trick but I'm wary of being back here again in 5 years and asking for more. Anyway, by then Wikipedia might be dead, and so might I ;) Kudpung กุดผึ้ง (talk) 11:46, 20 June 2022 (UTC)

I did ask for INDEFINITE (as you know now that you have been to the phab ticket, just clarifying here for others). There is already a suggestion there for 365 days, and the task was renamed to reflect that :( MB 13:46, 20 June 2022 (UTC)

Yes, I realise that now. All the fun of the fair, just as I predicted.

The Phab request has now been marked as 'stalled'. I hope enough people are following this because the devs are going to need a lot of convincing this is necessary. Kudpung กุดผึ้ง (talk) 14:03, 20 June 2022 (UTC)

It also says a "local discussion" is underway. If that means a private discussion among devs, that is not transparent. All our discussions on this are public. MB 14:21, 20 June 2022 (UTC)

That is classic WMF dev-speak. There is nothing for them to discuss. It's their way of finding another ruse for stalling. They are pretending - like I said above - that the whole thing needs yet another RfC. Oh, I know Phab so well - and Bugzilla, its predecessor. So do Scottywong and The Blade of the Northern Lights. Kudpung กุดผึ้ง (talk) 14:54, 20 June 2022 (UTC)

Well, to be fair, the phab ticket has only been open for a day or two, and it doesn't look like anyone has said anything like "we're not going to do this." So, I'd cut them some slack and give them a reasonable amount of time to figure out how to make the change without introducing any unexpected consequences. If they do eventually refuse to make the change, there are probably ways for us to make this happen on our own, without help from the devs. It wouldn't be nearly as efficient or elegant, but you could have a bot automatically add a template to all new articles that ensures they're not indexed, and then removes that template once the article is patrolled. It would be a silly way to do it, but it's possible if the devs put up a brick wall. But from what I can tell, we're not yet anywhere near the point of needing to contemplate such actions. Give them a week or so to figure out what they're gonna do. —⁠ScottyWong⁠— 18:04, 20 June 2022 (UTC)

I opened the phab and asked that the 2012 RFC, which called for unpatrolled articles to be NOINDEXED (indefinitely, until patrolled) be implemented. There was some pretty strong support for that here. In follow-up discussion at Wikipedia:Page Curation/Suggested improvements#Extend NOINDEX beyond 90 days, Novem Linguae and MusikAnimal are suggesting we not go that far and start with 6 months or a year instead of indefinite, and suggest a broader discussion since the RFC was 10 years ago. I don't think more discussion is necessary here, but how about a poll to see if we have a clear local consensus before discussing at VPP: MB 18:50, 21 June 2022 (UTC)

• 180 days
• 365 days
• indefinite

---

• Anything is fine with me, as long as we as NPPs coalesce around a particular number before we take this to WP:VPR. MusikAnimal recommends 180 days. I originally recommended 365 days. There is an increase in the ease of the patch if we use an integer number, since indefinite would require custom code. –Novem Linguae (talk) 18:59, 21 June 2022 (UTC)

  On Jun 23, someone submitted a patch to allow wgPageTriageMaxAge to be set to infinite easily, so there is no longer a technical barrier to implementing infinite if we desire. –Novem Linguae (talk) 07:52, 23 June 2022 (UTC)

@Chris troutman, Extraordinary Writ, MarioGom, Atsme, Barkeep49, Rsjaffe, Kudpung, North8000, Alexandermcnabb, and Scottywong: Pinging other participants in the discussion, please state your preference as to the time period. MB 19:31, 22 June 2022 (UTC)

I was going to suggest 180 days when I saw the section title; 365 also seems fine to me and adds more of a buffer in case our backlog situation gets worse. Given that indefinite is apparently more technically difficult, I think it makes sense to pick a cutoff time, even if it's a bit arbitrary. As a sidebar: do we know how the cutoff currently affects articles created from redirects that were created more than 90 days ago? They sit in the back of the queue and it's not clear to me if they get deindexed or not. _signed, Rosguill ^talk 19:43, 22 June 2022 (UTC)

365, though I prefer indefinite. I’m thinking about how that would affect the article writers, as I want to see a strong incentive to add notability sources.

on the other hand, if we fix the workflow, the noindex duration would become less important. — rsjaffe 🗣️ 19:52, 22 June 2022 (UTC)

• 180 is enough - ^{adding that I'm ok with 365 or even indef 03:04, 23 June 2022 (UTC)} And I also have questions. Is there a way to check for dupes from time to time while an article is in draft? I've actually come across a few dupes that were in main space and also in draft. Typically, truly notable topics don't just disappear because one attempt failed. I don't see WP running out of articles because we had to draftify a few problematic or unfinished stubs/articles. I was also wondering if there's a way we can promote those types of articles to educators who want to teach the WP editing process, and can make good use of them to show students where the problems are, and how to make them main space ready? Atsme 💬 📧 20:19, 22 June 2022 (UTC)
• 365 Anything less than indefinite creates a perverse incentive for article authors to overwhelm our ability to patrol but I think a calendar year is sufficient time to patrol, especially since implementation of 365 days is apparently technically easier. Chris Troutman (talk) 20:23, 22 June 2022 (UTC)
• 90 days is a big problem.....large amounts of unreviewed articles go past that. Indefinite is best and sort of needed if it's looking at the creation date of the page because the page creation date on articles created by converting a redirect or moving from a draft space is the date of creation of the draft or redirect which can be 10 years ago for a page that just showed up as an article space yesterday. Beyond 180 days you still also have a lot of completely new articles in the NPP cue.....usually ones several NPP'ers looked at and avoided. So indefinite is best, 365 is second best, 180 days is third best. 90 days is far far too short. North8000 (talk) 20:35, 22 June 2022 (UTC)
• I'm opposed to indefinite for philosophical reasons (I think deadlines are helpful to spurring volunteer action and I have a soft spot for our "anyone can contribute" roots) and practical (I don't think the foundation would go for it). No preference between 180 or 365. Best, Barkeep49 (talk) 20:42, 22 June 2022 (UTC)
• 180 with adjustment to filter or a separate report that shows articles over 90 days (actual 90 days, not un-redirects so 2005 articles appear). Between the two, should be able to keep anything egregious out of indexing. Slywriter (talk) 20:53, 22 June 2022 (UTC)
• Slight preference for 365. If the backlog gets beyond that, then the deadline would be the least of our problems for NPP. MarioGom (talk) 21:45, 22 June 2022 (UTC)
• Indefinite or 365 as a second choice if the former is not possible. Someone, sorry I can't recall who, made the excellent point much earlier that article creators - especially UPE, who won't get paid until it goes 'live' - have a much bigger vested interest in creating better articles - I echo User:North8000's concerns about redirects - is the timer indeed article creation or is it reset by queue addition? Sorry, me no teknikal... Two 'sorries' in one sentence - spot the Brit. Best Alexandermcnabb (talk) 04:37, 23 June 2022 (UTC)

Indefinite or 365 as a second choice if the former is not possible. We should not be offering articles to google if they have not been patrolled, since so much stuff I come across violates core content policies. (t · c) buidhe 05:22, 23 June 2022 (UTC)

• Indefinite or 365 as a second choice if the former is not possible. As there are no chances whatsoever of 'spurring volunteer action' with or without backlog drives or canvassing for new reviewers. This is a time to be pragmatic and not wax philosophical. 'Indefinite' is not a hurdle and it would avoid having to go back and ask for more next year. As I said earlier, we should not be suggesting anything alternative to 'indefinite', but this RfC unfortunately now opens up the decision by the 'gatekeepers' at the WMF and allow them to beat us down to something that can no longer be negotiated down to when they hold the volunteer community by the throat against the wall - and they will. Kudpung กุดผึ้ง (talk) 07:34, 23 June 2022 (UTC)
• Update: it looks as if the devs are going to do 'indefinite' after all. Kudpung กุดผึ้ง (talk) 07:59, 23 June 2022 (UTC)

• yay! >little indef dance< Best Alexandermcnabb (talk) 08:19, 23 June 2022 (UTC)

• Indefinite. I never understood why we had a limit. 90 days, 180 days, a year... it doesn't really make a difference. Articles should not be searchable until they've been checked by at least one other human being. – Joe (talk) 08:55, 23 June 2022 (UTC)
• Indefinite in light of the report that its implementation is technically possible. Unpatrolled pages with potential issues should not be indexed under any circumstances, though I also support a separate report (suggested by Slywriter) for pages older than 90 days so that they don't get lost in the queue and can easily draw attention from multiple reviewers if necessary. ComplexRational (talk) 12:09, 23 June 2022 (UTC)

BTW I did some looking and also from my sometimes work at the back end of the que ....it looks like that back end of the "regular article" cue is somewhere around 9 months. There it looks like mostly articles that several NPP'ers looked at and decided not to handle. Lot's of what looks like "edge case that should probably go to AFD but I don't want to be the one to decide and do that". Back around a year (or older) it becomes more articles that have a old birth date from their birth as a redirect or draft, but where the actual article is much newer. North8000 (talk) 13:20, 23 June 2022 (UTC)

Off topic but agree, User:North8000, I've spent the last 10 days at the back end of the horse and the resulting AfDs are at times attracting controversy and a lively debate! Best Alexandermcnabb (talk) 05:28, 24 June 2022 (UTC)

• Indefinite or 365 would encapsulate the maximum size of the NPP queue that I've seen to date. Either one would suit me down to the ground. scope_creep^Talk 22:53, 29 June 2022 (UTC)
• 180 days would align with the 6 month limit of draft space. The word Wiki means quick and so talk of years is absurd. And an indefinite limit would be a surrender, encouraging the idea that it's safe to let backlogs climb to infinity. The lack of any sense of urgency would tend to kill motivation so the patrol process would fail even more than it does currently. Andrew🐉(talk) 22:19, 1 July 2022 (UTC)
• 365 days . which will be long enough to deal with the material. "Infinite is more likely to lead to complications. DGG ( talk ) 23:34, 3 July 2022 (UTC)

---

By my count, no limit (indefinite) has clear consensus (nine including those that said any of the choices were OK, three said 180/365, and no one objected to increasing from 90). I will put a notification at WP:VPR. MB 19:47, 23 June 2022 (UTC)

No additional comments. Will update the Phab ticket. MB 04:54, 26 June 2022 (UTC)

I think "indefinite" is a bad idea, slight preference for 180, but OK with 365. Creating and distributing content is in our core mission - that it could be indefinitely hampered because of slow or insufficient volunteers is sort of anti-wiki. If we are going to be fine hosting bad content for an entire year, then asking some search engines to please look the other way past that time is diminishing. — xaosflux ^Talk 13:13, 29 June 2022 (UTC)

Follow up. So here is a use-case scenario:

1. An editor, Alice, notices we are lacking an article on something she read about Amanita muscaria var. flavivolvata
2. Alice writes up a new short article on this, (assuming good faith it is a fine start-class article)
3. It sits noindexed - making it harder for the general public to find
4. This noindex stays forever until some other volunteer volunteers to approve the page

I'm not really a fan of that workflow. — xaosflux ^Talk 14:13, 30 June 2022 (UTC)

Also, as this is a change that impacts almost all editors - as I noted at the just recently listed VP posing, this doesn't seem to be well advertised. — xaosflux ^Talk 13:14, 29 June 2022 (UTC)

I thought the idea of this discussion was to workshop a proposal to take to the village pump, at which point it would be widely advertised. – Joe (talk) 13:23, 29 June 2022 (UTC)

Oh I see, it was taken to VPP. @MB: I think Xaosflux is right, your post at VPP doesn't show sufficient consensus for this idea. It should have been formatted as a clear proposal and advertised at WP:CENT, etc. Instead it reads like you're informing VPP of a decision that's already been made (which isn't the case – the heading of this section is "Picking a specific # of days for NOINDEX proposal at Village Pump"). – Joe (talk) 13:34, 29 June 2022 (UTC)

Xaosflux and Joe Roe, I echo what Kudpung said below. There was clear consensus at NPP here to reaffirm the prior RFC. I didn't think this had sufficient likelihood of being controversial enough to warrant forking into a separate VPP discussion and/or new RFC. I placed a neutrally worded notice there about this discussion and asked for further comments, of which there have been almost none. This change does not impact editors; people who are concerned about whether their article is indexed are usually trying to promote something which is clearly against our core policies. They should not be rewarded in getting added visibility via search engines after some arbitrary time period because NPP volunteeers are overwhelmed by the quantity of poorly sourced and difficult to review articles. NPP is trying to address the backlog and I do not believe will be any less motivated to do so when this is implemented. We are just trying to improve the encyclopedia by closing this way to get unvetteted articles fully into mainspace. I also note that any newbie who follows our suggestions and uses AFC is blocked from publishing trash, but someone a little more sophisticated bypasses AFC and has a good chance of having their trash live and indexed. This is a step towards equalizing these processes. MB 23:56, 29 June 2022 (UTC)

This venue can certainly host the discussion - the main point I was raising is that it should be well advertised. — xaosflux ^Talk 14:05, 30 June 2022 (UTC)

I agree with you, Xaosflux, and even suggested it back on June 21st. Atsme 💬 📧 14:12, 30 June 2022 (UTC)

• @Xaosflux and Joe Roe:, IMO this is a purely local NPP issue, and an essential software request. I do not see how this is a change that impacts almost all editors; it is directly related to the workload of the NPP process and its inability to keep up with the stream of mostly inadmissible, or at best, articles possibly of relative unimportance, that nowadays make up the bulk of new submissions. ACPERM (also an NPP initiative) greatly reduced the tide of effluent a couple of years ago but it's already grown again to its previous proportions. Indexing for search engines may be a coveted bonus for some creators, but it is not a right. I do not understand why challenging improvements to NPP would be particularly helpful, or why the few genuinely active NPPers should be constantly be made to feel they don't do enough. Prolific reviewers are being lost already through burnout. Kudpung กุดผึ้ง (talk) 22:14, 29 June 2022 (UTC)

  Am I reading that currently volunteers are encouraged to quickly patrol new pages due to the current settings, yet by extending the setting they will be less encouraged to quickly process new submissions - especially by extending the setting to forever? Reviewing new pages is indeed important and should be done regardless of the request to external indexing engines - if we are hosting bad information it should be dealt with as soon as possible. — xaosflux ^Talk 22:57, 29 June 2022 (UTC)

@Xaosflux: I think you are most likely reading this wrong. Your comment: 'Creating and distributing content is in our core mission ' is correct, but hampering it due to preventing NPP from doing its work by challenging its requests for improvement to the process is, IMHO, decidedly 'anti-Wiki'. When I created the NPP user right in October 2016‎, it was with the express intent of introducing experienced and high quality patrolling into the system and for no other reason - it was certainly not intended to make it slower! I fail to understand why the WMF is determined to undermine its own objectives.

Hence the local Wikipedias and their task-force volunteers are obliged to take matters into their own hands like they would have done for ACTRIAL if the WMF had not acquiesced after 10 years of bitter wrangling. IMO, WMF employees should not even be participating in these community discussions. Clearly the number of articles in the corpus is a far more important boast for the WMF than the quality and reliability of the content in them. The reason that so many inappropriate or totally unsuitable new pages are submitted is directly due to the WMF's refusal to do anything about it - despite the constant begging for a proper new user welcome page. Compared to some idipendent projects using MediaWiki, the Wikipedia is totally antiquated - a Model T Ford in terms of progress in information technology - and based on ideologies that now, after 20 years have little in common with today's reality: that the English Wikipedia is no longer short of content and the mediocre stuff can either wait or be stopped before it is created. Anyone who cares for Wikipedia and recognisess that NPP is a foundering process, is invited to come up with effective solutions rather than impede them, and to get cracking on implementing them.Kudpung กุดผึ้ง (talk) 23:47, 29 June 2022 (UTC)

• Update: I'm not sure if this was what the NPP community really wanted but the rollout that was scheduled by the WMF for next week appears has been successfully blocked. Kudpung กุดผึ้ง (talk) 22:59, 29 June 2022 (UTC)

  Kudz, are you talking about the 14 July Zoom meeting with the Trustees? Atsme 💬 📧 23:33, 29 June 2022 (UTC)

Atsme, I don't generally trust the Trustees much more than the WMF. I always got the impressions that the Trustees do the WMF's bidding and their main tool is a rubber stamp. I may be wrong, though, times may have changed. Question of which tail is wagging which dog. I don't follow what goes on there, and I have no time for tedious Zoom meetings. Kudpung กุดผึ้ง (talk) 00:17, 30 June 2022 (UTC)

@Kudpung: <sigh> Can you expand a bit? What happened and where? Geoff | ^{Who, me?} 23:09, 29 June 2022 (UTC)

@Glane23:, I can understand if not everyone knows what or where Phabricator is (it used to be called Bugzilla), so, <sigh>, here is the link to the Phab task again. Everything you need to know is there →

Tracked in Phabricator
Task T310974

Kudpung กุดผึ้ง (talk) 00:17, 30 June 2022 (UTC)

@Kudpung: Thank you kindly - that helps. It's been getting hard to find the trees in the thicket of this discussion. Geoff | ^{Who, me?} 12:23, 30 June 2022 (UTC)

• @Chris troutman, Extraordinary Writ, MarioGom, Atsme, Barkeep49, Rsjaffe, MB, North8000, Alexandermcnabb, Scottywong, Novem Linguae, and Buidhe: so what's happening now? Has everything stalled? With or without a backlog drive, 100s of totally unsourced articles in the feed are getting dangerously close to the current 90-day limit. Backlog drives never have a permanent impact and constantly need to be repeated. Maybe it's time to do something else - the ACTRIAL and its ACPERM were a resounding successes - perhaps now pushing 'autoconfirmed' out to XCON with a mandatory use of the Article Wizard might be an option to go for. Anyone can still edit Wikipedia, no one needs a PhD to do it, but as DGG says: the purpose is not just getting articles; it's teaching editors. This is much more difficult and time consuming, and the existing templates do a notably poor job of it, which clearly echoes what I was saying above at: The reason that so many inappropriate or totally unsuitable new pages are submitted is directly due to the WMF's refusal to do anything about it - despite the constant begging for a proper new user welcome page. [...] the English Wikipedia is no longer short of content and the mediocre stuff can either wait or be stopped before it is created. Kudpung กุดผึ้ง (talk) 09:28, 3 July 2022 (UTC)

  In addition to the backlog drive, the last two newsletters and Buidhe's recruitment efforts have attracted a number of a new patrollers, and I've been working through this list to find candidates for autopatrolled (I know we both have reservations about that right, but if nothing else it's effective at getting the backlog down). The backlog is going down now: by about 200 articles a day for the last ten days, which if sustained will get us under 10000 again by mid-July and theoretically to zero in a couple of months. As for permanent solutions... extended confirmed is a massive hurdle compared to autoconfirmed and I highly doubt you'd find consensus for an ACXCON. What I'm curious about is why we seemingly get cyclical backlogs like this every two years or so. We talk a lot about the number of reviewers and how many reviews they're doing, but there are other variables that could have just as much of an influence on the backlog: rate of article creation, proportion of articles autopatrolled, time taken to review each article, regularity of reviewing, etc. Maybe getting data on these would generate new ideas. – Joe (talk) 09:57, 3 July 2022 (UTC)

One issue that confuses us is assuming that the backlog number (which is very essential and useful) indicates more than it does. At any given moment, there are only about 10-20 days worth of manual reviews sitting in backlog. The tiniest shift in our overall "equation" (of incomming articles vs. reviews getting done) causes large changes in the backlog. But it's basically all that we have. Many of the the indicators that would also be very useful are not available. North8000 (talk) 10:38, 3 July 2022 (UTC)

The swings in the backlog over the last year or two directly correspond to some top reviewers quitting NPP or coming back. The top reviewers I am thinking of are Onel5969 and John B123. Their efforts are appreciated and they are missed. Not sure about trends over a longer time period. –Novem Linguae (talk) 11:01, 3 July 2022 (UTC)

You are getting to the main huge topic which I avoided trying to get into here.North8000 (talk) 11:37, 3 July 2022 (UTC)

That's certainly a recurring issue. I forget who corresponds to which spike, but the departure of SwisterTwister, for example, way back in 2016, eventually led to a backlog of more than 22,000 articles. But I think it raises more questions than it answers. Why do we end up depending so heavily on one or two reviewers, who inevitably burn out? When the backlog is low, for example, does one person taking all the low-hanging fruit lessen the engagement of other reviewers and set us up for a crisis down the line? – Joe (talk) 11:38, 3 July 2022 (UTC)

OK, so I'll dive in. Wikipedia runs on volunteers doing what they enjoy doing, (with some "doing it for a good cause" thrown into that "enjoy" equation) For most reviewers, due to the nature of things, reviewing is an extremely painful, slow process. Then after they hit a certain threshold, where they have fluency in the zillion words of guidelines, policies, venues, have learned that it's a big fuzzy system where they have to make judgement calls, where they need to have a thick skin, and where they realize that they don't have to feel guilty about not reviewing for all of the areas where the article needs fixing / development then it becomes less slow and painful and the evolve into one of the reviewers with bigger numbers who numerically get most of this week's work done. And once in a while they evolve further in all of theses areas and also put in more time they become one of the huge-number rock stars....a handful of them could knock a 14k backlog down to 4k in a week. And then when they leave the opposite can happen. Aside from getting a few things elsewhere in Wikipedia fixed, our best approach would be to get good experienced people started, and then help them develop into the category where it becomes less painful and slow and guilt-ridden to review articles. It's not just about getting the bunch of articles that is in the backlog done, it's about attaining & maintaining the horsepower to keep it in check painlessly. North8000 (talk) 12:21, 3 July 2022 (UTC)

It's cyclical in that BOTs are being used (they get caught & stopped, but over time, new ones are introduced and resume the spamming), plus we're getting translations from other Wikis by the 100s, and we're getting a lot of new article submissions from South Asia and the Middle East, which creates more redirects and AfDs. Add to that, seasonal sports, new movies and lists. Atsme 💬 📧 15:12, 3 July 2022 (UTC)

A proper new user welcome page would probably help a bit. Something that is displayed to a user when they're about to create their first new article, pointing them in all the right directions and setting their expectations. Perhaps it's worthwhile for someone to put together a page where we can brainstorm all the requirements for such a page, and maybe even put together a draft of the page itself and present it either to the wider community or WMF. Or maybe this has been done already? I think it's a bit unrealistic to just tell the WMF to "make a better welcome page" without even telling them what problems we're trying to solve or giving any suggestions for what should be on that page. —⁠ScottyWong⁠— 20:45, 3 July 2022 (UTC)

I did it Scottywong, several times, that why I keep mentioning it. But it's got swept under the carpet and lost in the annals of time and on dead Mac computers, just like the Article Wizard that I painstakingly rewrote and a newbie just went and reverted it all. I have worked successfully with the WMF to get several things done for NPP, but my main complaint is that the volunteers are expected be doing the leg work (i.e. coding) on things that should be paid for, but AFAIK, no one among the 550 paid staff has skills in developing things within the scope of UX and they don't appreciate it very much when someone hands them a beautiful GUI and says, now code this in MediaWiki for us. Kudpung กุดผึ้ง (talk) 21:05, 3 July 2022 (UTC)

Do any of these drafts still exist somewhere on WP? —⁠ScottyWong⁠— 10:56, 4 July 2022 (UTC)

@Scottywong: 'swept under the carpet and lost in the annals of time', but I expect I could recreate them easily enough - reluctantly. Kudpung กุดผึ้ง Kudpung กุดผึ้ง (talk) 17:35, 4 July 2022 (UTC)

• If we follow exactly the NPP instructions, we will never be able to handle things; when we have come near doing so is by using judgement for which articles are fundamentally ok and which aren't, and proceeding accordingly. Judging this takes experience, not just good understanding of the rules. Similarly with editors--it makes not minutes but hours to really teach someone, and I try it more than most, but I have never attempted more than 1 or 2 per week. (I've mostly worked at AfC not NPP the last few years, but I consider that almost identical, except that at NPP its safe to assume 90% of the material is coi.

I have lately become much less willing to continue. In a few special areas I am the only one handling them fluently, or even handling them at all, is extremely discouraging--and I'm sure many experienced reviewers find themselves similar trying to cope with their own areas of interest almost unaided. The likely result is that many more articles will be mistakenly accepted or rejected. AfD is no substitute, for it requires the at least equal judgment. We will end by discouraging good contributors in unusual areas; we will also be letting through much more junk, but at least those can be dealt with later along with the half million similar junk accumulated over 21 years. Finding new contributors to replace those who get discouraged is much more difficult. I never expected to do this work as long as I've been doing, which is now 15 years. I had earlier expected that by now we would have new people who could take over--and there are a few, but not enough to replace those of us who are leaving--and the ones who do, mostly need further experience and background to work accurately enough. For people like me or Kudpung, WP is perhaps the most worthwhile work we've done in our lives, but we need to gradually stop before we find ourselves forced to. DGG ( talk ) 03:03, 4 July 2022 (UTC)

Thank you for that DGG, I'm sure it will strike a chord with our long-time reviewers and NPP/AfC activists.Wikipedia has matured and most of the traditional encyclopedic areas are covered and maintained by topic experts who quietly get on with their work. As the Internet becomes more accessible in developing regions and smartphones can be bought for a few dollars, the vast majority of today's new article submissions mainly comprises football (soccer) bios, other sports people and events, Bollywood, hardly intelligible English, vanity pages, spam, and pure junk. This makes the patrolling of new pages a tedious, boring, and soul destroying task and an increasing number of articles being pushed into draftspace.

Most new users (and some older ones too) resent being taught - believing it's their right to dump what they like in Wikipedia with the expectation that someone will clean their stuff up for them. It might be The Encyclopedia Anyone Can Edit, but editing here is still a privilege and there are rules to be followed. It's hardly a wonder that those who apply for the NPP user right give up so soon, leaving 90% of the work to 10% of the patrollers who then burn out and leave anyway. Like DGG, I'm sure that most patrollers go for the low-hanging fruit and/or topics in their own knowledge areas; I know I do.

Unfortunately users like DGG and me are no longer spring chickens and very few of the current active reviewers have a long institutional memory or solid experience. As the curation tools get better (and they are a vast improvement on what we were using 12 or 15 years ago) the rate of detection of abuse of privileges gets better and this has led to the alarming discovery that even after the Orangemoody affair a few years ago, we are probably still only scratching the surface. . Kudpung กุดผึ้ง (talk) 05:04, 4 July 2022 (UTC)

It looks like there isn't clear consensus on how much notification/discussion is needed to determine the consensus on this issue. The hangup really is about indefinite, which is favored philosophically by most NPPers to ensure nothing is externally visible by without review. Since there is little to no opposition to extending from 90 days, I just asked at the phab to implement 365 days at least as an interim step. I think we should take that for now if we can get it to give some immediate relief. MB 17:54, 5 July 2022 (UTC)

Perhaps we can get someone uninvolved to do a compromise closing - it can always be revisited. From above there seem to be 2 very-related issues that are going on: (a) Pages that aren't reviewed for a 90 days fall off the reviewing tool view. I don't think there is anyone that objects to making that longer of itself. (b) Pages that aren't reviewed for 90 days become indexible - that is what has more differing opinions. Now, these appear to be very linked in that (a) seems to just be a view of pages in (b), but if they were divorced from each other (a) being indefinite seems to be fine while values for (b) get hashed out. I don't think the system currently supports that though? — xaosflux ^Talk 19:04, 5 July 2022 (UTC)

(a) shouldn't be an issue. Special:NewPagesFeed shows all unreviewed pages regardless of age. I believe this discussion has been entirely about (b). –Novem Linguae (talk) 21:22, 5 July 2022 (UTC)

@Novem Linguae so there is nothing that will hinder the patrollers from continuing to patrol pages and have a queue of unpatrolled pages? Some of the comments above suggested that this would be hampered. — xaosflux ^Talk 21:32, 5 July 2022 (UTC)

Xaosflux, as NL said above, this is entirely about (b). Articles never fall off the reviewing tool view. For example, I just looked at the NPP feed and there are articles going back to 2007 - but those are usually (or probably always) redirects newly turned into articles that still carry the original creation date. The oldest "new" article in the queue is from January 22 of this year. I assure you that in your scenario above, Alice's "fine start-class article" would be reviewed promptly. There are always some reviewers who look at the newest articles and pick off the "lowest hanging fruit". I do that myself in a few topic areas whenever I have a few spare minutes. The old articles that are still unreviewed (and those that we want to remain no-indexed) have usually been looked at by several reviewers, are often stubs, and usually have tags for notability, possible UPE, possible copyvio, etc. These get held up until someone comes along who is willing to spend the time looking for additional sources, translating foreign languages sources, etc. and determine it is fine, or become confident enough to send it to AFD. There has been a lot of VP discussion on shifting the burden for proving notability to the article creator and allowing more liberal draftification of articles that fall short based on their present state (the sources in the article), but that is unlikely to gain consensus. So for the time being, we are stuck here with a lot of difficult articles to review. As having a WP article is so valuable today, there is an endless stream of new articles on NN people and companies. These promotional type articles especially should not be indexed until they have passed NPP. Hope that helps explain things better. MB 23:29, 5 July 2022 (UTC)

Yes, so there is nothing that is preventing patrollers from patrolling, and this is all about if we should extend the auto-indexing-of-unpatrolled value. That is what I expected was going on - but was trying to be sure to not miss anything in the comments above suggesting that this proposal only impacts reviewers, while it actually has very little impact on their own volunteer workflow - it impacts authors and readers. I contributed above and am personally fine with some of he proposed extensions. — xaosflux ^Talk 23:39, 5 July 2022 (UTC)

This is a matter of perspective. This does not impact reviewers' workflow, but it diminishes their work if there is a backdoor way to get a fully-visible WP article. This is another reason (and there are others) for people to say why bother with NPP and go do something else. The only "impact" to readers and authors is that borderline articles are harder to find. IMO, people who care about seeing their article appear in a google search are probably trying to promote something - and that shouldn't be a priority to us. MB 00:23, 6 July 2022 (UTC)

I already supported extending it above, was just making sure we didn't have something else going on that breaks the workflow unnecessarily. For example, we have a cutoff on other RCP workflows - but we have a much larger technical challenge trying to extend the entire RCP tables much further as the incoming data is much higher. — xaosflux ^Talk 01:09, 6 July 2022 (UTC)

You supported extending it only to 180 or 365, and if I am not mistaken, are one of only 3-4, and probably the most vocal, opponents of going indefinite. The phab is on hold pending some indication that there is a "community consensus". Although indefinite is still a topic for discussion, I hope extending to 365 is recognized as having clear support and this, at least, is implemented ASAP. MB 01:42, 6 July 2022 (UTC)

@MB to be clear, my main being "vocal" part is that there should be current community support for this change, whatever the value. Yes, I expressed a preference for something not-indefinite, however that's just my quiet voice :) The discussion above does seem to be trending to saying 365 is an acceptable first step, and why I suggested someone uninvolved may be able to find a compromise closure. — xaosflux ^Talk 10:08, 6 July 2022 (UTC)

With respect, I think you're making a bit of a mountain out of a molehill MB. You asked people to "[pick] a specific # of days for NOINDEX proposal at Village Pump" and we decided on indefinite. So let's just go ahead and make the proposal at the village pump. I think it's very likely to be supported (to be safe we could propose 365 days as an option B per xaosflux) and it's much easier than trying to wikilawyer or badger the MW devs into doing it without a clear, recent consensus. I'd be happy to make the proposal myself, if it's not stepping on your toes. – Joe (talk) 11:08, 6 July 2022 (UTC)

Keep in mind that VP Discussions are discussions - sure you can put up "Should noindex be indefinite until patrolled?" but respondents are free to say more than yes (∞) or no (90). — xaosflux ^Talk 13:18, 6 July 2022 (UTC)

• It may not be realised by everyone here, but 'NoIndex - Indefinite' was an original feature of the Page Curation development process. IMO this doesn't even need debating. It just needs implementing. The people working at, or in charge of Phab may not have been around at the time. Kudpung กุดผึ้ง (talk) 22:30, 7 July 2022 (UTC)
• I'm very late to this party, but in my view 90 days is definitely too short. The original RFC was for indefinite, which would be my preferred option ideally, but anything inbetween would be an acceptable compromise and a step in the right direction (though wouldn't be worth the effort changing it to something like 91 days), with 365 days being reasonable. -Kj cheetham (talk) 21:59, 2 August 2022 (UTC)

Various NPP barnstars exist, but I don't believe anyone has given any on behalf of the project in a while. Is anyone willing to volunteer to be the NPP recognition coordinator? Most are geared towards the number of reviews in a year, so this would probably be very little effort except for a spurt in January (or I suppose it could be done annually at another time). MB 00:32, 3 August 2022 (UTC)

I volunteer. Any idea when these were last given out? -MPGuy2824 (talk) 03:28, 3 August 2022 (UTC)

The Reviewer of The Year Cup was last awarded in 2020, and as far as I can tell, the other barnstars were last awarded in 2018. -MPGuy2824 (talk) 06:08, 3 August 2022 (UTC)

Great, thanks for the help, it is now official. I looked in the archives and unless I missed something, the last reviewer of the year appears to have been in 2019. MB 06:11, 3 August 2022 (UTC)

JohnB123 was recognized as Reviewer of The Year in Dec 2020 -MPGuy2824 (talk) 06:58, 3 August 2022 (UTC)

The image clearly shows the history but the award for 2021 is missing. This should be addressed for the missing year, and if he has time, perhaps ICPH could update the engraving. Kudpung กุดผึ้ง (talk) 00:54, 4 August 2022 (UTC)

No need to bug ICPH for updating the engraving. I've tried it out and am able to do it myself. Also, I've created a new section for the award backlog in Wikipedia:New pages patrol/Awards. Please tell me if anything is missing/wrong there. -MPGuy2824 (talk) 02:13, 4 August 2022 (UTC)

See Wikipedia_talk:Template_index/User_talk_namespace#Proposal:_Add_single-level_notice_for_user_creating_non-notable_articles for the background. As I said there, I’m on NPP and run into users who don’t know or understand the notability requirements. It would be nice to have a notice that in a couple of sentences discusses why notability required and what it is, then points to the notability page. This would save NPP lots of time spent introducing people to notability. Of course, it won’t help with further discussion, but at least it would provide a concise and clear start. Thanks to the efforts of Aoidh and HLHJ, we now have a protype template that appears ready for testing and feedback. We struggled a bit with balancing informing vs overwhelming the recipient.

Feedback is important to optimize this template. When you use it, how is it received? Do we need to add or subtracting anything? In my mind, every single word added has a cost, as we want people to read this and not just go tl;dr. But having it too short is not good either.

The template is Template:Uw-notability. You can add it to Twinkle if you use that tool. Go to twinkle preferences, then, under "warn user", edit items in custom warning templates to display. Otherwise, you can add it manually by editing the user page of the person you want to notify, then add {{subst:Uw-notability|nameofarticleinvolved}}.

Thanks for your feedback. — rsjaffe 🗣️ 18:23, 5 August 2022 (UTC)

It may not be their first article. scope_creep^Talk 19:27, 5 August 2022 (UTC)

I like the concept of it, and agree with scope_creep. -Kj cheetham (talk) 19:45, 5 August 2022 (UTC)

Looks alright overall. I agree with scope_creep, and I also believe the template should emphasize what is independent in addition to/instead of what isn't, as is done for the other two points. ^Complex/_Rational 20:17, 5 August 2022 (UTC)

I've made some edits to address the concerns. Looking back at how Wikipedia defines Independent in WP:GNG, it uses a similar construct as in the template: "Independent of the subject" excludes works produced by the article's subject or someone affiliated with it. For example, advertising, press releases, autobiographies, and the subject's website are not considered independent. I've added the first part of that definition to start with a somewhat positive definition, but suggestions for better text are welcome. — rsjaffe 🗣️ 21:45, 5 August 2022 (UTC)

Delivered by: MediaWiki message delivery (talk) 21:25, 6 August 2022 (UTC)

I have discovered a number of newly created pages on Arabic novels and authors within Wikipedia:Kateb Maktub. Some seem to have been deleted as copyvios, while others seem to be copy-paste-translate of Arabic sources with CC licenses, which may not be copyvios but need lots of cleanup. I self-reverted a G12 upon closer inspection, though there may be other outstanding problems with the other creations. I believe a nearly-identical issue was raised at ANI in June (Wikipedia:Administrators'_noticeboard/IncidentArchive1102#Recent_influx_of_problematic_articles_on_Arabian_language_novels), and would like another set of eyes (bonus if someone is fluent in Arabic) to determine how to proceed. Courtesy pinging Fram, who opened said ANI discussion and left a note of it on this page. ^Complex/_Rational 16:27, 7 August 2022 (UTC)

today I left a message on the talk page of one contributor. She has Google translated an ar.wiki article producing borderline gibberish, and then added fake refs that don’t support the text at all. They’re just links to pdf versions of the book. If it doesn’t improve fast I’ll draftify it. We can’t keep up with these mass created poor quality articles. Mccapra (talk) 19:06, 7 August 2022 (UTC)

Very much a similar topic to ComplexRational's above: What do we do about translated articles clearly written by someone who's not fluent in the source language? WP:MACHINE is a thing... poorly done translations seem to constitute a substantial fraction of the tricky NPP cases. Ovinus (talk) 20:30, 7 August 2022 (UTC)

Don't forget that we have a Discord server (chat room and instant message capabilities) just for discussing New Page Patrol. Click here to get setup. Would love to get more folks on there. Can ask questions, bounce ideas around, and meet fellow patrollers. Could really build our little community. Come join us :) –Novem Linguae (talk) 04:51, 7 August 2022 (UTC)

• In! And THANK YOU, Novem Linguae for your tireless efforts. I am still quite focused on my efforts with the BoT, and hope we will soon be seeing more positive results. I truly believe that by making NPP more streamlined and efficient via automation (especially the tedious tasks), it will help avoid reviewer burnout. Happy editing! Atsme 💬 📧 15:10, 7 August 2022 (UTC)

  @Atsme. You're very welcome. My pleasure. Glad to hear someone is staying on top of BoT stuff! –Novem Linguae (talk) 08:26, 8 August 2022 (UTC)

I am going to take this opportunity to commend two of my remarkable NPPSCHOOL graduates who have gone on to become even more remarkable NPP reviewers beyond my expectations: Zippybonzo and Dr vulpes. I am humbled and incredibly honored to have had the opportunity to be their tutor. Zippy & Dr vulpes, you are shining examples of what our NPP tutorials offer in preparing motivated, enthusiastic editors like yourselves to be the kind of reviewers you both have become. Thank you for affording me the opportunity to be your tutor! I hope your accomplishments will serve as encouragement for others to consider NPPSCHOOL – we have several excellent tutors to choose from. I am also excited to say that we have another promising NPP reviewer in the making who recently signed up for my course. Happy reviewing!! Atsme 💬 📧 15:01, 7 August 2022 (UTC)

Atsme Well thank you for being my tutor, I am honoured to have been tutored by you. Zippybonzo | Talk (he|him) 15:07, 7 August 2022 (UTC)

@Atsme You were a great tutor and pushed me to think about the reviews in a holistic manner. I won't let you down. Dr vulpes ^{(💬 • 📝)} 05:49, 8 August 2022 (UTC)

The next generation is looking very promising. Great job everyone. Exciting times! –Novem Linguae (talk) 08:27, 8 August 2022 (UTC)

Indeed, good job! -Kj cheetham (talk) 09:57, 8 August 2022 (UTC)

Is there some way of marking an article unreviewed without notifying the previous reviewer? I've wanted to do so several times, because my unreview action is correcting some technical error rather than challenging the original review. * Pppery * _{it has begun...} 21:43, 7 August 2022 (UTC)

What kind of notification is currently generated: talk page message? notification tray notification? Also can you explain the use case a little bit more... what is an example of a "technical error" that would need to be unreviewed silently? –Novem Linguae (talk) 08:45, 8 August 2022 (UTC)

It seems it sends this template: Template:Unreviewednonote-NPF, automatically to the reviewer's talk page. Curbon7 (talk) 09:30, 8 August 2022 (UTC)

Looks like there's a ticket for this already. I'll try to prioritize it. Can you remind me what the use case is? What's an example of when you'd want to mark as unreviewed, but not notify the creator or reviewer? –Novem Linguae (talk) 10:26, 8 August 2022 (UTC)

Novem, does the proposed change give the reviewer an option to not send the notice or does it give the reviewer a choice to check why it was unreviewed? Atsme 💬 📧 13:17, 8 August 2022 (UTC)

Those are in net the same, since the reviewer can use the send message feature to explain the reasons for their actions, and then unreview without any further message. * Pppery * _{it has begun...} 13:24, 8 August 2022 (UTC)

Hey Atsme. Thanks for the question. The software already lets you send a message when unreviewing, you would just need to fill in the text box below the "Mark as unreviewed" button. However even an empty message is currently mandatory (enforced by the software). The request here is to make the message un-mandatory, i.e. the reviewer could choose to send no message. Hope that makes sense. –Novem Linguae (talk) 07:37, 9 August 2022 (UTC)

(edit conflict) Mark Ward (theologian) is the most obvious example in my unreview log; an admin performed a history split in a such a way as to cause their autopatrolled bit to apply to the split-off article when the true creator wasn't autopatrolled. Another example would be Hansen's small octagon + Where tapere. While in that case one personal message on the reviewers talk page explaining the need to unreview abandoned drafts they move to mainspace would have been useful, two bits of content-free templates aren't (and I'm lucky I caught it at only two articles, there could have been much more). Finally, another case is indigenous science, where I already used the "send message" feature to explain why I was unreviewing the article, so there was no need for a redundant automatic template message saying nothing. * Pppery * _{it has begun...} 13:24, 8 August 2022 (UTC)

Please join me in congratulating John B123 for winning the cup again, for 2021.

The top 10 article reviewers for 2021 are

Rank	Username	Article reviews
1	John B123	26,525
2	Onel5969	22,036
3	Joseywales1961	9,976
4	JTtheOG	8,695
5	Mccapra	8,395
6	Hughesdarren	4,891
7	Whiteguru	3,222
8	Rosguill	2,086
9	Seacactus 13	1,523
10	Mcampany	1,367

Thanks to all of you for your service.

P.S. Barnstars for 2021 will be coming soon. -MPGuy2824 (talk) 02:19, 9 August 2022 (UTC)

A belated congratulations are in order! — Insertcleverphrasehere^{(or here)_{(or here)(or here)}} 02:23, 9 August 2022 (UTC)

Wow you must get up very early in the morning. Congrats on all the hard work! Dr vulpes ^{(💬 • 📝)} 07:02, 9 August 2022 (UTC)

Nice work John, incredible effort. Hughesdarren (talk) 08:53, 9 August 2022 (UTC)

Congratulations! Atsme 💬 📧 10:41, 9 August 2022 (UTC)

Thanks all, however I think Onel5969 is far more deserving of the accolade. Their tireless work at the back of the queue reviewing the difficult articles that everybody else had passed by was far more difficult and time-consuming contribution than my own. --John B123 (talk) 21:55, 9 August 2022 (UTC)

I'm pleased to see that NPP catches redirects converted to articles. Does any mechanism cover dabs converted to articles? For example, if I overwrite John Smith with a badly written bio of my non-notable friend John Smith, is there a system for picking that up? How about name lists such as Abdul Hamid? Certes (talk) 20:51, 7 August 2022 (UTC)

No, because those examples are just changes of article content. Redirect and article are the only two distinct types of pages known within Page Curation (within mainspace, there are also Drafts). MB 21:38, 7 August 2022 (UTC)

I like your mindset, that we should find and close loopholes in the PageTriage software. I'll create a ticket. –Novem Linguae (talk) 08:31, 8 August 2022 (UTC)

An example of a recent hijack. Certes (talk) 10:36, 8 August 2022 (UTC)

I'm not sure I understand why you call this a loophole. It is a content change to an existing article, albeit it a major one. Hijacking can occur unrelated to dabs/SIAs, e.g. this one. Is there a more general way to detect that the subject of an article has been changed? Looking at category changes, %of text changes, etc. Is there a reasonable way to do this without too many false positives? MB 00:22, 9 August 2022 (UTC)

This one would probably be similar to redirect-to-article detection in the # of false positives. I personally think it's an acceptable amount. I see this as "low hanging fruit" because the software makes disambiguation pages easy to detect, same as redirects. We would not be able to detect article-to-article hijacking easily. With all that said, if enough editors object, will skip this feature. –Novem Linguae (talk) 07:34, 9 August 2022 (UTC)

There should be few false positives. If a new John Smith emerges who is so famous he becomes an instant primary topic, the correct procedure is to move John Smith to John Smith (disambiguation), then overwrite the resulting unwanted redirect called John Smith with an article on the new guy (with a flashing neon hatnote). Similarly, if a RM decides that John Smith (Labour Party leader) should become the PT, we move the dab then move the existing bio. In either case, although the bio usurps the dab's title, the bio goes on a different page and we evict the dab to another title, not overwrite it. Certes (talk) 11:36, 9 August 2022 (UTC)

I didn't mean false positives detecting dab hijacking, I was talking about the more general case of the subject of a non-dab being completely changed. MB 14:31, 9 August 2022 (UTC)

NL, don't count my comment as an objection. I was just wondering about the utility - if dab hijacking is only 1% of all hijackings, can/should we do more? Does the frequency of dab-hijacking justify the effort? If the effort is minimal maybe it does. MB 14:37, 9 August 2022 (UTC)

I'm not sure how common it is. As well as 888 mentioned above, other hijacks from yesterday include Galactica (twice) and Scaler, but those were quickly reverted. I don't see any today. Certes (talk) 16:14, 9 August 2022 (UTC)

I think that a disambig is technically just an article and so such a change would require a new identifier to be put on all disambig articles and then software to watch for it disappearing. Plus, such hijacking is really just vandalism that can happen to any article. For example if I changed the Dog article into into an article about one of my dogs. North8000 (talk) 16:47, 9 August 2022 (UTC)

I would implement this as an onRevisionFromEditComplete hook (edit hook). So anytime someone makes an edit, the check code would run. The actual algorithm that looks for the disambiguation removal could be written several ways: could check wikitext, could check category subtraction, or could check for changes to page_props (thanks to mw:Extension:Disambiguator which adds pp_propname = 'disambiguation' to all disambiguation pages). I judge this to be feasible. –Novem Linguae (talk) 19:59, 9 August 2022 (UTC)

If we're looking at about four pages per day then it's not worth going to too much effort. Do you have a feel for how many redirects get replaced by unwanted articles each day? Certes (talk) 22:07, 9 August 2022 (UTC)

I don't have any firm stats, but I know from experience reviewing redirects that there are probably dozens every day, most not notable and quickly reverted to the redirect. MB 23:22, 9 August 2022 (UTC)

When I first created this template, I added it to the top of all the NPP sub-pages (above the navigation tabs). I could see it at a quick glance at any page I went to. It was moved without any discussion, because someone felt it "looked ugly" there (according to a edit summary). Now it is different places - before the toc, after the toc, in the graph, in a text block. This really bugs me because I have to hunt for it instead of it just being on top on all pages. Does anyone object if I move it back? — Preceding unsigned comment added by MB (talk • contribs)

Even if it does look a bit ugly, I'd like it back. It a very important number and more accurate and timely. North8000 (talk) 13:22, 30 July 2022 (UTC)

Done, it's back on top. MB 21:36, 4 August 2022 (UTC)

The template just displays the backlog count in black text. The Pending Changes counter also displays a color-coded "level":

• blue = very low
• dark green = low
• light green = moderate
• red = high
• inverted-orange = very high.

Originally, I didn't think this would be useful for NPP. At Pending Changes, very high is over 18 and a few people can review the changes and get it back low relatively quickly - the level typically varies throughout the day; the colors probably do call attention to the backlog and cause some people to review PCs. If we implemented this here, the boundaries would need to be several thousand and it wouldn't work the same way.

Now, I think it might help. After the May newsletter, the backlog dropped about 1,500 then flattened out. After the June newsletter, there was another 1,000 reduction and then flat. Then the July backlog drive led to a reduction of 4,500 in the first half of the month, and then it's been mostly flat again. This shows that just keeping the backlog in people's minds has an affect. Using these thresholds would be another way to do that. Some people might see we are rising and be motivated to do more reviews to keep from crossing into a higher category. (or do more if we are close to reaching a lower threshold). It would be a permanent goal. It may help, probably not much, but we need every little bit we can get in any way. I can't think of any real negative - it's just a line of text wherever people have put the template. We could try this:

• very low <2000
• low 2000-4000
• moderate 4000-6000
• high 6000-8000
• very high >8000

In spite of all the effort the past few months, with this scheme we would still be "very high", but getting down to "high" is not too far off. Comments? MB 05:30, 30 July 2022 (UTC)

Like the coloring idea, and making it the same as pending changes would be good. — rsjaffe 🗣️ 13:08, 30 July 2022 (UTC)

I'm guessing that my situation may exist for some others. For most areas where I work in Wikipedia I both enjoy it and know that it is for a good cause. Reviewing is the only wiki area where I work that overall I don't enjoy (though it has it's fun moments helping editors that need help) leaving only the "good cause" part. And seeing when the barn is on fire (= high backlog) is a motivator for pitching in and doing a bunch. North8000 (talk) 13:45, 30 July 2022 (UTC)

Could we add flames to the display when it’s over 10,000? (Mostly kidding, but that would be cool). — rsjaffe 🗣️ 13:50, 30 July 2022 (UTC)

• Support. These kinds of color coded alert systems are useful. Back when I use to do Huggle anti-vandalism a lot, I kept one of those userboxes on my user page, and would hop on if the vandalism level got high. –Novem Linguae (talk) 19:37, 30 July 2022 (UTC)
• Support I like the idea of colour-coded alerts though the exact numbers might need a bit of tweaking. -Kj cheetham (talk) 16:41, 1 August 2022 (UTC)

  I think the numbers are good, if a bit aspirational. We really should try to keep it below 8000, and having that be the high end makes sense. — rsjaffe 🗣️ 17:15, 1 August 2022 (UTC)

• Why not instead separate the original from the new colored version? I quite like the plainness of the previous version, but can understand how others may prefer the colored version. Seems liek a best of both worlds to split them into two, or at least add a parameter. Curbon7 (talk) 16:06, 3 August 2022 (UTC)

The colors/thresholds have been implemented, as you have probably noticed. A short version and/or non-colored version may be added as options in the future for those that don't prefer the current version. This question is about update frequency. Originally, it updated every 15 minutes, just like the Pending Changes backlog. I would have preferred a real-time count, but because a bot has to do a database query and save the count with an edit so the template can display it, it has to be periodic. The interval was recently changed to every two hours, because "editing every 15 minutes to show the swings of ~5 pages rather than every 2 hours for ~20 pages is heavy overkill." I was in the habit of watching for the change every 15 minutes and am certainly disappointed with a 2-hour interval. There are many thousands of edits every hour, I don't believe these "extra" edits are significant. Does anyone else care? MB 21:25, 4 August 2022 (UTC)

@MB: I think that a fast update (e.g. every 15 minutes) is very useful and that 2 hours is less useful . Sincerely, North8000 (talk) 14:50, 10 August 2022 (UTC)

Forgive me for saying so, but the template above is not very aesthetic. It is using a monospaced font, and the orange/tan/white colors clash a bit. Should we consider overhauling the template's appearance, perhaps just copy pasting the code for one of the templates below and tweaking the algorithm while leaving the visual appearance almost identical to what we are copying? Note the black below is actually a color that changes with the severity of the backlog, and not just decoration, although I'd recommend red for us.

Idea 1	Idea 2	Idea 3
AfC submissions Random submission ~6 weeks 1,059 pending submissions Purge to update v t e	wd-4 WikiDefcon Level is Normal. 3.18 RPM according to EnterpriseyBot	~6 weeks There are 1,059 pending submissions pending AfC submissions.

–Novem Linguae (talk) 01:27, 5 August 2022 (UTC)

I'm neutral on any aesthetic changes. Go ahead if you think it is an improvement. It's only "Very high" that has the colored orange background, so if we were below 8000 it would be much more subdued - maybe we want clashing colors with a high backlog :)

The "reply" link shouldn't be there, do you know what is causing that? MB 02:47, 5 August 2022 (UTC)

DiscussionTools is detecting it as a talk page comment because of the timestamp. Let's investigate further over at Template talk:NPP backlog. –Novem Linguae (talk) 03:08, 5 August 2022 (UTC)

I didn't mind it as it was before, as it was similar to {{Pending Changes backlog}}. -Kj cheetham (talk) 07:21, 5 August 2022 (UTC)

1. The editor has demonstrated a pattern of performing obviously controversial reviews without first determining consensus.
2. The editor has demonstrated a pattern of failing to exercise sufficient care when reviewing pages, resulting in new users being offended or discouraged.
   The editor has demonstrated a pattern of failing to exercise sufficient care when reviewing pages, resulting in users being offended or discouraged (especially new users).
3. The editor has used the permission to gain the upper hand in disputes.
   The editor has used the permission as leverage in disputes or used any project tools in any improper way.
4. The editor has performed any blatant vandalism (not limited to page reviewer vandalism).
5. The editor has failed to report to an administrator after noticing unauthorized use of their account or otherwise neglected account security practices.
6. The editor has been inactive for 12 months or more.
   The editor has been inactive at NPP for 12 months or more.
7. The editor has accepted or solicited payment in return for reviews.

I've made some minor changes:

• (2) is a little change to show we shouldn't offend or discourage any users.
• (3) is another minor change per the above discussion.
• (6) is a minor clarification. This is not any change in policy, but some people have apparently misinterpreted this to mean that if given the right, it is permanent even if never used as long as the editor is active on the project (which would be WP:HATCOLLECTING). That guideline has always meant editors with the perm should do at least one review per year (and hopefully many more than that). Unlike the US Supreme Court that must ponder what the words of the founding fathers meant, Kudpung is still around so we know that this meant active at NPP. (Pardon the US-centricity of this analogy). I made the change to #6 recently and was reverted because it "wasn't discussed." I don't believe it needs discussion because it is an obvious clarification, but just stating here the reason before making that change again. MB 00:09, 3 August 2022 (UTC)

  2) and 3) both look good and shouldn't be controversial, in my view. I do think 6) needs discussion, though: several editors have expressed disagreement (i.e. we're at the 'D' stage of WP:BRD), and I for one would oppose it unless there was some hard evidence that formerly inactive reviewers have been using the permission inappropriately. (A sidenote—the original version of these guidelines said quite clearly "The editor has been inactive on en.Wikipedia for 12 months", so I don't think "inactive at NPP" was in fact the original intent.) Extraordinary Writ (talk) 00:19, 3 August 2022 (UTC)

  It only said that (inactive on en.Wikipedia for 12 months) for the first six months, after which it was changed to the current wording (March 2017, inactive for 12 months or more). I defer to Kudpung when he says that aligns with what he meant - inactive at NPP. MB 01:55, 3 August 2022 (UTC)

Although my participation both on and off-Wiki for the movement is very heavily reduced since early 2020, I am indeed still around, especially as I and a couple of others contributed significantly to the development of the new system and its maintenance for 10 years. What we have now is a far cry to what we were having to use before 2012. For all NPP reviewers and aspirants it's almost essential to take 3 minutes to read NPP: This could be heaven or this could be hell for new users – and for the reviewers - it will clear up a lot of misunderstandings.

Anyone who is sufficiently interested in NPP to follow this talk page will be fully aware that the user right is being abused by users with disallowed agendas and that nearly half of the 750+ reviewers is completely inactive. User permissions enable access to necessary maintenance tasks that require a bit more skill than normal editing; they are not however, awards of merit for good work, hence hat collecting is also an abuse of special permissions. Without any disrespect meant - so please permit the levity - I am amazed that Extraordinary Writ appears to have a crystal ball. Sometimes people who have known me for nearly 70 years can't guess what I am thinking! I can confirm however that when I created the user right for NPP and its policy, it was firmly in my mind for the right to be removed after 12 months of no logged reviews; the error in the policy which MB recently corrected ,was a keyboard error or a momentary lapse.

There are several very good reasons to reducing the number editors with the NPR right to the actual number of truly active reviewers, among which it's time for NPP to be brought in line with other user rights. On AfC for example, the user right is withdrawn from users who have not made a review for 6 months. Having a right removed for lack of activity is no disgrace and it can always be requested again if the editor want to return to active and regular reviewing. Kudpung กุดผึ้ง (talk) 03:03, 3 August 2022 (UTC)

I'm familiar with the arguments—I just share the view of Barkeep49, Novem Linguae, etc. that the benefits don't outweigh the harms. I've dealt with my fair share of patrollers with "disallowed agendas", and I can't think of a single one that was inactive for more than twelve months (they're usually very new, very active accounts). If you can think of any examples of disruption that this proposal would have prevented, I'd be interested to hear it, but otherwise it's my view that this would cause more trouble than it's worth. That said, I respect that we're going to have to agree to disagree here; perhaps an RfC would be the best way forward. Extraordinary Writ (talk) 04:09, 3 August 2022 (UTC)

• Support Personally I'd be happy with them all as currently written, but number 6 is potentially controversial so might need confirmation of wider consensus. -Kj cheetham (talk) 08:30, 3 August 2022 (UTC)
• Neutral for now on #6. If a strict time period is to be codified, I believe that a talk page notice of the "deadline" should be given, and there should be no prejudice for restoration as long as certain conditions are met (perhaps to be determined by an RfC). Namely, restoration should be straightforward at PERM for semi-active users who have been inactive at NPP but haven't shown any red flags, and short-term vs. long-term inactivity should be handled differently. It needn't be as involved as desysop/resysop procedures – nothing more complicated than PERM routinely handles – but I think it unfair to treat someone with a 7-month busy spell IRL and a 7-year semi-retirement the same. Any signs of potential abuse can be handled on a case-by-case basis, as outlined by the other points. Support the remainder, especially the rewritten #2, because poor reviews can indeed discourage any editor. ^Complex/_Rational 14:14, 3 August 2022 (UTC)

  Yes, if the perm is removed for inactivity, the user is not under any "cloud". If an inactive reviewer wishes to come back, they just ask again and it would be nearly automatically granted. We certainly need the help of anyone qualified and willing to help. I am just trying to clarify the guideline now, not implement anything further. If we move on to an actual removal mechanism, I anticipate a user TP notice after 6 months without a review as a reminder. This would all be discussed/publicized further. MB 14:38, 3 August 2022 (UTC)

  I'll work on adding a #6 reinstatement to granting guideline. I sporadically watch reviewer right requests and have never noticed a former reviewer turned down - so I think this is in line with the normal judgment of the admins that handle the requests. MB 14:54, 3 August 2022 (UTC)

I applaud the much needed effort but many of those could mis-fire. North8000 (talk) 17:32, 3 August 2022 (UTC)

I don't see how that could misfire, North8000. Perhaps you could explain. Over 200 reviewers at AfC have been removed yesterday for inactivity - no reviews in 6 months - including me and a couple of admins. Why should NPP be any different? Kudpung กุดผึ้ง (talk) 05:07, 4 August 2022 (UTC)

@Kudpung: (note that I didn't say "oppose"....those were just comments.) I think #2 and #3 are pretty vague and wide ranging....the kinds of things that are matters or opinion, interpretation or inexperience. I think that the suspension for no activity is a good idea, but am worried that we could lose experienced reviewers who just took a break. I don't the the process for enforcing these, but if it involves reviewing the situation vs. just autopilot, I think that those would all be fine. Sincerely, North8000 (talk) 14:07, 4 August 2022 (UTC)

• No objections to these revisions from me. Mccapra (talk) 22:08, 3 August 2022 (UTC)

• Oppose If an editor is not active for a spell then removing the right will make it even less likely that they will return to do any patrolling as we'd be creating an additional barrier to further activity. If a right is not being used then it is therefore not being abused and so there is not a problem which needs fixing. Andrew🐉(talk) 10:53, 4 August 2022 (UTC)
• Oppose – relative to activity. Let's not add hurdles with more bureaucracy. Editors who are active on WP may need to temporarily focus on something else of higher priority for a year, or perhaps they are recovering from a serious health issue (I recently read where an editor who was declared legally blind and barely active for like a year, recently underwent surgery that restored her vision). Anyway, I don't think we should remove their rights without first notifying them, which may actually serve to jump start them. What I just began at Project Dogs is to ping all listed participants that haven't shown up in a while to confirm their status, and those who do not respond, will first be checked to see if they're still active on WP and contributing to the project elsewhere. If they are, then I'll pose the question on their UTP in case the ping didn't work, or was overlooked. I believe we should give them a chance to respond before removing their rights. Atsme 💬 📧 11:45, 9 August 2022 (UTC)

  Per above, there would be notification after 6 months with no activity, an perhaps again in 9 months. This would be discussed/publicized before any removals are done. MB 14:25, 9 August 2022 (UTC)

• Oppose 6) per my comments above. Revoking the right simply places another obstacle in the step of those who want to return to reviewing, thereby making it harder to bring down the backlog, which should be our number-one priority right now. Now, there are times when that price is worth paying (I supported the recent RfC on admin inactivity, for instance), but in my view that's not the case here: there's been no evidence presented of formerly inactive patrollers coming back and causing disruption, so it's not really clear what the benefit of this change is supposed to be. The current inactivity requirement (which is equal to or higher than that for other sensitive permissions, such as template editor, page mover, and autopatrolled) seems to be sufficient, as far as I can tell. Extraordinary Writ (talk) 18:07, 9 August 2022 (UTC)
• Oppose I'm worried that reviewers who sometimes do a lot of reviews but then took a break will get dumped and won't ask to come back. Per below I do think that some housecleaning is in order, though. North8000 (talk) 14:55, 10 August 2022 (UTC)

Under Wikipedia:New_pages_patrol/Reviewers#Guidelines_for_granting Granting:

6. If the right is removed solely for inactivity, and there are no extenuating circumstances, it will restored upon request at Wikipedia:Requests for permissions if the editor commits to meet the minimum activity levels. The restoring administrator, at their discretion, may do so permanently or on a trial basis depending on the situation.

Does this so OK? MB 00:32, 4 August 2022 (UTC)

Looks reasonable. Has the minimum activity level already been stated (I believe some comments suggested one review in the preceding 6 or 12 months)? ^Complex/_Rational 00:41, 4 August 2022 (UTC)

Yes, one review in a year is the minimum. MB 01:35, 4 August 2022 (UTC)

That would be gaming the system just like admins do to avoid losing the bit. Kudpung กุดผึ้ง (talk) 05:01, 4 August 2022 (UTC)

@Kudpung: There may also be cases when someone sticks to the bare minimum with the intention of returning to higher activity levels later (echoing North8000 above – to not lose experienced reviewers on a long break), which I wouldn't call gaming the system per se. Regardless of intention, however, I don't see a way to avoid gaming the system as long as certain rules exist. I would be curious to know how this possibility is handled for other permissions with procedural removal for inactivity. The question arises of whether instating such rules and the risk of gaming the system outweigh the potential risks of having semi-active or inactive users with the NPP right. Most are already addressed by the other guidelines for removal; the only other one I see at the moment is drastic policy changes that in turn affect NPP workflow – is this fundamentally the idea? ^Complex/_Rational 14:29, 4 August 2022 (UTC)

Let's set some expectations. This group can't create something that's binding on admins without an RfC. If the idea is that it's admin discretion but here's some advice, well that can happen. Best, Barkeep49 (talk) 05:40, 4 August 2022 (UTC)

I think that some housecleaning & motivation is needed. Maybe for a new NPP'er 30 reviews in their first and second year is a good criteria. That would give them a nudge to start doing it. And for folks that have been in longer, maybe an auto purge for no reviews in the last two years, with the understanding that someone who had been active prior to that can easily ask and get it back. — Preceding unsigned comment added by North8000 (talk • contribs) 18:34, 9 August 2022 (UTC)

I found an article – Milton Torres Quisocala – that looks like a machine translation of an es.wiki article (es:Milton Torres Quisocala) that was created by a sockpuppet of a blocked user there and has since been deleted (prior to being created on en.wiki).

I'm only pretty confident that this is a translation because it does not read like natural English, which is what prompted me to dig deeper. No SPI has been done (yet), and even if it were, I don't believe G5 applies cross-wiki. FWIW, the account behind this article also exists on es.wiki. However, I'm not sufficiently fluent in Spanish and I'm not autoconfirmed on es.wiki. What looks like a pertinent SPI is located here, and I haven't found a corresponding case on en.wiki.

How are cases like this usually handled – at NPP and in general? Should there be a deeper investigation for possible cross-wiki abuse or should I (temporarily) ignore my findings on es.wiki when patrolling? For this case specifically, I would also appreciate if someone fluent in Spanish and/or active on es.wiki could take a look. Additionally, I don't know if this is the best forum in which to ask; I'm posting here because I fell down the rabbit hole from NPP. ^Complex/_Rational 17:15, 16 August 2022 (UTC)

I've moved this to draft as it needs more sources. It does look like a bad translation to me -- "however, he obtained only 2,174% of the electoral preferences" makes no sense at all. >>> Ingenuity.talk(); 17:37, 16 August 2022 (UTC)

For now, that should suffice. And I believe "2,174%" was part of the half-baked translation – in Spanish, a comma is used in lieu of a decimal point, so it should read "2.174%". ^Complex/_Rational 17:51, 16 August 2022 (UTC)

Could have probably prodded or AFD'd this one. Fails WP:NPOL since he was never elected to anything at state or federal level, 1 relevant source in Google Search (a press release), and 0 relevant news sources. Draftify should probably be reserved for more borderline situations. –Novem Linguae (talk) 00:43, 17 August 2022 (UTC)

Can someone please explain the peer-review process at the NPP School to me? I am interested in getting a review, but I am not actually sure about how it happens. CollectiveSolidarity (talk) 01:40, 11 August 2022 (UTC)

It might be inactive. If so, you can always ask someone on their user talk page, here, or on Discord for a second opinion. Pinging the peer review cohort coordinator @Rosguill in case I am wrong about the inactivity. –Novem Linguae (talk) 02:23, 11 August 2022 (UTC)

It's inactive, I recall that we did an organized peer review drive once, but in debriefing while we generally appreciated the exercise there was a sense that the editors that most needing coaching and oversight were the ones least likely to participate. _signed, Rosguill ^talk 05:40, 11 August 2022 (UTC)

@CollectiveSolidarity, we set up a channel on the discord server. If you want to do a deep dive on a couple articles I'm more than willing to meet up and go over a few articles with you. Dr vulpes ^{(💬 • 📝)} 01:23, 17 August 2022 (UTC)

@Dr vulpes Which discord server? You mean the main one, or is there a specific server for NPP similar to the Anti-vandalism server? CollectiveSolidarity (talk) 19:48, 17 August 2022 (UTC)

There's a separate NPP server, link is at the top of this page and here. Dr vulpes ^{(💬 • 📝)} 19:54, 17 August 2022 (UTC)

Like Dr vulpes I'd also be willing to do some in-depth reviews with ya. Ovinus (talk) 20:02, 17 August 2022 (UTC)

What was the final result about NPP being able to draftify older articles that needed work vs tagging them? A VPP discussion said not to draftify but didn't Kudpung say something about NPP being established differently from other types of reviews, and that we are supposed to draftify? I also don't see what difference the age of an article makes as to how it's reviewed as long as it is in our queue. What's the big deal? Atsme 💬 📧 03:02, 16 August 2022 (UTC)

Atsme, I'm a strong protagonist for getting the software smartened up but I'm not as active on other stuff these days as you might think (Arbcom made sure of that), so I don't know. What I do if ever I patrol an article these days, which is rare, is to move anything to draft which while clearly not being fit for mainspace, has very good potential for surviving any AfD (it might even already be notable and adequately referenced but in a really terrible state or a very bad machine translation, etc), if the author would spend some time on it. My philosophy however is very firmly based on the premise that although Wikipedia has a dozen 'clean up' projects for all kinds of tags and also the GOCE and ARS, the onus is on the creator. As an encyclopedia, we serious editors and content providers would get a lot more done if we didn't have to walk behind the Lord Mayor's Show with a bucket and shovel. Kudpung กุดผึ้ง (talk) 03:27, 16 August 2022 (UTC)

I would say it's more of a case-by-case basis. The problem is if the author is inactive, as most new editors tend to become, then the article will simply die a slow death in draftspace. Curbon7 (talk) 03:33, 16 August 2022 (UTC)

:: I see there's rules at both WP:DRAFTIFY for "During new page review" and WP:NPPDRAFT. Why are they seemingly repeated, isn't there a danger they'll go out of sync? Seems to me would be easier to not duplicate them and just rely on one linking to the other. -Kj cheetham (talk) 16:51, 16 August 2022 (UTC)

I think the final result is that if an article is older than 90 days, no one is supposed to draftify it, and it's supposed to go to AFD instead. This is now codified in WP:DRAFTIFY rule 2d. If this bugs you guys, let me know and we can look into repealing it. The close of that RFC was on March 24, 2022, so it's been about 5 months. We could reasonably start another RFC around now, probably at the same village pump. Perhaps we could even appoint someone to write a neutral opening statement, a persuasive first !vote, and head up the effort. –Novem Linguae (talk) 06:05, 16 August 2022 (UTC)

Courtesy link to the March RfC. Ovinus (talk) 06:38, 16 August 2022 (UTC)

Novem, you have been such a pleasure to work with, there aren't enough words to express my appreciation. That said...before I forget, we need stats to know how many situations exist that are similar to Distortions Unlimited: tagged G11 and rejected, Prodded and rejected, and then redirected? See following questions:

1. How many G11 rejects and/or Prods end up at AfD and are actually deleted vs kept?
2. How many 90+ day old redirects are hijacked and used for an unrelated article such as what happened here but was caught by Ovinus, one of our highly proficient new reviewers?
3. Is there a way we can add a caution notice for hijacked redirects? There's no telling how many have slipped through the cracks and reside in main space with countless issues.

As for the 90 day draftify timeframe, I'm of the mind that the questions above should factor in because the answers will help us make informed decisions as it effects our initial approach. Atsme 💬 📧 11:35, 16 August 2022 (UTC)

Hey Atsme. You've been a pleasure to work with as well, thank you for all that you do. Your questions are a bit hard from a technical perspective, I can't think of an easy way to get that data. Perhaps another good set of data to get would be how many inappropriate draftifications were being made per day before the RFC was enacted? That was the supposed reason for creating the 90 day ban, yet I suspect the number was quite low. I did a spot check at that RFC and I was not convinced at all that inappropriate draftifications were a common/big/numerous problem. –Novem Linguae (talk) 11:52, 16 August 2022 (UTC)

I think at this point anything will help. We obviously have a way to indicate an article became a redirect so it seems to me that a redirect that becomes an article could trigger a notice of some sort in the queue. A filter could then be added in the queue to list only that activity. What do you think about that? Atsme 💬 📧 13:07, 16 August 2022 (UTC)

Thanks for linking to this @Ovinus. I started this RfC a week ago because during the last NPP Drive I ran into a lot of articles that got bumped into our backlog because someone made one or two minor edits on an article that wouldn't pass review or was in need of some real love and care. I'm sorry if this has caused a problem I was honestly looking for a way to solve a problem that I didn't have a large base of technical knowledge about. Currently I've been sending the articles to AfD and then telling the pushing for drafify. I think if there is enough activity (multiple people editing or significant edits/changes) being made then it should be ok to send to draft. The 90 day rule makes sense in that people who aren't active won't notice and the article will die off. But the assumption is that no one will be there to finish or care for that article. Dr vulpes ^{(💬 • 📝)} 00:36, 17 August 2022 (UTC)

(If what I said didn't make sense or is very wrong please forgive me, I just got back from a four day hike and I am very tired) Dr vulpes ^{(💬 • 📝)} 00:37, 17 August 2022 (UTC)

Regarding an RFC on extending 90 days for draftification, I would suggest re-reading this discussion that is much newer. It doesn't specifically mention draftity, but it's the thread suggesting that NPP should just pass anything that is not so bad to be CSD-worthy. I expect that a new proposal to further extend the Draft time would be unlikely to pass. That said, I do agree that one of the biggest problems we have in reducing the queue is dealing with the old articles that have been looked at several times, often tagged, but just passed over. MB 15:37, 16 August 2022 (UTC)

That discussion presents an interesting perspective, MB, one which confuses me. The idea that NPP should only look for speedy-deletable articles makes sense to reduce the workload, but not to maintain Wikipedia's integrity. Are we still in young Wikipedia's stage where anything goes? The suggestion to vastly reduce NPP's scope is absurd and would cause a firehose of shit articles; AfD is clogged enough as is. As to the old articles... indeed. When they're old they're typically a borderline case. Ovinus (talk) 16:05, 16 August 2022 (UTC)

This idea that NPP shouldn't check notability seems quite dangerous. Luckily I believe this to be a non-mainstream idea, and unrelated to the ideas that resulted in the 90 day draftification rule. I think the 90 day draftification rule was a backlash against some nebulous fear of massive, systemic "backdoor deletion" of old articles (of which no real evidence was presented, yet it still gained traction), not a backlash against NPP checking notability. –Novem Linguae (talk) 16:37, 16 August 2022 (UTC)

I'm sure you understand the argument - the older and article is, the less likely it is that the author will be around to improve it and the more likely it sits in draftspace untouched until eventual deletion as an abandoned draft (I agree this argument does have some merit). I linked the above discussion to show the opinion of the "inculsionist" camp, who would likely oppose any Draftify period extension on the grounds that a Drafted article is nearly a deleted article as Draft space is nearly invisible and articles there rarely are improved. Policy prior to the RFC said that draftify applied to "newly-created articles", and the first RFC was meant to define that. The 30 day RFC was rejected as too short a period, but the 90 limit barely passed. There were a variety of reasons given in the opposes, 90 days is too short, too long, too bureaucratic, etc. You talked about "repealing" the RFD. Did you really mean going back to the prior wording of "newly created"? That would leave it open to interpretation again, which I don't think solves anything. I know that prior to the RFC, some admins used a "rule of thumb" that 6 months was "newly-created". We could propose that, or perhaps 90 days by anyone and 6 months by NPP. That might sway some people to support. MB 22:32, 16 August 2022 (UTC)

I understand the gist of the argument, although having been "in the trenches" I cannot agree. Thank you for showing their input, though, and reminding that the RfC was mostly about simplifying vague language. I think your last suggestion is actually quite reasonable. Another solution might be having the cutoff for everyone being the oldest (non-converted-redirect) entry in NPP, which could be determined by bot, but people might similarly consider that bureaucratic. Ovinus (talk) 22:40, 16 August 2022 (UTC)

If folks are interested in revisiting the 90-day requirement, I think the most effective way would be to follow the closer's suggestion and start a discussion on "When the clock should start: on article creation, or on review?" A 90-days-after-review requirement wouldn't interfere with NPP at all, so perhaps that's the path to follow—it would probably be more likely to succeed than challenging the RfC directly. Extraordinary Writ (talk) 22:49, 16 August 2022 (UTC)

I don't really understand this idea of starting the clock after the review. The original RFC was specifically written to prevent "backdoor deletion" via Draftify of old articles, and it put a 30 day limit. Then when that went no where, the time was changed to 90 days. Some supported that as a reasonable compromise/definition of a new article. The close suggested follow up on whether to stay with 90, or extend to 180 or something else. The follow up "should the clock start on creation or review" doesn't make sense to me. The whole RFC was intended to limit this to "new" articles. Those that think "new" means 30, 60, or 90 days could care less about NPP backlogs. If the clock started after review (which as no time limit), "new" could be stretched out considerably. We have unreviewed articles 6 months old right now. Reviewing activity is down now after the backlog drive and we aren't keeping up with the inflow. We could easily get to the point of having unreviewed articles a year old. As E-Writ said, the limit "wouldn't interfere with NPP at all" if the clock started after the review, but that would be extending the limit from a fixed 90 days to indefinite since nothing forces us to review an article. I don't see how that could possible get support in a project-level RFC. MB 02:10, 17 August 2022 (UTC)

The old RFC was, in my opinion, about 50/50 (45 support, 46 oppose), and we just got unlucky with that particular close. Anything reasonable could be proposed now: repeal, changing to 180 days, repeal then restricting draftification to NPPs only, or repeal then restricting draftification to unreviewed articles would all solve the problem of NPPs being banned from using an important tool (draftification) when doing back-of-the-queue reviewing. –Novem Linguae (talk) 02:23, 17 August 2022 (UTC)

I very much doubt that there would be consensus to extend beyond 90 days. Many editors don’t agree with draft space at all, and anything that looks like a means of draftifying more stuff will bring them out in numbers. In any case our main problem isn’t the specifics of a time limit, it’s the lack of volunteers to do NPP work. We could burn a lot of rubber trying to push the limit up to 120 days or something but I think the effect on the overall backlog would be minimal. Mccapra (talk) 21:41, 17 August 2022 (UTC)

I think you're right, Mccapra. Maybe it's about changing the reputation of NPP as slogging through a swamp of subpar articles, and instead as a process to save and restore meritorious content. For example, the oft-controversial WP:ARS could get involved in improving borderline articles at NPP. Edit: As soon as I say that I find Category:Promising draft articles. Seems underused, though. Ovinus (talk) 00:11, 18 August 2022 (UTC)

IMO it's a realistic possibility to get it changed to 120 or 180 days. Even with NPP running with less backlog, I think that an extension is good/needed. For articles that aren't a slam-dunk "yes", you sort of have to wait until they are a week old to make sure you know their initial state, and then after giving initial feedback, wait a couple months before knowing they aren't going to fix it / find GNG references. Even if NPP's inconstantly did them per that time frame, that only leaves a 3 week window to get all of the reviews done. Even a 30 day extension would more than double that. North8000 (talk) 21:52, 17 August 2022 (UTC)

An argument could be that an extension would take away the rush on draftify ones and gives them more time to fix them in mainspace. North8000 (talk) 21:56, 17 August 2022 (UTC)