Jump to content

Wikipedia:Page Curation/Suggested improvements

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Page Curation

This is an old revision of this page, as edited by Bunnypranav (talk | contribs) at 07:46, 26 December 2024 (fix). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

TutorialDiscussionNew page feed
Reviewers
Curation tool
Suggestions		Coordination
NPP backlog
Articles
15454 ↑214
Oldest article
5 years old
Redirects
1928
Oldest redirect
5 months old
Article reviews
1702
Redirect reviews
6234
  • There is a very large articles backlog
  • The articles backlog is growing very rapidly (↑845 since last week)
Shortcut

History

See also: Wikipedia:Wikipedia_Signpost/2018-10-28/Special report

WP:ACTRIAL, a proposal to limit new page creation to autoconfirmed editors, was proposed in 2011 and influenced the creation of PageTriage.

PageTriage was created by the WMF in direct collaboration with some New Page Patrollers in 2012 as a feature-rich New Page Feed and Curation Tool to replace the much simpler 2006 patrolled edits feature that comes pre-installed on all wikis. This process was driven forward by Kudpung with help from Erik Moeller (WMF). The developers that created PageTriage were Kaldari and Bsitu.

In 2016, the new page patroller permission was created, limiting marking a page as reviewed to these editors (and to admins).

In 2018, the WMF Growth Team did some work on PageTriage, again in direct collaboration with some New Page Patrollers as part of Wikipedia:WikiProject Articles for creation/AfC Process Improvement May 2018. This resulted in ORES and Articles for Creation being added to the New Pages Feed. MMiller (WMF) was the product manager that helped implement this.

In 2019, after a large backlog of Phabricator tickets developed, NPP added Page Curation and New Pages Feed improvements to the Community Wishlist. It was voted #1, which helped to get the WMF Community Tech Team to add new features and to reduce the backlog of Phabricator tickets.

Except for these brief spurts of activity, the tool doesn't receive much technical support. As of 2022, we are making a renewed push to collect issues (bugs and required features), create Phabricator tickets, and convince developers to work on PageTriage. Wikipedia:New pages patrol/Coordination/2022 WMF letter received 444 signatures, possibly making it the largest open letter in the history of enwiki.

It has been suggested that Twinkle may be a workaround for some issues. However, Page Triage was expressly designed in 2012 to be a "one stop" tool to avoid switching back and forth between various menus, scripts, and gadgets.

Redirects - issue 2

Redirects converted to articles should be in the feed but indexed by the date of creation of the article, not of the redirect, and by the username of the creator of the article, not of the redirect.

Tracked in Phabricator
Task T157048
This would be very useful. Probably a little more complicated to code.- MrX 12:45, 2 September 2016 (UTC)[reply]
Currently, if a five-year-old redirect becomes an article today it is posted to the back of the queue and looks like it has been there for five years. The creation date in this case should be the first date substantial content was added, not the date the redirect was created. VQuakr (talk) 23:32, 8 September 2016 (UTC)[reply]
And the automatic "your page has been patrolled" message goes to the creator of the old redirect; no message goes to the creator of the article unless the patroller is aware of the situation and goes to the extra trouble: Noyster (talk), 11:13, 9 September 2016 (UTC)[reply]
Agreed, especially since when a page is tagged for deletion the same thing happens. A notification should be posted to both the redirect and the article creator (as when a page is tagged for deletion the redirect creator may have comments too.) Blythwood (talk) 04:48, 4 October 2016 (UTC)[reply]
Id like to see this. Lineslarge (talk) 00:05, 25 September 2017 (UTC)[reply]
Phab status unclear. Kudpung กุดผึ้ง (talk) 02:46, 13 September 2019 (UTC)[reply]

Article Creator From Redirect

Tracked in Phabricator
Task T157048

When an article is created from a redirect the "was created by" data should be whoever created the article not the redirect. This both allows for correct filtering and also closes a loophole where a reviewer could reviewe their own articles. Best, Barkeep49 (talk) 22:50, 24 January 2020 (UTC)[reply]

phab:T157048 DannyS712 (talk) 23:12, 24 January 2020 (UTC)[reply]
Support Mccapra (talk) 11:40, 14 November 2021 (UTC)[reply]

Redirects - issue 3

Perhaps more difficult: when an article is converted to a redirect and that action is then reverted, it should not appear in the New Page feed.: Noyster (talk), 11:36, 2 September 2016 (UTC)[reply]

Tracked in Phabricator
Task T92621
I'm not so sure about this one.- MrX 12:45, 2 September 2016 (UTC)[reply]
If an article is not in the NPP list (too old, or, I believe, also if it has been patrolled), then it either is reduced to a redirect or gets vandalized with all content removed, and subsequently is restored to its previous state, it should not return to NPP. One can set some limits here, for example, if the content is restored within a day.--Ymblanter (talk) 18:53, 8 September 2016 (UTC)[reply]

Notifications: new icon

Tracked in Phabricator
Task T157051

Pages that have been tagged for maintenance issues (but not for deletion) andare 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. Kudpung กุดผึ้ง (talk) 04:48, 4 September 2016 (UTC)[reply]

  • Support I second this. It would allow us to have a different message sent to the user. Currently if you green check a page that youve tagged for deletion, and send them a message telling them why it is inappropriate, they get a very passive aggressive "Thanks so much for submitting that article! Which is crap, please don't do so again." It should have a different user page template when sending the message to the user that goes along the lines of "Page so-and-so has been tagged for maintenance..." — Insertcleverphrasehere (or here) 21:30, 20 August 2018 (UTC)[reply]
  • Support - verrrry much needed! I have actually discovered a PE who was tagging articles with Notability tags, and they were the article's creator. Imagine the gall... Atsme 💬 📧 22:29, 15 July 2022 (UTC)[reply]

Welcome message

Tracked in Phabricator
Task T207225

Include a button to optionally place a "welcome newbie" on a creator's talk page. First suggested by WereSpielChequers in 2012, this could offer a dropdown à la Twinkle of some of the more relevant wecome message templates. Kudpung กุดผึ้ง (talk) 21:43, 7 September 2016 (UTC)[reply]

Aside from the advantage that welcoming is known to give, some of our patrollers get into the mindset of wanting to do something with each article they look at. Welcoming a newbie as an alternative might help shift some people from the mentality of trying to work out which deletion tag or article improvement template is most applicable to a new article. ϢereSpielChequers 22:32, 7 September 2016 (UTC)[reply]

Barkeep49, can you follow up at Phab, because I don't have a clue what all their statuses mean. If it means that it has been put at the end of the 500+ tasks in waiting, we may have to make a new case for it in the next Wishlist. Kudpung กุดผึ้ง (talk) 03:00, 13 September 2019 (UTC)[reply]

Kudpung, will check on it in the morning. I believe it should be somewhere in their queue of stuff and they haven't gotten to it. In general comunication explaining how they were going to approach the wishlist development work is less than I hoped or experienced when they put AfC into the queue. Best, Barkeep49 (talk) 03:06, 13 September 2019 (UTC)[reply]
Kudpung looks like this didn't make the final cut of wishlist items and so would have to go on for some future development. Best, Barkeep49 (talk) 01:49, 14 September 2019 (UTC)[reply]
Yes,it is worth it because it falls directly within the mission statement of Growth. It's been shoved aside again for the last 3 years and needs attending to. @MB and Novem Linguae:, can you subscribe yourselves to the Phab ticket please? Kudpung กุดผึ้ง (talk) 12:04, 29 October 2022 (UTC)[reply]

Articles by previously warned editors

Reproducing here the original 2012 suggestion by WereSpielChequers: There are three bits of information that would be really useful to know re the previous articles created by the same editor. For badfaith editors who've had articles deleted G3 or G10 it would be really useful if their subsequent articles were highlighted in red on the screen so that people knew to check them first. For Goodfaith articles it would be useful to know how many articles someone has previously created, or at least to have a little prompt or filter for those who've done 50 or more so you can easily spot candidates for Autopatroller status. Also if you've just patrolled or tagged an article having the option "Look at x other unpatrolled articles by this author?. Kudpung กุดผึ้ง (talk) 22:48, 7 September 2016 (UTC)[reply]

