Reaching a certain edit count or tenure does not necessarily mean someone will be an effective, responsive, or engaged mentor.

I certainly concur with that. Even the en.Wiki 's hugely successful 'Teahouse' when it was introduced is now suffering from to some extent from a plethora of less experienced 'hosts'. I do not believe however, that the significant technical work required to calculating and maintaining more nuanced mentor metrics would be conducive to the more immediate needs of basic onboarding of new editors, especially those who register with the sole intention of creating and posting a one-off, inappropriate new article.

I realize this project has been entrusted to a department primarily concerned with content translation, and and after having read the research paper by Hale, I'm left wondering whether the main focus of this project is to grow the corpora through cross-language article alignement (perceived need), or to help new users create acceptable articles on truly encyclopedic topics (established need).

I see you’ve already gone ahead anyway and created 48 page templates.
https://b24e11a4f1.catalyst.wmcloud.org/wiki/Category:Pages_using_article_guidance

• That’s a few more than the 12 I recommended. A lot of work if they have to be coded up for 7 languages, and tested.

My theory was that if the new users were to be left to do some of the work themselves, it might have a greater didactic impact.
What’s the ETA on this project? And is it only being built for mobile platforms?
Even with 500 new articles a day, some of those templates would get used once a year at the most on en.Wiki.
Like the Newcomer Homepage, it’s also confronting the new user with information overload: Qual der Wahl (agonía de elección).

I'm just curious to know why throughout this project Wikidata is being evoked. Perhaps for the smaller Wikis where traditional and scientific articles are still needed, there is a possibility that there exist some entries in Wikidata that came from the en.Wiki, but for the average new article in a day's average intake of around 500 new articles on today's en.Wiki I would be surprised if any Wikidata already exists. Fine if it can be done automatically, but that detracts from the KISS principle. and it seems to be trying to do too much.

I don't think there's any need to get too technical to resolve this. All that's basically being asked is for the mentorship programme to exercise more due diligence when according the 'mentor' right to users. What we are often seeing at en.Wiki is either newbies mentoring newbies, or in the example I posted above, what we rather pejoratively and rightly or wrongly call 'hat-collectors'. That said, the local Wikis should be able to set their own thresholds, and IMO these should be quite high - at least as demanding as those for NPP's Guidelines for Granting.

@Pginer-WMF . The proposed list above of biography types is good. Each type has its own specific challenges of layout and content. Most of these types are written by fans and are often not of a suitable standard of language for including immediately in mainspace, or include text created by LLM. However, politicians present a different set of challenges: they are often written by professional public relations and political image consulting firms with focus on crafting a positive public persona. They generally bypass any help pages, and place articles directly into mainspace.

@Pginer-WMF, yes, I do think subsets for bios could be considered but I would guard against creating too many types of article templates at least until some have been tried out for impact and run past UX and UI designers from the community's veterans first.
The effort is to help the new, new page creators to create their articles rather than doing it for them by basisically turning it into a gap-filling exercise. Gap-filling does not necessarily enhance critical thinking for academic phraseology; at NPP we're looking at a lot of potentially notable topics , especially among the popular BLP types, but in very poorly written articles that need a lot of attention before they are anywhere near ready for mainspace.

@Novem Linguae. I don't think I want to enter a naming-and-shaming exercise, but the screenshot is genuine. (around March this year, en.Wiki)

'To learn about this, we can incorporate input from experienced reviewers as well as data analysis on articles created.'
Apologies - didn't see that. As former coord of NPP for nearly a decade, don't hesitate to ask for suggestions how to best obtain the feedback and from whom. on en.Wiki. Below is a list of the suggestions for the main types of articles based on a rough 24 hour sample (~500 articles) on 19 March 2025. On that day 28% were biographies (BLP and other Bios):

