@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?

As far as i can see, the request is for use with the Curation toolbar that can only be used by New Page reviewers, and therefore only concerns AfD for new mainspace articles and not the various MfD venues for other mainspaces. Twinkle works for those others.

OK, I'll buy that.

Why would a New Page Reviewer want to relist the main page?
As far as I understand, relisting is confined to users of the NPR right, is that not so?

Looks good and works, except the pop-up calendars do not work as expected. Possibly due to the unique US date format instead of the international one?

What is the actual progress on this?
The script didn't work today - it only completed half the job and then put some of the elements on the wrong pages. Relying on Twinkle (which works) as a backup system is not a solution for me.

This feature is not an unreasonable request, but as I said above, I'm not absolutely sure that the number of times this happens is sufficient to dedicate a lot of dev time to it if it is complicated to do.
90% of the patrolls are done by less than 10% of the patrollers. That 10% is highly experienced and they would probably see this for themselves. I also do not think the entries in the feed should become so cluttered with info that they lead to banner blindness. Personally I believe we have more urgent requests on the wish list to address, especially the other hallmarks of COI.

Isn't it fairly obvious to a New Page Reviewer if there is a similarity between page name and user name?

@Halfak I am surprised again to hear that bugetary topics are an issue. They are frequently raised as a reason for not getting things done or not accomplished in a timely manner, but the WMF is currently very over funded by a large surplus.

@Aklapper, I'm asking you because by default in the absence of any published delegation of authority, you appear to be the de facto (or official) person in charge at Phab. Hence the 'go-to' person.

@Barkeep49, in which case it's probably not a priority anyway. A 'nice-to-have', but not essential.

Note: I personally do not beleive that this request is a priority.

I have never been able to get https://en.wikipedia.org/wiki/User:Ale_jrb/Scripts/csdhelper.js to work.
This really needs to be added to the Page Curation system.
@Aklapper , could we have an update please?

@Aklapper could we please have an update on the stat5us of this please. The courtesy of letting us at least know if you have shelved it would suffice. Thanks.

@Aklapper could the NPP community please have an update on the status of this request. It appears to have been a year and a half with no action. Thank you.

This doesn't look quite like the original request at Suggested Improvements. Can we have an update please in layman's terms?

@Aklapper What is the current status of this request?

This request was heavily endorsed at Page Curation Improvements. This is about the way new users are treated and is a critical issue.

@MusicAnimal What does this status mean to a layman? Is it done or isn't it?

This request was endorsed by one user only at the NPP Improvements page.
It's not something I would use. I don't believe it to be a high priority requirement and the move of this task to 'Triaged but future' seems appropriate. Other Page Curation tasks are far more urgent.

Yes, it's better than nothing and very useful, but I am also concerned that every new piece of page meta information we now start adding to the entries in the feed will not only introduce clutter to add to a patroller's bewilderment - I'm thinking here in terms related to Banner Blindness, a phenomenon well researched by information scientists, well before the advent of the Internet.
I suggest the info be displayed as:

I'm still not sure that what is being done here corresponds exactly to the original request at Page Curation, Suggested improvements. I don't see any mention in No.80 of putting pages back into the feed.

I'm not sure that this is useful at all. It's not something that will help me with my patrolling. Maybe I'm missing something, but a new page, unpatrolled and thus non indexed, shouldn't have any page views except by its creator and/or reviewers.

I'm not sure that what is being done here corresponds exactly to the original request at Page Curation, Suggested improvements.

To save looking it up, the full text of this request is:
Pages that have been tagged for maintenance issues (but not for deletion) and are otherwise just acceptable for inclusion, should be shown not with the green 'checked' icon, but with an orange blob that contains a capital T. It should be obvious that this would enable admins who are patrolling the quality of the patrollers themselves rather than new pages, can immediately revert any tags that have been inappropriately or erroneously applied, and replace them with correct ones or use the 'unreview button' which should then send the 'unreviewed' message automatically to the patroler, using a dropdown list of canned reasons

I seem to recall that at the very beginning, 'Page Triage' was developed with the intention of it being 'agnostic' - that being the reason why it was built as a MediaWiki extension. @kaldari will know more. Whether or not other WMF projects use it, as they grow they will be needing something like it. In any case, with a bit of luck, all the requirements will be addressed following a successful poll at the Community Wish List. It could even be a reason to put a dedicated team on it.

User:Evad37/MoveToDraft was written because of the WMF delay in writing it. It does everything the original request made since by https://en.wikipedia.org/wiki/User:Czar on en.Wiki in 2015. It's since been requested by the community many, many times.
Can it now finally be added to the Curation Toolbar - primarily to restrict its use to the New Page Reviewer group to avoid its overuse/abuse by unqualified editors. Thanks.

Email of Editor-in-Chief: cs@edubkk.org

I'm a bit concerned as to why this is being referred to as Special:NewPages. The correct default New Page Patrol GUI is at Special:NewPagesFeed. Perhaps I'm missing something.

8 months and no comments?