Thanks Kudpung. We've got the list of potential Autopatrollers now at Wikipedia:Database reports/Editors eligible for Autopatrol privilege so that doesn't need folding into curation, but it would still be good to bring extra skeptical attention to editors who have created G3 and G10 articles. I'm no longer quite so sold on the "Look at x other unpatrolled articles by this author?" button as I can see that being used by sloppy deletion taggers to tag everything else that an editor has created. ϢereSpielChequers 13:36, 13 September 2016 (UTC)[reply]
Given the lack of any secondary supporting votes, this suggestion may not have consensus to be implemented. If there is no further discussion in 10 days, it will be archived. -MPGuy2824 (talk) 08:18, 29 October 2022 (UTC)[reply]
This would be very useful. Perhaps we can remind WereSpielChequers of his suggestion and maybe @MB, Novem Linguae, and Onel5969: would like to chime in. . Kudpung กุดผึ้ง (talk) 12:09, 29 October 2022 (UTC)[reply]
Thanks for the ping, Kudpung, and I guess I should put this page on my watchlist, huh? At the current state of the queue, this is not so important, but when the backlog gets back up to 1-2000 (and it will), this would be very useful. Especially the last part of Kudpung's suggestion. When the backlog gets long, and I came across a well structured, well cited article, I would open up another queue looking for any other unreviewed articles by that editor. This would make that simpler.Onel5969 TT me 12:19, 29 October 2022 (UTC)[reply]
I agree we don't need to be using Page Curation to detect potential Autopatrol candidates. The last part about an option to show other unreviewed articles by the same editor is covered in T313647 - I opened that independently of this not seeing the duplication, so I certainly think that would be useful. It can be helpful, not to sloppily tag all articles by one editor but to quickly approve all articles by one editor if a pattern of confidence emerges. The other part, notice of previous G3/10 deletions by the same editor seems useful to me and needs a ticket opened. MB 13:46, 29 October 2022 (UTC)[reply]
This is 3 feature requests, so splitting into 3 subsections. –Novem Linguae (talk) 17:01, 29 October 2022 (UTC)[reply]

Highlight articles in red by editors who have had a G3 or G10 before

Would be technically complicated to implement. Would need a hook to listen for CSD taggings, and then an SQL table to keep count somewhere for each user. Can't use pagetriage_page_tags because that is per page. Can't use pagetriage_log because it only logs patrollers, not all users. Edge cases would include aliases of the CSD templates, and the case of untagging it instead of deleting it (false positive). –Novem Linguae (talk) 17:05, 29 October 2022 (UTC)[reply]

I was hoping this would look at deletion reasons rather than tags. This isn't just that some taggers are heavy handed, but also that some taggers use a less urgent tag on articles that merit a G3 or G10 deletion. Providing we can get the proposal back to deletion reason not tag reason I think this would be useful as it would speed up the removal of attack pages from Wikipedia. ϢereSpielChequers 21:51, 29 October 2022 (UTC)[reply]

Display count of articles a user has created (display where?)

Would be technically complicated to implement. Would need to track a user's article creation count (either using a hook, or an SQL query), and then store the data somewhere. As above, PageTriage doesn't have a table yet with the user as a primary key. An edge case would be deleted articles, which might not show up in the count depending on how it was implemented. –Novem Linguae (talk) 17:08, 29 October 2022 (UTC)[reply]

Technically easy to implement. If this feature is requested by a couple people, let's make a ticket. –Novem Linguae (talk) 17:09, 29 October 2022 (UTC)[reply]

Patrolled by Twinkle

Tracked in Phabricator
Task T207477
See also #28 below.

Some people (generally older users) are still patrolling from Special:NewPages and Twinkle. As here is a delay in display time of the New Pages Feed (it is only refreshed when updated by the patroler), it would be useful if a 'T' icon could be displayed indicating that the article was already patrolled from the old feed. This would help recognise articles that are copy-and-paste creations. Kudpung กุดผึ้ง (talk) 23:09, 7 September 2016 (UTC)[reply]

@Barkeep49, Insertcleverphrasehere, DGG, and Jbhunley:, No, I'm talking about a feature that shows if a patrolled item in the feed was patrolled using Twinkle. Semi automated edits using Twinkle are shown as such in edit summaries as '(TW)' so IMO if there is something that recognises this already, it should be possible to show it in the feed. The reason for this is to eep track on just what extent Twinkle is still benig used for reviewing new pages, and to encourage users to Curation instead. Kudpung กุดผึ้ง (talk) 01:52, 14 September 2019 (UTC)[reply]
I'm not sure how much it matters if some things are looked at twice. DGG ( talk ) 04:36, 14 September 2019 (UTC)[reply]
Twinkle Tags and reviews are not linked .... This needs quite-much work but will be a nice feature, to have the luxury of. ∯WBGconverse 05:13, 14 September 2019 (UTC)[reply]

Tool for moving to draftspace

Tracked in Phabricator
Task T124396

Mentioned several times around the site but first suggested here 13 December 2015 by czar. Kudpung กุดผึ้ง (talk) 14:16, 8 September 2016 (UTC)[reply]

  • Show as 'Move to Draft' in the Curation tool actions list
  • Move the page to Draft:articlename without leaving a redirect
  • Send this message to the creator:
Hi (USERNAME), thank you for creating a new article. Unfortunately it's not quite ready for publication but to allow you to continue to develop it without fear of deletion we have moved it to Draft:articlename. When it is ready, please submit it to AfC for review and if it's good to go, a reviewer will move it back to mainspace for you. You may wish to read WP:My first article, and if you need more help, do post a question at The Tea House

We will need to impress upon patrollers however that this feature should not be over used or as a get out for not knowing how to tag the article.

--Kudpung กุดผึ้ง (talk) 00:46, 13 October 2016 (UTC)[reply]
Move the page to Draft:articlename without leaving a redirect – this is technically impossible unless you are a page mover or admin. We could make it tag the redirect as WP:G6, though — MusikAnimal talk 23:02, 15 October 2016 (UTC)[reply]
Yes, I just did this yesterday, and have done it at least once or twice on previous occasions. (Note: I am not an active "NPP" (more of an "old pages partroller"!), and only occasionally come across stuff like this when working for the WikiProjects like FILMBIO...) It sounds like maybe there should be a move to encourage Page movers to do NPP? (Or someway to grab the attention of Page movers to move New Pages into Draftspace without leaving a redirect? – Some kind of maintained maintenance list perhaps?... If somebody came up with such a list, I'm probably one of the PM's who might watchlist it.) --IJBall (contribs • talk) 06:07, 27 February 2017 (UTC)[reply]
  • Oppose. I have some concerns about this. I can see moving to draft becoming a form of unilateral "soft deletion" with no discussion, no admin oversight and no limits on what can be deleted. New editors (i.e. not autoconfirmed) won't have the technical ability to move their draft back to mainspace without going through AfC (which is supposed to be an optional process). Even if they did, they wouldn't necessarily know that's what they're supposed to do, or they might assume their article has been "rejected" and give up on it. There's a huge potential for biteyness and I think a lot of these drafts would end up abandoned and G13ed. I think if this were to become common practice, or if were to be built into Page Curation, there would have to be a wider discussion to establish a community consensus for the process and agree some guidelines on what circumstances it can be used and if any oversight is necessary. – Joe (talk) 11:26, 27 February 2017 (UTC)[reply]
  • Support - As far as I know, any autoconfirmed user can move any page to draft space, The admin oversight would come into play when the redirect CSD is reviewed by an admin. Those of us who are not admins, but are WP:PAGEMOVERs, should be trusted to move articles to draft without a redirect unless it is shown that we have abused that right.- MrX 14:57, 15 June 2017 (UTC)[reply]
  • Strong Support - Kudpung กุดผึ้ง (talk) 15:59, 15 June 2017 (UTC)[reply]
  • Strong Support @Kudpung, Note that such a tool already exists in the form of a script: User:Evad37/MoveToDraft. However, this should also be a feature of the page curation tool. If the user has the Page Mover user right, it should move without leaving a redirect, and if they don't, it should automatically tag the redirect for CSD R2. Many articles that end up PRODed or CSDed would be much better off draftified. In my experience, often up to a fifth or so of all new articles in the new pages feed would be best served by being draftified (varies by time of day). Draftifying encourages new users to continue working on the article, while tagging for deletion discourages them (why bother if it is going to get deleted anyway, especially in the case of CSD). In any case, Draftifying articles is currently difficult and time consuming as a manual process and the automated tool available is obscure and does not automate tagging as CSD R2 for non WP:PAGEMOVERs. Semi-automated Draftification should be made more available to New Page Patrollers through addition to the page curation tool. Note I originally posed a similar note to the page curation talk page before being informed of the discussion here.