This is the easy part. Phab is possibly not the ideal venue to address this. All that needs to be done is to collaborate with the people who actually do the daily work of seeing the entire inflow of new content.
Rather than trying to sientifically parse new articles into types and then present the new user with walls of text or confusing drop-down choices (UX and UI psychology), we have whittled this down to 10 -12 basic article types (given that the vast majority of articles on the en.Wiki nowadays are biographies.) The effort should be to avoid thinking up a long list of article types and then spend months debating what the page templates should look like. The recommendation should be to encourage feedback and ideas from the Wikipedians who have a vast resource of institutional memory and anecdotal evidence: the most senior New Page Reviewers from the user right I created in 2016.

@GGalofre-WMF This is nothing new. First brought to the WMF table by the en.Wiki community in 2022 and recently again to the Article Creation team with a presentation on a virtual conference based on the uregent needs of the en.Wiki , much of the work has been prepared. leaving only a proof of concept to be quickly engineered. What is missing is collaboration and discussion with the volunteer community/ies who have long term awareness and solid anecdotal experience going back years.

It seems to me that this simple request has been dragging on for 3 years. Why is it taking so long?

@Robertsky Right up my alley too (50 years ago), but neatly summed up. Many Wikipedia volunteers are interested in knowing at least who their NCOs and officers are up to regimental half-colonel, and then at least some idea who's-who on the General Staff ladder.

We're not discussing the website, we're requesting some transparency around the remotely operating staff of a registered juristic person that owns the website and operates virtually from a rarely used but physical letterbox office in One Sansome Street SF. It would really be nice to know more about their infrastructure and what their lines of vertical responsibiity are. It would dispel any theories and instill more confidence.

@Aklapper There's usually one on the wall of every unit's admin office.

@CKoerner_WMF Despite the welcome initiative, the page at we've been keeping the slight more detailed org chart updated on Meta-wiki.updated on Meta-wiki is still not an organigramme with any arborescence, nor are any of the other pages cited by @Novem_Linguae. I'll repeat what I wrote earlier:

IMO it should be reviewer driven but be completely optional for reviewers. A BLP banner is a must but the effort should be to streamline the Page Curation tool for reviewers rather than add new tasks. There are literally 100s of Wikiprojects, not even NPPers know more than a few. A dropdown would be very long. There was once a suggestion for NPP to add stub tags.(I think it was mine). Same problem.

The saga of a staff and contractors page has been dragging on for a full two years now and actually since long before @Novem_Linguae took the initiative to open this ticket.
A year and a half ago I wrote:
//@CKoerner_WMF. I fully understand @Aklapper's 'Whoever might be responsible for this in WMF, I do not think that they necessarily follow this task or use Phabricator' but this does now look like a positive step forward. A correct and up-to-date display may help to dispel many of the conspiracy theories surrounding the WMF's Staff & Contractors .

II thought what we were also asking for here was for the info pane to display something like: 'Kudpung has sent a message to the creator' in the case of a message sent to the creator without marking as reviewed. At least this would inform the next reviewer that a second opinion is required if thats what @Novem_Linguae means with 'I'd be OK with rewriting this ticket to put both the "make comment" textbox and the "view comments" feature in the toolbar. That seems reasonable."
I would prefer an extra flyout panen that coud reproduce the contents of the message(s) too, but that's probably more complicated to make.
Original onwiki discussion is at https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Investigating_the_cause(s)_of_backlogs

Using MacOS Sonoma 14.5. Firefox 133.0 (aarch64)

Strange thing is, I am logged into the meta.wikimedia.org site already.

It might be an idea to provide a key to the job titles and their hierarchy. These terms without a context - especially for community-facing positions - could be meaningless outside the US:
Specialist
President
Vice President
Senior Manager
Manager
Senior (...)
Chief Officer
Officer
Senior Director
Director
Staff (...)
Principal (...)
Lead (...)

@CKoerner_WMF Thank you so much for this new org chart Chris, and anyone who assisted with it (I see it was dropped into a wiki page in a single edit). Now that it is editable Wiki, markup everyone can fill in any gaps, links, and links to it from WikiMedia project pages.