@Joe Most of the feedback I get from new users when draftifying their submissions has been quite positive. They often have had trouble in the past with their new, undersourced, articles getting quickly deleted, and are grateful to have their article retained with the chance to work on it further; so I don't see a big biteyness issue. Those that don't understand the draftification, despite the message posted to them, will often just immediately recreate the article, in which case it becomes a matter of simply using the normal tag/PROD/CSD/XfD process if necessary and this doesn't really pose a problem at all. It isn't a catch all, many articles are better off CSDed, PRODed, sent to AfD, or simply tagged, but it is another tool in the NPP toolbox that should be made more widely available.
@IJBall I added the above script to the WP:PAGEMOVER page as well as the userspace to draftspace version, This should help Page Movers be aware of other uses of the user right. A better approach however is for admins who notice prolific and competent NPPatrollers to offer them the page mover right and explain its usefulness in NPP, and to make NPPatrollers aware of the usefulness of the user right so that they can request it. — InsertCleverPhraseHere 01:12, 21 July 2017 (UTC)[reply]
I am well aware of the script and gave been using it for some time. It's actually quite good. The problem is that the volunteers, such as Evad37 should not have to be making these tools. Of course, the Foundation will rejoice once more at the volunteers doing the devs work for them. There is absolutely no need for a major RfC to agree on this tool - Wikpedia is already stifled by senseless RfCs, What it does need however, is incorporating into the Page Curation tool so that i can only be used by accredited New Page Reviewers, and avoid being abused by unqualified New Page Patrollers, because in spite of the caveats above, based on empirical experince of tens of thousands of patrolls, they will almost certainly use it as a catch-all. Kudpung กุดผึ้ง (talk) 02:32, 21 July 2017 (UTC)[reply]
@Kudpung This is a good point. The worst part about Evad37's tool is that it does not automatically tag the redirect as CSD R2 if the user is not a Page Mover (I tested this with my old account that doesn't have the user right), rather it just creates a normal redirect to the draft. This is an issue as unqualified New Page Patrollers who find the tool and decide to use it will not get doublechecked by admins unless they go through the extra hoop of manually tagging the redirect for CSD. Paradoxically, adding this to page curation with an automatic CSD R2 for non Page Movers would actually result in more oversight of draftification, not less. — InsertCleverPhraseHere 02:49, 21 July 2017 (UTC)[reply]
  • Oppose This is contrary to the fundamental Wiki principle of developing articles in mainspace. If you have a notable topic then the draft should be in article space to make it clear that it already being worked upon. Otherwise, you are encouraging forking and generally wasting people's time by pushing stuff around rather than improving it. It is our policy that imperfect articles are welcome and this tool should not violate established policy. Andrew D. (talk) 19:27, 8 August 2017 (UTC)[reply]
Apart from being off topic here, Andrew Davidson, because WP:PERFECTION doesn't mention anything of the kind, and besides which, new users can't create in mainspace anyway, the choice is clear: pages that might have some potential but are suffuciently imperfect that they cannot possibly reside in mainspace are usually deleted; given the opportunity to develop their articles in a safe haven might not only result in a reasonble new article, but also one less new user gets bitten by having their article harshly deleted before it has been hardly begun. Kudpung กุดผึ้ง (talk) 23:48, 23 September 2017 (UTC)[reply]
  • Support Automates a process that is handled manually at the moment. scope_creepTalk 00:57, 14 September 2019 (UTC)[reply]
  • If we already have a good script, we should use it. I think it is a good idea that volunteers make tools. I think it's a good idea that we not rely on the paid developers unless they are actually needed. The more of the programming is done by regular WPedians, the better. But I certainly do use move to draft -- the main thing that's needed is that Evad37 or someone work on the current script further to make it easier to give different reasons. DGG ( talk ) 04:39, 14 September 2019 (UTC)[reply]
    Given what it takes to update something built into the toolbar for areas like this which are complex, I agree with DGG that we're better off having a user script, especially one that has as capable of a developer as Evad maintaining it. Best, Barkeep49 (talk) 04:41, 14 September 2019 (UTC)[reply]
  • Comment: I don't see much value in adding this to the toolbar, given that we have User:Evad37/MoveToDraft. It would probably be easier to improve the user script to mark the R2 deletions as reviewed. MarioGom (talk) 11:32, 14 November 2021 (UTC)[reply]

DYK information

I first mentioned this about a year ago; but it would be nice if, when NPP patrollers find an article that is decent and mark it patrolled without adding any clean up tags, there was an easy way to either nominate it for DYK or at least send a message to the contributor informing them of the existence of DYK as a showcase for their article. Actually nominating it might be a bit much because of the burden on the nominator to do a QPQ, but if we have new users contributing good content the opportunity to have their work showcased on the main page is incentive to continue contributing, and NPPers should be informing them of that possibility. ~ ONUnicorn(Talk|Contribs)problem solving 14:53, 9 September 2016 (UTC)[reply]

Nice idea, ONUnicorn, but NPP is supposed to be a system for checking whether or not new pages pass the bar (sorry about the private pun). It we start using it for DYK suggestions it wil add clutter to the interface and people will want to use it for GA and FA suggestions. Generally the vast majority of new articles are from new or very inexperienced users and are practically all of very low standard. What we are generally looking for are articles that will be kept because they would probably survive AfD, and articles that must be deleted for non compliance with important policies, and to a lesser extent, articles that are not fit for publication but have potential and can be moved temporarily to draft space. --Kudpung กุดผึ้ง (talk) 06:14, 15 September 2016 (UTC)[reply]
@Kudpung: I have done a fair amount of NPP. I am aware the main point is to keep unacceptable content out. However, Wikipedia has a problem keeping new editors who are good. There is no effective reward for a new editor who submits a new article that meets our guidelines. Most new editors are unaware that new articles can be featured on the main page, and have no idea how to navigate the complex system that is DYK. All I'm asking for is the ability to click a box that would put a message on a new editor's page that says something to the effect of this. This should only be done if there are no problems with the article; if the patroller marks the page as reviewed without adding any clean up tags and elects to send the message. ~ ONUnicorn(Talk|Contribs)problem solving 14:21, 15 September 2016 (UTC)[reply]
I think this is a reasonable suggestion actually, especially with college editing Wikipedia projects that are meant to widen Wikipedia coverage on marginalised topics (women, ethnic minorities, etc.). It's a reasonable encouragement - a stretch further, but not unreasonable, to tell new contributors "This is really interesting. I think this information could easily be put on the front page of Wikipedia if you did a bit more work. Go here and it will tell you how." I am developing some form messages based on my own NPP experience and may add one for this situation. Blythwood (talk) 15:33, 1 October 2016 (UTC)[reply]
Blythwood, You may wish to take a look at Wikipedia:WikiProject User warnings. Kudpung กุดผึ้ง (talk) 00:29, 3 October 2016 (UTC)[reply]
Tracked in Phabricator
Task T207441

Together with Wikipedia:Page_Curation/Suggested_improvements#50._Proposing_Autopatrolled_for_user_creating_new_articles_of_a_very_high_quality, I have put these through as a request to be added to the 'Wikilove' section as templated options for High Quality Submissions. — Insertcleverphrasehere (or here) 08:10, 19 October 2018 (UTC)[reply]

You could use User:SD0001/DYK-helper to file DYK nominations easily. However, note that the DYK process includes a "QPQ" requirement which is time-consuming and not something IMO new page reviewers would be interested in. SD0001 (talk) 16:38, 15 September 2019 (UTC)[reply]
SD0001, QPQ strikes in, only after 5 DYKS, IIRC ..... But, that's a nice script:-) ∯WBGconverse 13:18, 18 September 2019 (UTC)[reply]

Keyboard shortcuts?

So that I don't have to wear out my finger pressing the accept button twice, and then advancing the next page. Wikipedia is not a video game, and if it is, controllers should be sent to all page patrollers for ease of use. L3X1 (distant write) 01:01, 10 April 2017 (UTC)[reply]

perhaps a script could take care of this? L3X1 (distænt write) )evidence( 12:10, 14 July 2017 (UTC)[reply]
L3X1, what shortcuts do you want and for what stuff? Make a list ... ∯WBGconverse 11:14, 13 September 2019 (UTC)[reply]
Winged Blades of Godric, I was thinking:
  • C, minimizes or expands curation toolbar
  • I, brings up or closes Page Info popout
  • L, opens WikiLove popout
  • R, opens review popout
    • A marks as reviewed or unreviewed, depending on case (IDK if this one is possible)
  • D, opens or closes deletion menu
  • N, advances queue. Thanks,L3X1 ◊distænt write◊ 16:44, 13 September 2019 (UTC)[reply]
IMO, a button to advance queue, and a button to review the page are the most important, if adding all of them is a burden. Thanks,L3X1 ◊distænt write◊ 22:42, 15 November 2021 (UTC)[reply]

I would like one shortcut. Sometimes when reviewing redirects, I find a whole series created by the same editor and after checking several I determine that I am going to pass them all. I would like one-click review option. Perhaps SHIFT-click on the check button for "mark as reviewed and advance" or maybe CTRL-SHIFT-click to make if more difficult to do by accident. Alternatively, some way to review all articles in the (filtered) feed with one click would be even more efficient - but that would need to have a confirmation, something like "Are you sure you want to mark all 23 as reviewed?" MB 14:12, 18 October 2022 (UTC)[reply]

Filters by a score of estimated public interest

Tracked in Phabricator
Task T207238

filter the content by a score that arbitrarily estimates public interest (pageviews x # of editors?) that way I would know that I would be spending time on the complicated judgement calls that count (I am an eventualist when it comes to backlogs: it doesn't really scare me that the backlog is massive, as long as the higher priority bits get taken care of first). I do article assessment for WikiProject Novels, and use the score filter, to prioritize which ones to assess of the multi-thousand article backlogs. This gives me the sense of hacking away at the relatively important, even if the backlog is never ending (for example, I would use this queue to pick the stubs that I would assess for relative importance to novels). Sadads (talk) 22:29, 19 June 2017 (UTC)[reply]

Support This has also proven very useful in working on WikiProject African diaspora--updating the popular pages report surfaced some unexpectedly highly visible pages that needed attention, and I agree that info really helps motivate work on them. Innisfree987 (talk) 18:11, 5 June 2017 (UTC)[reply]
Stop-gap report which is updated hourly: [1]. -MPGuy2824 (talk) 09:54, 23 August 2023 (UTC)[reply]

Review 'on hold'

I think it could it be very helpful if the Page Curation Tool could permit a patroller who has decided to review an article to then temporarily flag that page as being 'on hold', and for it to be automatically removed from the review list for, say, a period of 10 to 15 minutes. This should give a review enough time to do their work and would avoid a lot of overlaps and frustrating duplication of effort if it did. This seems to be quite a common experience at both the 'very recent' and the 'very old' end of the review list. By the time I've reviewed or tagged an article - and drafted helpful feedback for its creator - I commonly find another patroller has also reviewed that same page. I get the impression I'm not alone in experiencing these edit conflicts. If this is happening a lot, then it must not only be confusing for page creators, but is surely an inefficient use of limited volunteer resources, too. Is this a need perceived by others? Nick Moyes (talk) 22:42, 8 June 2017 (UTC)[reply]

Not a bad idea, but technically possibly complicated to design. I too sometimes have situations when I am researching a new page, another patroller has tagged it for deletion and an admin has already deleted it. Kudpung กุดผึ้ง (talk) 00:44, 9 June 2017 (UTC)[reply]
Tracked in Phabricator
Task T207438
@Winged Blades of Godric: Yeah that would probably work. — Insertcleverphrasehere (or here) 16:21, 22 October 2018 (UTC)[reply]

Decline CSD/PROD

Tracked in Phabricator
Task T207435

Include a ‘declined PROD/BLPPROD/CSD’ feature the choice of these messages.This would bring Curation in line with Twinkle and go a step further:

Hi. I’m just letting you know I have declined the CSD you placed on xxxxxxx because either it is either not covered by a criterion or this was not the approriate criterion. If you still feel the article should be deleted please use a different CSD rationale, or PROD it (recommended), or send it to AfD

Hi. I’m just letting you know I have declined the BLPPROD you placed on xxxxxxx because the article already has a link. If you still feel the article should be deleted please PROD it (recommended) or send it to AfD

Hi. I’m just letting you know I have replaced the PROD you placed on xxxxxxx with an appropriate CSD tag because the article is a clear case for speedy deletion.

Kudpung กุดผึ้ง (talk) 01:03, 9 June 2017 (UTC)[reply]

Also Requested above at Wikipedia:Page_Curation/Suggested_improvements#16._Decline_CSD.
Barkeep49, can this request be merged with No.16, and followed up at Phab? I'm sure it was on the wishlist. Kudpung กุดผึ้ง (talk) 02:24, 14 September 2019 (UTC)[reply]
Kudpung, I think 16 was merged here (they show the same phab ticket regardless). The scope of work that came out of the wishlist is on meta. In checking the original wishlist asks I don't see this ticket on there. While I was aware of what you and Insertcleverphrasehere did I was not really following along closely enough to know where this fell off. Best, Barkeep49 (talk) 02:41, 14 September 2019 (UTC)[reply]
Barkeep49, we only dispatched the high-priority tickets, after a discussion at Wikipedia_talk:New_pages_patrol/Reviewers/Archive_30#Task_List/Prioritising_tasks .... ∯WBGconverse 13:02, 14 September 2019 (UTC)[reply]

Ability to log CSD taggings to their CSD logs

Tracked in Phabricator
Task T207237

Some editors still use Twinkle to record their CSD taggings and editors can only look at logs made by using Twinkle. I think adding this feature will be a good idea for most editors. KGirl (Wanna chat?) 22:15, 24 July 2017 (UTC)[reply]

I always use twinkle for this reason. Is there not a way of logging CSD with page curation? If so that is a major flaw.— InsertCleverPhraseHere 22:28, 24 July 2017 (UTC)[reply]
@TonyBallioni: We're discussing about CSD tag logs being stored to user subpages, not this one. And also Insertcleverphrasehere, page curation and huggle don't actually log CSD tagging in a user subpage. KGirl (Wanna chat?) 00:12, 25 July 2017 (UTC)[reply]
I know, but we already have an easily accessible deletion only log for it that also has the advantage of not being deletable via U1. I'd oppose spending developer time on this feature when there is a log already and there are other features above that are already in Phabracator that seem like they'd make the functionality of reviewing new pages easier. TonyBallioni (talk) 00:16, 25 July 2017 (UTC)[reply]
For those of us that like to edit or organise our CSD log, it forces us to use Twinkle. — InsertCleverPhraseHere (or here) 20:46, 25 September 2017 (UTC)[reply]
The deficiencies of the page curation's logs are (as I see it, from a Twinkle user's perspective):
  • They are in fixed locations. With Twinkle I can (and do) opt to log CSDs & PRODs in the same file. When I see a recurrent title I only need to check one place.
  • The PC logs record the fact that the reviewer requested deletion. Twinkle records that the article being deleted was created by its author. When using the logs it's far more useful to know the identity of the previous author than the previous reviewer. A repeat author may be a sockpuppet, a repeat reviewer may be, um, a reviewer??
Just my 2¢. Cabayi (talk) 09:36, 30 October 2018 (UTC)[reply]

Assisted reporting at AIV of authors of blatantly blockably created pages

Tracked in Phabricator
Task T207444

Serious BLP violations, swrious spam, serious vandalism. Kudpung กุดผึ้ง (talk) 13:34, 31 August 2017 (UTC)[reply]

Adding a "Potential COI" alert to the feed

Tracked in Phabricator
Task T207757

The page curation list should show if a new page could have a potential COI issue or notability due to someone being a close subject. It should detect the tag or use a filter judging by things such as the username. Example a page created called "ExampleIncorporated" was made by a user called "JohnatExampleInc". A match program could be used to detect if a COI issue could be a problem with the page. AmericanAir88(talk) 02:22, 22 October 2018 (UTC)[reply]

@AmericanAir88: good suggestion. This could be done potentially very easily by incorporating data from Filter 148 as well as potentially data from Filter 149. I'll File a Phab Ticket. — Insertcleverphrasehere (or here) 15:33, 23 October 2018 (UTC)[reply]

Skip viewed articles

Tracked in Phabricator
Task T207759

The NewPagesFeed can get very long and require considerable effort to navigate to point in the queue that is not "newest" or "oldest". I would like an easier way to find unreviewed articles that I haven't seen yet. I often look through large numbers of articles to see if I note something that requires urgent attention. I also skip a lot of articles, especially when there are many on a topic where I would need to re-acquaint myself with subject-specific notability guidelines to review properly.

I would be able to navigate the NewPagesFeed faster if I could skip articles that I have already seen but for some reason decided not to review. That issue is most apparent in the curation toolbar, where the next button may take me to a a page I have already seen, but do not want to review. It can take a very long time to find articles that I am interested in reviewing by clicking next in the Curation Toolbar, and it can cause me to "get stuck" on a group of articles that remain in my queue. I then have to return to the NewPagesFeed, ignore the visited links (using a local CSS) scroll down to where I want to work, and continue with the Curation Toolbar from there. Eventualy, I keep returning to that same group of articles I do not want to review at that time.

I would like to see a new feature that allows me to see only those articles that I haven't seen yet. It does not require a change in the curation toolbar interface: clicking next always means skip this article; if I just reviewed it, it is also not shown to me again. The UI change that is required is an option box in the NewPagesFeed that lets me ignore those articles where I have clicked the next button. Call that "hide viewed" or "only show unseen" or something similar.

It would make my reviewing more efficient by facilitating a quick scan of unreviewed pages I have not seen yet, and selection of the ones I think need the most urgent attention. --Vexations (talk) 23:06, 22 October 2018 (UTC)[reply]

While I am more of a generalist, and prefer to review every article I come across one by one, I realise that this is very difficult to do, and most reviewers 'specialise' in one or more areas or aren't comfortable reviewing some articles. Being able to flick through to problem articles or past articles that you don't feel comfortable with and not have to see them again would be very useful. Logged in Phab. — Insertcleverphrasehere (or here) 15:45, 23 October 2018 (UTC)[reply]
Useful, but IMO not an urgently required feature. The original poster is not, or is no longer a New Page Reviewer. Kudpung กุดผึ้ง (talk) 02:43, 16 July 2022 (UTC)[reply]

nppbrowser equivalent / keyword search?

Tracked in Phabricator
Task T207761

Thanks for the tip about the https://tools.wmflabs.org/nppbrowser/. I found the ability to search by keywords to be very helpful.

I don't see this functionality in the Special:NewPagesFeed. It does include AfC but seems to lack the functionality / view of tools.wmflabs.org/nppbrowser. Is there perhaps a way to have the same keyword search for AfC drafts? The current options are

Show: (_) articles; (_)redirects; (_) both

It would seem to be fairly straightforward to add a "(_) drafts" option, but I'm not sure what would be involved. K.e.coffman (talk) 18:14, 13 October 2018 (UTC)[reply]

I've copied this from the AfC noticeboard as it seems to be a New Page Feed request that would also be of interest to NPR. Adding it to the feed seems smarter than trying to add all drafts to the new page patrol browser. — Insertcleverphrasehere (or here) 15:29, 23 October 2018 (UTC)[reply]

Community Control over criteria for possible issues

Right now the feed relies on ORES related criteria for certain labels in the feed, eg SPAM, attack, etc. That's all well and good and we should keep making use of ORES' abilities. However, it might be nice, spurred on by recent discussion around adding a COI label, if the community had some ability to add its own labels, perhaps through tie ins to Edit Filters, so that development of this feature were not dependent on criteria that we have to go to the foundation to get updated/changed/etc. Best, Barkeep49 (talk) 01:34, 26 July 2019 (UTC)[reply]

Barkeep49, if you're talking about all the options for comments and tags, etc the Curation flyout, what we need are: CSD delined, PROD declined, user warning for UPE, etc. Can you list in detail here the additions you would like to see?
On another note entirely, I'm not sure that ORES things are displaying in the AfC feed and that was the main reason for creating the AfC feed. Could you check that - it might be just my browser. Kudpung กุดผึ้ง (talk) 01:58, 26 July 2019 (UTC)[reply]
Well we're soon going to get a potential COI tag added to the list of potential issues. They're going to use edit filters 148 and 149 which are fairly rudimentary but nice enough. At some point in the future we might have some better COI detection tools available. At that point we'll need to go back to the WMF to get them to change. I would like the community to be able to "own" development of the toolbar as much as is feasible so we don't need to go back to the wishlist in a year, two years, 5 years, whatever in order to have the next round of updates done. It seems clear that the WMF isn't interested in supporting page curation except so far as we drum up support from the wishlist. So be it. In that case I would like the community to be able to own it in the same way we do so many other processes.
As for AfC it's working for me but it appears in a different place than for NPP. Are you looking right under the review button? Best, Barkeep49 (talk) 02:19, 26 July 2019 (UTC)[reply]
Barkeep49, there's an ORES model currently under development for detecting COI/(U)PE. The end result is expected to highly exceed the currently rudimentary methods of automated COI/(U)PE detection but I have no knowledge about the precise timeline and it does not help that the department is currently understaffed. Now, that I don't expect EFs to grow any more efficient than they are currently are, the next better COI detection tool will be near-certainly this ORES-COI-model, for the integration of which, we (obviously) need to go back to WMF.
So, I am inclined to think that the premises of your demand is a bit ill-founded. Also, while I have not followed their work on integrating abuse filters to the system, I can confidently assume that integrating EFs will be a tougher deal than just doing the elementary checks through it's own code-base. I agree 'bout the necessity of moving away from the hard-code style but that was a question which has been already answered wrongly, years ago. ∯WBGconverse 09:37, 13 September 2019 (UTC)[reply]
Winged Blades of Godric, I had not heard about the ores development. That's good news. Best, Barkeep49 (talk) 12:32, 13 September 2019 (UTC)[reply]
Winged Blades of Godric, being understaffed is not an argument. The WMF is greatly over funded. All they need to do is augment their capacity and reduce some of the deadwood. Do you know which department is developing this, and more importantly, who is in charge of it?Kudpung กุดผึ้ง (talk) 02:50, 14 September 2019 (UTC)[reply]
Kudpung, it's the Scoring Platform Team.
I have known this via off-wiki sources for quite some time but now see T217232 which states :- Scoring Platform Team is very understaffed with no dedicated product support. FWIW, since then, the team has got reduced even more and Halfaker has been mentioning of the need of a bigger budget, of late.
On the broader locus, I have had highly interesting discussions between Danny, IFried, James and me, as to funding CommTech and other departments. Will note them, somewhere .... ∯WBGconverse 03:31, 14 September 2019 (UTC)[reply]
Winged Blades of Godric, will you ping me when you do? I'd love to read about it. Best, Barkeep49 (talk) 03:40, 14 September 2019 (UTC)[reply]
The way the funds our unpaid work generates are used is a bubble about to burst. The WMF is under fire on several fronts right now. Stay tuned. Kudpung กุดผึ้ง (talk) 03:42, 14 September 2019 (UTC)[reply]
Barkeep49, I will try to pen them down, when I get some time. Will ping you:-) ∯WBGconverse 04:04, 14 September 2019 (UTC)[reply]