@matmarex Thank's for the heads up. I now fully understand the importance of that group.
However, it is clearly a classic example of how the (semi)official 'Staff & Contractors' Wordpress site totally fails in its mission to be both informative and navigable. Instead, It just creates more confusion.

@CKoerner_WMF The new project seems like a well intentioned good start, but will it ever get done, or will it become a perma-debate on what to do, like most WMF projects? As I said six months ago already: Fingers crossed.

@CKoerner_WMF. I fully understand @Aklapper's 'Whoever might be responsible for this in WMF, I do not think that they necessarily follow this task or use Phabricator' but this does now look like a positive step forward. A correct and up-to-date display may help to dispel many of the conspiracy theories surrounding the WMF's Staff & Contractors .

This really needs to be given some attention now.

@kostajh I already mentioned above that I don't recall it being deprecated but that probably because it was not in the final version that was rolled out. I can confirm that the image is extremely old and certainly dates back to October 2011. If you really need to know, perhaps @Scottywong 's memory is better than mine.

Yes, I remember it. It was a very early UI of the feed. It wasn't a feature I asked for during development. Much as I am flattered to see my name in lights I don't recall it being deprecated.

A copy of the message to the article talk page message should be optional. Many reviewers' messages include information or tips for the creator that are not appropriate for general publication to the article talk page.

Absolutely! Congratulations are in order here. Thank you NL for everything you do.🙂

Are there any updates on this? As a firm believer of letting the article creator know what's good or wrong with their article, I will not be reviewing any articles where I cannot connect with the creator.

I think we're better off spending developer time in building/improving tools

@Tgr , as I mentioned earlier: Preferred button position - if possible. Layout constraints permitting. We had been thinking in terms of the location of the user rights icons on user and user talk pages.
We are aware that page rendering constraints may make this difficult but anywhere else on the page top would be acceptable but not centred and not among any maintenance banners that might be there. The idea is to make it clearly noticeable but not obtrusive.

Not all the welcome templates need to be included. NPP is not a general welcoming committee, it's only concerned with new(ish) users who have created a new article. Only the templates that are relevant from the New Page Reviewers' perspective are required. The reviewers should not be presented with a dilemma of choice.

Pretty much the same architecture as Twinkle's welcome system. Should have locally configurable content. The Growth team can tell you what a newbie is - it's their core work.

@TheresNoTime, off-Wiki discussions carry no weight at all. This has been more than sufficiently discussed and approved and your help with it has been enormously appreciated. One user's late complaint does not overturn a consensus. If Phabricator would work faster and if the other WMF employees here would prioritise issues that improve the the quality of new pages, there would be no need for requests for this feature and any others like it. Is Code Review done by volunteers or something? What's holding this up now?

This is not something that can wait until Phabricator decides it is important enough. It's part of the very remiit that gives the Growth team its name. NPP has decided it's important enough to:

1. Provide a better reception for new users
2. Increase the quality of new articles submitted by new users
3. Reduce the workload of NPP and AfC.

This has not received any attention for THREE years. We consider it important for improved onboarding of new users who have created articles. It should not be part of the Wishlist because it directly enters the remit of Growth which is essentially to improve the onboarding and UX of new users.

The important feature of the Kudpung mockup is that rather than attempting to explain the issues in detail and with a mass of alphabet soup, the message invites the creator to visit a very warmly presented page that is absolutely neither bitey nor accusatory, but which provides all the answers in a friendly way: at Help:Unreviewed new page and without presenting the creator with walls of text.

Target page:
Help;Unreviewed new page

The target page for the blue button link is already defined.

Oh well, we've been waiting for 10 years for this so what's another few weeks (or months)?

@MPGuy2824 Thanks for that. Apologies for the edit conflict with gerritbot above.

Are we sure this issue has been fully identified? Originally, as far as I remember from 10 years ago, it was also supposed to be possible to message the creator without marking as reviewed. This is often necessary, it avoids having to load the creator's talk oage and wtie a message there.