Send message to all article creators thanking them - differing based on article state

This has been copied over from Kudpung's writing here:

have been expecting something on the lines of:

Tagging, but leaving unreviewed: Thank you for creating xxxxxx. A reviewer has tagged the article as needing your attention before it can be accepted for indexing by search engines."
Tagging, but passing as patrolled: The standard message, with the message details completed by the reviewer.
A further idea: For all new articles passed as patrolled, a thank you template with a few (really just a few) links to help pages, the Teahouse, and 'Your first article'. Most of the new articles are created by new users and this would also help demonstrate that there are a humans behind Wikipedia.

Suggested responses:
1. New template: "Thank you for creating xxxxxx. A reviewer has tagged the article as needing your attention before it can be accepted for indexing by search engines.""
2. Template:Reviewednote-NPF
3. A new template that should automatically be sent when an article is passed as patrolled without further comment.

Page info and dab pages

Tracked in Phabricator
Task T76198

At present, on disambiguation (dab) pages the "Page info" symbol, , is covered by a little white "1" on a red square background, and the "Possible issues" section comments: "No citations - This page does not cite any sources." Since reference citations are not allowed on dab pages, it seems that there should be a way to sense the dab page and not specify a need for the citations. P.I. Ellsworth  ed. put'r there 03:44, 23 December 2020 (UTC)[reply]

There are examples of this at the Chicago Storm – Bringing It Back – Kill Devil Hill – J Street (disambiguation) (dab) – Formal semantics (disambiguation) (redirect) and Lil Bit (disambiguation) (dab) pages. P.I. Ellsworth  ed. put'r there 03:48, 23 December 2020 (UTC)[reply]

After checking several dab pages, I see that the bar on the right side that holds the various icons sometimes no longer appears. So the solution was to remove that sidebar from the dab pages? P.I. Ellsworth  ed. put'r there 04:41, 29 January 2021 (UTC) 13:08, 12 February 2021 (UTC)[reply]

Refine filtering of AfC drafts

Tracked in Phabricator
Task T342073

I propose that in the New Pages Feed, AfC drafts will also be able to be filtered by having no citations, having been previously deleted, created by new users, created by blocked users, etc., as opposed to just filtering them based on potential issues and ORES-given ratings. JJP...MASTER![talk to] JJP... master? 22:30, 22 March 2021 (UTC)[reply]

Expanded info on previous deletions

Tracked in Phabricator
Task T313650

My main use of the New Pages Feed involves filtering for Were previously deleted. At the moment these are highlighted in red as Previously deleted. Nowadays, however, a high proportion have been cycled from mainspace to Draft then back to mainspace (ideally with AfC eyes in between, but often not), which triggers this filter. It would be helpful if the Previously deleted text could be expanded to identify particular circumstances, for example:

1. Showing Previously deleted (previous AfD) for article XY if one or more Wikipedia:Articles_for_deletion/XY pages exist, helping identify potential reposts.
2. Showing Previously deleted (draft exists) for article XY if a Draft: XY page exists, often indicative of a copy-paste to mainspace.

Both of these would involve just file-exists tests based on the article title. A more ambitious option 3 would involve appending an icon alongside all Previously deleted texts, to allow the user to click through to a new tab showing Special:Log?page=XY so that the actual history of prior instances can be viewed.

Each or all of these changes could I think increase the effective scrutiny of articles recurring into mainspace. AllyD (talk) 08:50, 18 November 2021 (UTC)[reply]

New Page feed filtered article count doesn't include PRODs and CSDs which are left unreviewed

@MPGuy2824 and Novem Linguae:. With the recent patch, the number in the footer now closely matches the number of unreviewed articles in the queue. Right now, I see the footer says 7 and the feed says 5. That is a minor difference due to the caching issue. No big deal. But the queue actually contains 48 unreviewed articles right now - there are another 43 with Prod tags. So the count in the footer doesn't actually match the review status (green check or not); it is actually the number of unreviewed articles that are not currently nominated for deletion. Do we want to "fix" that to make it technically accurate? On the other hand, there is nothing to do with those articles. Which number is picked up in {{NPP backlog}} and the report/graph? Which number to we want to "publicize" as the queue size? — Preceding unsigned comment added by MB (talk • contribs) 14:26, 20 October 2022 (UTC)[reply]

  1. Consistency: NewPageFeed footer and {{NPP backlog}} both get their info from the PageTriage's stats API. The backlog chart's source isn't very obvious, but the numbers are different (See [2] (41) v/s [3] (68)).
  2. What number to publicize as queue size?: Your point that reviewers don't need to do anything more with PROD-ed articles is right. I'd say the current number in the footer is the one that we should show everywhere.
  3. "Fixing it to make it technically accurate": I assume that you mean some text changes to the footer stats. Sure makes sense. "XXXX articles and YYYY redirects are waiting to be reviewed", maybe? I'm sure you guys will think of something better. BTW, PROD-ed articles aren't shown as unreviewed (blue exclamation) but as nominated for deletion (black trash can), so there may not be any need to change the text at all.
If we decide that the numbers shown by the graph need to change, we'll have to talk to MusikAnimal, the bot's operator. -MPGuy2824 (talk)
What I meant by technically accurate is that that there are only two reviewed statuses - reviewed and unreviewed. The black trash can means nominated for deletion, that is independent of review status. If there is no green checkmark, it is unreviewed. The number in the footer that is labeled unreviewed articles is actually the number of unreviewed articles that are not currently nominated for deletion, but not quite the total of unreviewed articles. Right now, with the numbers so low, there are twice as many unreviewed articles as reported in the footer - there are around fifty prod/csds. Its sort of like having two different definitions of unreviewed. MB 05:27, 21 October 2022 (UTC)[reply]

Hide "were created by newcomers" from filter list

Since ACPERM was rolled out, 'Were created by newcomers (non-autoconfirmed users)' can be removed, because they no longer can anyway. Kudpung กุดผึ้ง (talk) 21:41, 7 July 2022 (UTC)[reply]

Support: I'd guess that those appearing when the filter is set currently are all AfC accepts. -MPGuy2824 (talk) 05:49, 1 September 2022 (UTC)[reply]
I'm hesitant to remove filters from the menu. In this particular case, there is a range of filters, and I am concerned that removing one will make the range incomplete. Also, articles do sometimes show up in this range, for example, accepted AFC drafts. –Novem Linguae (talk) 13:27, 22 September 2022 (UTC)[reply]

Hide "predicted class" and "potential issues" from filter list

Development mockup

Display 'Predicted class' and 'Potential issues' in the feed list by default and remove these options from the panel to reduce clutter and banner blindness.

Kudpung กุดผึ้ง (talk) 21:41, 7 July 2022 (UTC)[reply]

Is phab:T195545 the correct task? Doesn't seem related. I fully support adding an autopatrolled articles filter. I'm a bit more hesitant on removing features, especially the "potential issues" filters as I use those to look for low hanging fruit sometimes. I will also note that the filter "Were created by newcomers (non-autoconfirmed users)" has dozens of articles, mostly accepted AFC submissions that need NPP review. –Novem Linguae (talk) 07:16, 8 July 2022 (UTC)[reply]
Novem Linguae, T41547 was first requested at Phab in 2012 by a staffer who often started and promised features for NPP and then conveniently forgot them. T195545 also concerns the panel. It was the 2018 refurb that included the feed and filters for AfC; I included it here but as they seem to have completed it, it might no longer be relevant. You may be right about the non-autoconfirmed users, but even if they were created through AfC, they would probably have reached the 4 days/10 dits by the time the article hits the New Pages Feed. My suggestion for 'Predicted class' and 'Potential issues' was to include them permanently and remove the options from the panel to reduce clutter and banner blindness. Kudpung กุดผึ้ง (talk) 12:06, 8 July 2022 (UTC)[reply]
Just a note that $wgPageTriageEnableOresFilters in IntializeSettings.php is what controls whether or not "predicted class" and "potential issues" are displayed. –Novem Linguae (talk) 05:59, 9 July 2022 (UTC)[reply]
I don't think there's much point in us discussing code here - or even at Phab for that matter. The WMF is awash with funds and as Page Triage is a WMF project, they should be addressing the bugs and the feature requests. The New Page Reviewers have got enough to do without exploring or rewriting the MediaWiki code for those who are being paid for it. In case anyone has still not understood what is being asked for, its to remove the checkboxes for the "predicted class" and "potential issues", and have that information displayed in the feed entries by default. The effort is to make Curation as simple and effective as possible and hence an attractive job for the reviewers. Kudpung กุดผึ้ง (talk) 07:05, 9 July 2022 (UTC)[reply]

Novem Linguae, coming back to

  • Display 'Predicted class' and 'Potential issues' in the feed list by default and remove these options from the panel to reduce clutter and banner blindness.

I am reminded of something Kaldari (former WMF Head of Engineering) said a few years ago with a link to an external article: An abundance of user preferences, however, can lead to decision fatigue. So it's important to only provide preferences that will actually be used.[4] It is indeed something I was taught at uni in Berlin 36 years ago on a lecture called Qual der Wahl. I think we should open a ticket on this or perhaps you can write a patch yourself. Kudpung กุดผึ้ง (talk) 11:15, 17 July 2022 (UTC)[reply]

"Were created by filter" enhancement

Tracked in Phabricator
Task T313647

After reviewing one article/redirect, I often want to see others created by the same user. In the filters, there is the choice to specify a username. It is a bit arduous to copy/paste the username into this field. I would like another option (probably to the right of the user name box) that if checked, will fill in the field with the username from my last patrol. Comments? MB 04:19, 11 July 2022 (UTC)[reply]

Decent idea. Could do this by setting and reading a cookie (easy). Maybe have the link be the name of the last person... that keeps it short and makes it clear who is being selected. –Novem Linguae (talk) 14:06, 11 July 2022 (UTC)[reply]

More specific edit summaries for AfD nominations

Tracked in Phabricator
Task T44650

It would be good if the edit summaries for articles when adding an AfD tag could mimic Twinkle and read "Afd: Nominated for deletion; see Wikipedia:Articles for deletion/NominationName" - ditto RfD, MfD, etc.

Curation panel: Send message to creator/Talk page

Tracked in Phabricator
Task T313645
Panel before and after

Make it optional to post the message to the talk page. Some messages are appropriate for the creator only. I'm not as prolific nowadays as many reviewers, but I do find very often that I don't want the message posted to the talk page especially when I'm offering advice to a new user which I do quite often. If posting the message to the talk age is opional, perhaps more reviewers would leave a message of advice or encouragement for the creator. Kudpung กุดผึ้ง (talk) 02:57, 23 July 2022 (UTC)[reply]

Page Curation tag ordering

Tracked in Phabricator
Task T314430

This edit shows a tag added before the {{short description}}, which is out of order per WP:ORDER. This is really minor and makes no real difference, but would be moved by AWB, so better to put in the right place to begin with. MB 15:33, 2 August 2022 (UTC)[reply]

Request to auto-create TP and TP banner

Tracked in Phabricator
Task T315930

I'm not sure at what point this would occur but I'm of the mind that once an article is added to the NPP queue, a TP should automatically be created with header and relevant WikiProjects listed in the banner, if it doesn't already have one. By doing so, some of the project teams can help with article clean-up instead of leaving that chore for NPP. Atsme 💬 📧 20:10, 22 August 2022 (UTC)[reply]

The AFC helper script lets the AFC reviewer pick WikiProjects when accepting, and then generates a talk page with the correct banners. We could model it off of that. Keep in mind that adding WikiProject banners is now optional for NPPs as of about 6 months ago when we changed the flowchart, with the goal of faster reviewing. But this would still be nice to have. I'll make a ticket on phab. phab:T315930. Thanks for the idea. –Novem Linguae (talk) 20:48, 22 August 2022 (UTC)[reply]
Wonderful news, Novem L., thank you!! Atsme 💬 📧 21:14, 22 August 2022 (UTC)[reply]
I use Rater which does the same. It even makes a reasonable guess of the class. Yet another script that is not integrated into the NPP toolset. MB 21:21, 22 August 2022 (UTC)[reply]
@Atsme, Novem Linguae, and MB:, The lack of project banners, especially the BLP template, is one of the most infuriating things about the creation of new articles by lazy editors, but possibly understandable by newbies who might not even know what a Wikproject is. I always add them when I patrol, but unless I am a member of that project I leave the rating up to the Wikiproject people. Kudpung กุดผึ้ง (talk) 02:00, 26 August 2022 (UTC)[reply]
I don't think adding WikiProject choices to the Page Curation toolbar is too valuable for this use case. Rater works well, and a new and different implementation within Page Curation will probably have its own bugs or lack of features. I'm not opposed to the feature if others really consider that integrating in Page Curation is valuable compared to using Rater separately, but I think we could explore some other options here.
I wonder if we can make articles in the NPP queue prioritized in some other backlogs, like something advertised in the Wikipedia:Task Center. I think there's a few people doing this kind of gnoming: can we steer them towards the NPP queue, rather than random pages? MarioGom (talk) 07:22, 26 August 2022 (UTC)[reply]
The quicker we get all the time consuming menial tasks automated, the better. An article TP with project banners should be created at the point of article creation in main space (by auto-patrolled editors) or when moved from draft to main space. If auto-patrolled editors are not creating TPs when they create articles, then perhaps revocation of the right will encourage them? Atsme 💬 📧 15:34, 26 August 2022 (UTC)[reply]
Just a quick note that all the bottom/gnomish parts of the flowchart, including adding maintenance tags, adding categories, adding stub tags, and creating talk pages, are optional now for NPPs. If NPPs don't have to add talk pages, not sure it'd be fair to require that of autopatrollers. –Novem Linguae (talk) 22:41, 26 August 2022 (UTC)[reply]
I agree, but my reference was to editors who create articles in their own user space or in main space, have autopatrolled rights, but don't bother to create a TP for their newly created articles which are automatically marked as reviewed. Those articles tend to escape detection in the NPP feed. At AfC, reviewers can make sure the authors create a TP w/WikiProject banners, but we're less likely to catch it for autopatrolled article creators. Atsme 💬 📧 01:03, 27 August 2022 (UTC)[reply]