Not only in 2012, did an RFC decide that unpatrolled articles should be NOINDEXED until reviewed and accepted, but it was also in the MediaWiki manifesto at Page Curation. 10 years is a long time to wait and there's no knowing how many 100s of thousands of junk articles reside today in the corpus. Let's not wait another 10 years for a code review.

What is the actual status of this request right now? Is is stuck at code review or something?

I don't think this has ever been done. At least I've not come across any in the feed yet. @Novem_Linguae do you know anything about it? What is the actual status in in non-dev jargon?

Originally created seven years ago I am surprised that this task was not addressed at that time. As I wrote above in 2018:

Thanks everyone. I would be curious to know why it took four years, but that's another topic.

@Novem_Linguae, does that mean that someone has checked locally to see if drafts are in fact no longer being indexed?

Hang on... Sorry, @Novem_Linguae , I don't fully understand the Phabricator colloquialisms. Does this mean the task as originally requested by @TonyBallioni four years ago, and which @Primefac endorsed as

Images that are specific to en.Wiki don't need to be uploaded to Commons. Unless you want to share it, local upload suffices.

How about a cheap workaround with:

The 2011 New Page Patrol (NPP) system development page at MediaWiki is called Page Curation, and in its early stage the project was code-named Page Triage. It deals with the development of both the new feed and the Curation Tool.

All those years ago 'Page Triage' was proposed by the WMF as a consolation prize for so rudely denying the massive consensus for ACTRIAL, I worked closely with them during its development - but from the aspect of a patroler and not as a software developer. Fast forward to 2022: we now have ACTRIAL/AQREQ, and we have a special user group of (hopefully) experienced New Page Reviewers, and we finally have a much enhanced curation system. But the problems of patrolling persist and despite having over 750 patrollers (of whom half have never made a patrol), today's backlog stands at around 12,000 articles.

@kaldari Thank you for reminding me of that discussion, Ryan. NPP is now nearly bankrupt despite my having created the user right for it in order to introduce some quality and competency into the system.
I am not a software engineer and I do not pretend to understand the purely technical issues, but we need this request addressed urgently now to to avoid NPP collapsing altogether.

@TheresNoTime Thank you for un-stalling this.
There certainly has been more than sufficient discussion on-Wiki. It was part of the original development and and consensus has been affirmed twice since - please see the folded comments above - in 2016 and again this year.
Can it now please be implemented without any further delay?

Draftspace shouldn't be indexed anyway. They are either new article submissions that have been rejected by the New Page patrollers, ('draftified'), or articles created directly in draft space, possibly coming from the Article Wizard, and are a work in progress. Either way, as soon as they are moved to mainspace they will (or should) appear in the New Page Feed for review at NPP.

We are talking about mainspace only AFAIK, and as far as I understand, there would be no point in un-indexing articles that have already dropped off the queue into the search engines' clutches.

@TheresNoTime I lack any technical knowledge, but I assume that to replicate it you would need to find an article in the feed (or create one) that should be sent to AfD and initiate the process from the Curation tool.

Obviously no one has bothered to read this discussion with @kaldari and @Roan Kattouw. I think there is still a lot of misunderstanding about the role of new page patrollers/reviewers and the workflow involved. I've been deeply concerned with 'NPP' as far back as I can remember and I was overjoyed when Eric Möller agreed to allocate funds and personally collaborate closely with some patrollers and me to develop the new system.
Has anyone here actually taken a moment to read WP:NPP and WP:NPR? I have - I wrote them.

As previously mentioned 'millions' would be a great exaggeration. There are 'only' 6.5 million articles in the entire enWikipedia.

@Krinkle : It is most unlikely that this affects a majority of the 6.5 million articles on the site.

@Aklapper Many of us are aware of that page - that's why we keep asking here for cooperation and support for NPP which is not only an essential function on the en.Wiki, the WMF's flagship project, but also a software that was developed not by volunteers, but by paid WMF engineers.

@Aklapper Long overdue by several years. This is a software bug. It's not a request for a new cosmetic or convenience feature. It does need to be addressed.

@Aklapper This is quite urgent because this fix is long overdue and NPP is in crisis with a huge backlog. Many are now using Twinkle instead which does not provide the essential information and features, therefore the accuracy of the patrolling by less experienced reviewers is not good and creates more work for other patrollers who have to correct them and explain what they are doing wrong (diffs available). Of the 700+ reviewers, only a tiny fraction will do any patrolling and more are abandoning NPP due to frustration (diffs available).

@Aklapper could you please ensure that this bug is addressed as quickly as possible. Thanks.

It seems that this bug has never been processed. It's driving reviewers away from the process just when NPP has a massive backlog and needs all the help it can get. Would it be possible to do something about it now? @MarioGom , @Joe Roe , @DanCherek , @MusikAnimal

It seems that this bug has never been processed. It's driving reviewers away from the process just when NPP has a massive backlog and needs all the help it can get. Would it be possible to do something about it now? @MarioGom , @Joe Roe , @DanCherek

@Stang

Hello everyone, Phabricator is not a place to reach community consensus, please discuss on English Wikipedia, thanks.

Quite right - this is not the place to relitigate a recent consensus.
The issue has been discussed a total of 3 times, each time reaching a consensus. Following the 10 year old strong consensus a WMF staff member confirmed that it would be developed, but it was later conveniently swept under the carpet. It has been discussed and reaffirmed recently (see the links I posted above). Consensus has not changed. @IAmChaos reiterates again the exact reasons for the consensus having been achieved.

I left comments on the local thread, which I think is the right venue for discussing the community merits of the request. There certainly is no rush here, if this is what the community wants so be it - a slight delay isn't going to be a big deal.

@Xaosflux This software modification request is essential and concerns uniquely the huge workload of the New Page Reviewers, and hence the need to avoid unpatrolled pages entering the encyclopedia corpus as verified suitable for indexing by search engines.
It is a request local to the New Page Review system and its authorised users and does not need a broadly publicised RfC. It does not impact all users in any way - having your article referenced is an advantage but not a right; nowadays most of the new articles that are submitted are unlikely to benefit greatly from being listed by Google. Like most websites, Wikipedia does have its own buil-in search engine.
The vast majority of new pages that exceed the previous 90-day limit are borderline notability or suitability cases that have either been left for reviewing by more experienced patrollers or simply could not be reviewed in time - the backlog is immense; backlog drives have had some minor effect but it would still take a year or more to clear it.
Each time the backlog has been successfully cleared by an all-out campaign, the reviewers have relaxed their participation and the backlog has very quickly grown grown again to an untenable extent. Of the 700+ New Page Reviewers, less than 10% are active and very few are sufficiently experienced to patrol the pages quickly but accurately, and others are leaving due to burnout.
This is only one of the immediate solutions required by NPP. Others are also being implemented in an attempt to keep the encyclopedia free of spam and other totally inappropriate mainspace content.
New Page Patrollers, like all the other maintenance workers, are not paid for this mind-numbing and thankless task and it is therefore irresponsible to continue submit them to stress. and make those who do it feel guilty for not doing enough.

@Atsme: nothing. My post and adding you as a follower was FYI only. I'm very pleased it's being done.

Hi @MMiller_WMF , thank you so much for this good news. It comes as extremely welcome at a time when unscrupulous users are increasingly finding new loopholes to get their inadmissible and inappropriate new articles past our controls. Huge thanks also to @taavi for taking it on and getting it done in record time. FYI: @mb , @Novem_Linguae , and @Atsme.

The Growth Team formed in July 2018 to support the Wikimedia Foundation's long-term goal of "Knowledge Equity" through the Audiences department's "New Content" program. The "Knowledge Equity" goal and the "New Content" program are about building strong communities that make diverse knowledge available to people all over the world. One critical pathway toward those goals is through engaging new contributors in Wikimedia projects. But because of the cultural and technical skills needed to productively contribute to the projects, very few people who begin to contribute continue to do so in the days and weeks after their initial involvement. The Growth Team's objective is to address this problem through software changes that help retain new contributors in mid-size Wikimedia projects, starting with Wikipedias.