...not sure it'd be fair to require that of autopatrollers, I beg to differ, NL. Like Atsme I've always been convinced that the talk page shoud be processed at the point of creation. While there's an excuse for newbies, an autopatroller is generally expected to produce 100% complete articles (except for eventual future expansion). At least that's what I do and I'm rather proud of it. Or am I wasting my time making clean articles? Not that anyone bothers to read them so it's not even leading by example - unless I link to them when I'm teaching others. Having a tool for NPPers to do it would be handy, but I don't think it's high on the priorities until at least the PageTriage codebase has been rewritten. Kudpung กุดผึ้ง (talk) 03:57, 27 August 2022 (UTC)[reply]

If we had a report that is the reverse of Wikipedia:Database reports/Orphaned talk pages, then I'm sure some gnome group would attack it with vigour. -MPGuy2824 (talk) 04:04, 27 August 2022 (UTC)[reply]
We have ways to fix it that are time consuming – what we need more is prevention. It's a time sink, and should not require human gnomes if it can be automated. Keeping up with the technology and providing what volunteers need is far more efficient than depending on volunteers to fill the need. Atsme 💬 📧 11:40, 27 August 2022 (UTC)[reply]

Page feed deletion filtering

Tracked in Phabricator
Task T316301

Since AFDed articles can be marked as reviewed with just a quick check that there is a valid deletion discussion, it would be handy to find easily find these. The page feed has the option "Nominated for deletion", but that includes CSD & PROD. I just went through all those and found around 60, and about 2/3s were AFD meaning I had to skip through 20 others. It would be more convenient to be able to filter on just AFDs (don't see a reason to need only CSD or only PROD). MB 20:02, 25 August 2022 (UTC)[reply]

Workaround: Here's an old quarry query of mine I use to find these. Fork and re-run the query to update its data. –Novem Linguae (talk) 23:49, 25 August 2022 (UTC)[reply]
@Tamzin: your 'zinbot does this reviewing for redirects. Can it be used for articles with valid AfDs, as well? -MPGuy2824 (talk) 01:26, 26 August 2022 (UTC)[reply]
Not sure if these should be auto approved. What if a new user files an AFD, but misses a copyright violation (doesn't run Earwig on it), or misses a CSD G10 attack page? These may require human review. Much less steps than the whole flowchart, but at least the CSD part at the beginning, I think. –Novem Linguae (talk) 02:05, 26 August 2022 (UTC)[reply]

Display 'Autopatrolled' articles in the feed by default.

Autopatrolled - mockup

Autopatrolled articles are becoming increasingly problematic - either that or we are getting a bit better at serendipitously finding them. Alreadty the Autopatrolled righ has been removed from the Admin privileges.

Keep 'from Autopatrolled' in the filter options but:

  • Display all articles by autopatrolled users in the feed by default.
  • Display an alert 'Autopatrolled' in red.
  • Display the other usual alerts.

This would inform the reviewers of any issues and leave them to take a closer look at their discretion. Kudpung กุดผึ้ง (talk) 02:50, 14 September 2022 (UTC)[reply]

The purple colored check marks are a feature I added with the autopatrol filter patch. Autopatrolled articles have a purple check mark, and marked as reviewed articles have a green check mark. So we may not need to display "Autopatrolled" in red text, since we can just look for a purple check mark.
Is there consensus for "Display all articles by autopatrolled users in the feed by default"? If other users are in favor I will create a ticket. I pause for consensus. –Novem Linguae (talk) 06:52, 14 September 2022 (UTC)[reply]
NL, I think you missed the point entirely. Some patrollers are considering even more radical solutions such as for example, doing a systematic sweep of all Autopatrolled users' articles to see if anyone is breaking the rules. Now that would need a consensus, just like an extraordinary CU search would. There's no need to seek consensus however for every minor enhancement to the tools. If that were the case, I would never have got them developed in the first place, or again in 2018 when we added ORES, or a tool that flags up COPVIOs. Kudpung กุดผึ้ง (talk) 08:03, 14 September 2022 (UTC)[reply]
Kudpung, with your changes, the default-setting feed would show 14,000 articles right now, instead of 9,500. I wouldn't call it a minor change. -MPGuy2824 (talk) 08:16, 14 September 2022 (UTC)[reply]
MPGuy2824 you're confusing the feed content with the backlog The autopatrolled articles are not part of a backlog - they have already been Autopatrolled! Kudpung กุดผึ้ง (talk) 09:50, 14 September 2022 (UTC)[reply]
On these tickets where I am asking for consensus, it is because I have reservations, so I'd prefer to get some additional opinions to help make a more informed decision. –Novem Linguae (talk) 08:47, 14 September 2022 (UTC)[reply]
Do you at least understand the rationale behind my suggestion? Maybe I have not described it adequately. I did add an image. I don't see anything in the slightest contentious about this feature that it requires the new trend in needing a major RfC for every minor tweak on the website. In fact it's such a no brainer I can't understand why I didn't think of it way back in 2012 when it would have been included along with all the other original features without a debate. Kudpung กุดผึ้ง (talk) 09:57, 14 September 2022 (UTC)[reply]
Just to clarify, this requires more than changing defaults of currently available filter options. If you select "Were created by autopatrolled users", the feed shows nothing because they are still filtered out by state: "Unreviewed pages". You have to add state: "Reviewed pages", but then you have all reviewed pages in the feed. I think you want the default to be all unreviewed pages + autopatrolled-reviewed, which is a combination you can't get today. I think that complicates the current filter setting, probably requiring a third option for "state:"
I'm not sure who would use this. I am a task-oriented person and tend to do one thing at a time - just review redirects, just review articles. If I wanted to check some AP articles, I would look at just those (which you can see today). Wouldn't having 5k more articles in the feed just get in the way of people trying to review articles and reduce the backlog? If the majority of people would turn off the AP articles so they could get on with their reviewing, it really shouldn't be the default. I'd like to hear more people say they would want APs in by default. MB 04:02, 15 September 2022 (UTC)[reply]
I'm not concerned with the pure technology of it. 'Default' means 'default' and that doesn't mean it can't be turned off. My point in having this feature is that reviewers could ignore the autopatrolled articles displayed in the feed and move on unless ORES has flagged up an issue, and that's what it's all about; at least they would notice when one has some issues. I don't believe there are many reviewers who bother to select the autopatrolled articles in the filter (which incidentally doesn't seem to work at the moment). I check them out and my empirical findings tell me it's time it were done more often, and hence my suggestion to make it somewhat easier and more encouraging for reviewers to do so. Of course, we could go the whole hog and hold a debate for having the Autopatrolled right deprecated entirely, but it would be voted down because like NPP most of them regard it as a medal of merit - which it absolutely is not. Kudpung กุดผึ้ง (talk) 12:51, 15 September 2022 (UTC)[reply]
which incidentally doesn't seem to work at the moment. Did you try ticking the check box for "State: Reviewed"? That needs to be paired with the autopatrolled filter for it to display results. Hope that helps. –Novem Linguae (talk) 13:54, 15 September 2022 (UTC)[reply]
That must have slipped my mind, in which case, perhaps adding 'check check box for Reviewed' to that radio button's description would help users who are even less NPP savvy than me ;) Kudpung กุดผึ้ง (talk) 23:52, 15 September 2022 (UTC)[reply]

OK. So that works now, but still needs my suggested red alert in the feed, otherwise there's no point in having the radio button 'Were created by autopatrolled users' at all. As this only affects the work of reviewers and is only visible to them, a site-wide or any other RfC is superfluous. As I said earlier, we don't need consensus for every minor improvement to the GUI of a specialised tool. Believe me, if I knew how to do it I would boldly do it myself as I have many other things in the past (and recently) on templates and tools. We can refine the selection options further, and how they are displayed in the filter panel, but at least let's discuss it rather than ruling it out - I'm not one for making usage suggestions just for the sake of it.

We're all agreed that to save NPP we need to start thinking outside the box, and streamlining the work is part of making NPP sexy enough for editors to want to do it. That said, I'm not ignoring the fact that a lot of articles and redirects are created by autopatrollers and it is a help not to have to review them (generally), but we are well aware that it is abused and even by admins - that's why it was removed recently from the admin toolset. Kudpung กุดผึ้ง (talk) 00:30, 16 September 2022 (UTC)[reply]

I'm totally on board with putting autopatrolled articles in the feed, so we can more easily spot check them, but why make that the default? Surely patrolling already patrolled articles is a niche and occasional task, not something the average NPPer is doing on a day to day basis?
Also, when will they be removed from the feed? Do they have to be re-reviewed? Or just after a certain time has elapsed? – Joe (talk) 07:46, 16 September 2022 (UTC)[reply]
@User:Joe Roe, you can see AP articles now. Go to filters and select "were created by autopatrolled users" AND select "reviewed articles". Like other reviewed articles, they are in the queue for 90 days. This is existing functionality and supports spot-checking by anyone inclined to do so. That is not exactly the intent of this request though. MB 14:10, 16 September 2022 (UTC)[reply]

Automatically flag articles that have been overwritten as 'unreviewed'

Tracked in Phabricator
Task T207446

@MB, Novem Linguae, and MPGuy2824:. Proposed here. --Kudpung

When all or a very large proportion of an article's content is overwritten with new material, the article should be marked as unpatrolled and added to the NPR queue. This is virtually creation of a new article, but can be done by IPs and new accounts, and is often a sign of conflict-of-interest editing: Noyster (talk), 11:03, 16 January 2018 (UTC)[reply]

That is a very good idea, Noyster. What number of bytes do you think should trigger the alarm? Join the development discussion n the talk page of Wikipedia:WikiProject Articles for creation/AfC Process Improvement May 2018 before it's too late. Kudpung กุดผึ้ง (talk) 11:03, 18 May 2018 (UTC)[reply]
It certainly looks as if T36912 would provide the means to detect these edits. That task has been sitting since 2012 with low priority and no-one assigned. Could it be boosted up the priority scale, or do we have to wait to put it on our Santa Claus wishlist coming up to next Christmas?: Noyster (talk), |TB| 5:04 pm, 22 January 2018 (UTC+7)

Automatically notify creator when article has been marked as reviewed

  • There was a request to send a message to every creator on 'Mark as reviewed':

Thank you for creating xxxxxx. Your article has been passed by a New Page Reviewer. If you have any questions don't hesitate to ask at the Teahouse

This lets the creator know that s/he is not an island, and it serves to let them know that their work has been noticed. Just one of those nice little things that no one has ever thought of. Kudpung กุดผึ้ง (talk) 12:11, 18 October 2022 (UTC)[reply]

  • I like your last suggestion, but the creator already receives a notification about their article that has just been reviewed. If there is more support for this, i'll create the phab ticket. -MPGuy2824 (talk) 05:43, 19 October 2022 (UTC)[reply]
MPGuy2824, Page Curation does not inform the creator that their article has been successfulky reviewed. I have mentioned this many times over the years and to me it seems logical as a friendly gesture to the creator. To me it's a no brainer. It's so obvious, it does not need an RfC. Kudpung กุดผึ้ง (talk) 09:31, 19 October 2022 (UTC)[reply]
The notification shown when a creator's page is reviewed
Kudpung, i should have been clearer. There is no automatic talk page message added when a creator's page is reviewed, but they do get an echo notification. See screenshot attached. -MPGuy2824 (talk) 10:00, 19 October 2022 (UTC)[reply]
MPGuy2824, I never knew abut that notification, but I'm autopatrolled and have been for over 12 years; it's not quite the same kind of thing though, ist it? It looks obviously software generated. My thoughts were to make page creators more welcome and let them know that a human is behind their work. It would be nice. Wikipedia is always yelling about being nice to the extent of tripping over themselves. But never mind if it's too much bother. I'll probably start a famous site-wide RfC for for such a small feature and see what interest it generates, it will get a consensus but it would be much ado about nothing. Kudpung กุดผึ้ง (talk) 11:08, 19 October 2022 (UTC)[reply]
MPGuy2824, This suggestion of mine was suggested entirely independently and without knowledge of this by Sageross of the WMF during our video conference with the Director of Product. Kudpung กุดผึ้ง (talk) 10:25, 5 November 2022 (UTC)[reply]

Info in Page Curation for other reviewers

Tracked in Phabricator
Task T40054

I'm fairly certain this used to exist, but maybe it's wishful thinking. There are plenty of cases where a reviewer might message the creator without wanting to mark the page as reviewed. For example, by the time the next reviewer arrives, the creator may have addressed the issue. In any case, it will warn the reviewer that the creator has already been messaged.
See the example of the added alert in red.

This request has some overlap with an older ticket. I've changed the ticket details to encompass this scenario too. -MPGuy2824 (talk) 09:53, 26 October 2022 (UTC)[reply]

As an extension to this feature - but on the 'Mark as reviewed' pane, apparently creators get a notification when their article has been reviewed, but are they automatically informed if a successful review is also accompanied by some tags on the article? The tags might not be a deal breaker for a review, but they are there because they nevertheless need to be addressed. Kudpung กุดผึ้ง (talk) 09:59, 23 October 2022 (UTC)[reply]

The notification shown when a creator's page is tagged with maintenance tags
When an article is tagged from the "tags" pane, a notification is shown to the creator. This is also an echo notification and not a talk page message. -MPGuy2824 (talk) 09:44, 26 October 2022 (UTC)[reply]
MPGuy2824, I'm not so sure that the creators we have to deal with even know what notifications are. The yellow banner for notifying of talk page messages is one thing (it was reduced in size a few yeas ago) but the little bell and the computer icons are really too small to be of any use. I propose that they should be RED and BLINK when there are notifications to be read. This is not a NPP specific suggestion, but it would NOT need a RfC. Kudpung กุดผึ้ง (talk) 11:49, 29 October 2022 (UTC)[reply]
That would need a phab ticket for mw:Extension:Echo. I think it would need a discussion and consensus somewhere. Anything that visually affects every logged in editor would need consensus so that there isn't a major backlash when it is implemented and disliked. –Novem Linguae (talk) 17:24, 29 October 2022 (UTC)[reply]

Tagging via toolbar: Replace the options in the 'common' section with the ones that are actually used most often

According to this quarry, the top-10 most commonly used tags are (in descending order): notability, stub, refimprove, one source, orphan, linkrot, unreferenced, uncategorized, copy edit and primary sources.

The 'common' section of the toolbar has the following tags: under review, linkrot, copy edit, more footnotes, refimprove, unreferenced, stub, uncategorized and orphan.

I'm not sure about 'under review', but we should remove "more footnotes" and add "notability (General)", "one source" and "primary sources" to the common section of the toolbar. -MPGuy2824 (talk) 04:28, 29 November 2022 (UTC)[reply]

Support. It's hard to argue with empirical data. Feel free to make an edit request at MediaWiki:PageTriageExternalTagsOptions.js. –Novem Linguae (talk) 05:16, 29 November 2022 (UTC)[reply]
Maybe "under review" could warrant a discussion. It has been used only 17 times in 2 months. -MPGuy2824 (talk) 05:17, 29 November 2022 (UTC)[reply]
Support - also agree that the "Under review" could be removed. Onel5969 TT me 17:14, 1 December 2022 (UTC)[reply]
Tracked in Phabricator
Task T347539
Resolved

Note: This discussion is now moot, since the common tags have been removed. -MPGuy2824 (talk) 07:20, 3 December 2023 (UTC)[reply]

The common tag section is going to be re-added. -MPGuy2824 (talk) 04:33, 15 December 2023 (UTC)[reply]

Don't mark pages deleted under any R criteria or certain G criteria as previously deleted

Tracked in Phabricator
Task T353477

As I've patrolled the New Pages Feed, I noticed that most of the time if a page is marked as having previously been deleted, it was deleted under one of the redirect criteria, an RfD (and the new page is not a redirect), or G7. I think that the New Pages Feed should ignore these deletions and not mark that the page was previously deleted if it were under these criteria (unless its a redirect and it was deleted under an RfD or R crtieria), as often these deletion have no merit on whether or not the page should remain. As an example, Kenangan Masa is marked as previously deleted because it was a page that was moved to draftspace and the redirect was deleted under R2. The deletion has no merits on the actual article itself since it was unrelated to the article content. ― Blaze WolfTalkBlaze Wolf#6545 13:53, 10 May 2023 (UTC)[reply]

Track PROD, XfD, and CSD like Twinkle does?

Tracked in Phabricator
Task T207237

Is there a preferences panel to allow the Page Curation toolbar to track PROD, XfD, and CSD like Twinkle does, and like MoveToDraft allows? Am I missing this somewhere? If not, can it be added? microbiologyMarcus (petri dish•growths) 21:24, 29 November 2023 (UTC)[reply]

I have a collection of my logs in my userspace at User:MicrobiologyMarcus/logs for anyone not familiar. microbiologyMarcus (petri dish•growths) 21:25, 29 November 2023 (UTC)[reply]
It's a good idea. Just need a dev to code it up. The ticket for it has been open since 2018. –Novem Linguae (talk) 01:53, 30 November 2023 (UTC)[reply]
@Novem Linguae User:Sohom Datta has made a script at User:Sohom Datta/PageTriageUserspaceLogger. Can this be integrated? ~/Bunnypranav:<ping> 07:45, 26 December 2024 (UTC)[reply]

Filter for # of languages linked to article

As someone who does a fair amount of reviewing in moments of small amounts of time, I would love to filter for articles with a certain number of articles in other languages (i.e. 2-3 other languages) or specific other languages (like only articles with languages I read). This would allow me to quickly clear some of the articles that are translations or were identified by experienced editors from other wikis, Sadads (talk) 20:15, 2 September 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Page_Curation/Suggested_improvements&oldid=1265308289"