I'm surprised this wasn't already standard. I kind of took it for granted that it was. Needs to be done quickly.

@JJMC89 could we have an answer please?

@JJMC89 what is the actual status of this request right now?

What 'local discussion'? That is what is confusing the NPP task force. Yes, you can easily change the code. It would be great if you could do it as soon as possible because the NPPers have some other wok to do too, and much depends on how quickly this NO INDEX can be done.

Stang, could you please elucidate what is meant by

Repeat: The request is not to change wgPageTriageMaxAge from 90 to 365 days, but to have no limit so that articles must be reviewed before they are indexed per the RFC. This is a straightforward request from en.Wiki. There are no technical constraints. Please effect asap. Thanks.

This is a straightforward request from en.Wiki. There are no technical constraints. Please effect asap. Thanks.

@Ladsgroup - I may not have been quite so blunt, but concur with @Snottywong, who with others and myself are still smarting from the disgusting behaviour of the WMF at Bugzilla several years ago when they told us, with personal attacks, that they would refuse to 'allow' ACTRIAL. Fortunately a couple of years ago, a new breed of director-level devs not only agreed such a major policy and change of principles is a local Wikimedia remit, they even provided extensive help to implement the trial, and excellent stats which fully proved the WMF's earlier conjecture to be totally false.
You may be an admin here, but you don't get to unilaterally decide what the major Wikipedia projects can and cannot do, especially when it concerns a good faith, but totally anachronistic piece of 'Founding Principle'. Such an attitude on en.Wiki would get an admin quickly stripped of their rights.
The Universal Code of Conduct was very recently accepted at its voting (by a small majority), some of us don't like it, but now is the time to uphold some of its values.

Just noting my surprise that this is so complicated and creating such a challenge.

@Huji No worries 🙂

@Huji who is 'Martin'? For the benefit of all participants who are not privy to the cliques of devs, could we please stick to user names? Thanks.

These ten options are not based on a pragmatic approach. Nor are they tailored to the workings of all the Wikis. The the idea of abolishing IP editing stems from a cold look at today's reality in which a vague founding ideology is now a poor fit - an anachronism. The 10 proposals would integrate well in an editing environment already devoid of IP edits but which, such as the en.Wiki, still has more sinister demons to slay than simply vandalism.
The 10 points also involve significant development time and costs without any proof that the measures would in fact work. It is also highly unlikely that creating more reviewers / patrollers will happen. Existing patrollers have all the power they need and will not agree to a larger workload at the whim of the paid staff. Most users who take their patrolling seriously will not be newbies or doing it from a mobile device.
ORES has been rolled out on en.Wiki and does a good job, but AI is limited. What the reviewers and patrollers do needs human instinct and cannot be supplanted by filters, scripts, and bots.

In T291018#7363981, @Erico wrote:

I support the self-determination of projects and therefore I consider that fawiki has the legitimacy to request the ban.

In T264940#7219057, @patilise wrote:

I wonder if we could have a version for other wikis as well (e.g. enwiki as the largest one, jawiki as a sample for wikis with more unregistered users), probably on a separate page.
The data we currently have allows a comparison of ptwiki before and after editing by IP editors was turned off; having other wikis would allow us to make sense of ptwiki data before turning off editing by IP editors, especially on how similar/different the situation was between ptwiki and other wikis, so it is easier to assess whether the ptwiki experience could be applied on other wikis.

There is going to be a RFC on en.Wiki soon and this data would be essential. Is this being prepared? Is there an ETA on it?

@MusikAnimal Thanks. Explanation accepted. I must have misunderstood it at the time.

There used to be a link on the sidebar:
'Curate this page'
Somewhere along the line this feature got removed.
It should only have been visible to New Page Reviewers.
It's my guess that someone has confused it with the 'Add to New Pages Feed' feature request - which is now up and running as requested, and removed it.
However, Curate this page' is somewhat different - it's supposed to allow any New Page Reviewer to review a page without having to load it into the feed first.
Can we please have it back?