Wikipedia:Page Curation/Suggested improvements/Archive 2
This is an archive of past discussions on Wikipedia:Page Curation. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page. |
Archive 1 | Archive 2 |
51. Allow users to override infinite scrolling of the feed
The infinite scrolling interface is annoying and unproductive. Even to go back a few days in the queue requires way too much user input. To get to the vast middle of the queue is onerous. There should be an option to load everything in the queue (at least for pages created by new users), or to load pages similar to how it is done in Special:RecentChanges.- MrX 15:39, 15 June 2017 (UTC)
- See Wikipedia:Page_Curation/Suggested_improvements#15._Jumpback above. Tracked at the right Phab Task. — Insertcleverphrasehere (or here) 08:13, 19 October 2018 (UTC)
52. Allow patroller to send message to editor without tagging or un-reviewing/re-reviewing
Done
|
---|
I often add tags to an article I've come across, perhaps while stub-sorting, using Twinkle as usual, and then realise that it's awaiting NPP. I might want to send a message to the creator ... but I can't do so without adding another tag. I've been known to add a duplicate tag, send the message using the Curation toolbar, then edit again to remove duplicate. PamD 17:45, 15 June 2017 (UTC)
|
53. Allow filtering by no citations
done
|
---|
Adding a filter to the new pages feed to allow patrollers to see which pages are marked by the software as having no citations would be helpful. I have created this task in phab. TonyBallioni (talk) 17:27, 28 June 2017 (UTC) Support This would be a useful way to prioritise our patrolling. Boleyn (talk) 05:36, 14 July 2017 (UTC)
|
54. Send feedback to talk page
While working on reviewing "older" new pages, I sometimes notice that I'm sending feedback to someone who created a redirect that has been turned into an article by someone else. I think I've asked for a feature to select the recipient, but I now think that such a feature clutters the UI and makes things more complicated. It occurred to me that it would be better to post the feedback to the talk page and leave a notification for the creator/main contributor instead. That way, the tags have a context that is more easily accessible to other contributors. Is there support for such a change? Mduvekot (talk) 12:04, 1 July 2017 (UTC)
- Definitely would like to be able to automatically record comments (eg: Noting that a page appears to pass an SNG), without necessarily needing for it to notify the page creator. The way to do it might be to have a field for user to notify, and automatically populate it with page creator. That could be replaced with one or more users (separated by commas?), or left blank for article talkpage comment but no notification. ~Hydronium~Hydroxide~(Talk)~ 08:12, 2 July 2017 (UTC)
- I completely support the idea of leaving feedback on an article's talk page. But obviously only when it's useful to other editors to improve that article. Unaware of this thread, I today suggested a similar idea on this page. In essence, I propose an option to "Add copy of comments to article's talk page". It would probably need some covering text, such as:
- A New Page Reviewer has left feedback for the creator of this article. The following extract may also be of relevance to other editors in improving this page: (insert text and autosignature).
- It would be good to hear what support other reviewers would give for such a function. Nick Moyes (talk) 16:56, 14 July 2017 (UTC)
- I completely support the idea of leaving feedback on an article's talk page. But obviously only when it's useful to other editors to improve that article. Unaware of this thread, I today suggested a similar idea on this page. In essence, I propose an option to "Add copy of comments to article's talk page". It would probably need some covering text, such as:
- Support This would allow others who come to the article to see the reviewer's comments, this can only be an improvement. — Insertcleverphrasehere (or here) 04:12, 4 September 2018 (UTC)
- One of the flaws of the curation tool is that is sends the notes from the reviewer to the creator of the article. It should go to the talk page of the article instead. I've gotten my share of "what were you thinking?" responses from experienced editors who created a redirect that was overwitten by a new editor. I learned to always check the history of a page I'm reviewing. Vexations (talk) 01:47, 17 September 2018 (UTC) (comment copied from the discussion board by — Insertcleverphrasehere (or here))
- Vexations, I totally agree about the notifications to the article creator when it should go to the article TP. It even notifies banned/blocked users. I'm pinging MMiller (WMF) hoping maybe he can either fix it or make a suggestion so we can. Atsme✍🏻📧 02:11, 17 September 2018 (UTC) (comment copied from the discussion board by — Insertcleverphrasehere (or here))
- Requested on Phab. — Insertcleverphrasehere (or here) 08:31, 19 October 2018 (UTC)
57. List of previous creators of an article
Page creation log is now live at: special:log/create. — usernamekiran(talk) 19:38, 30 June 2018 (UTC)
|
---|
Adding such a feature to new pages feed would be complicated. But if only new page reviewers (and nobody else except sysops) could see it in page history, the proposed feature may become reality. —usernamekiran(talk) 00:15, 9 September 2017 (UTC)
|
58. Add the Sources exist Tag
Done
|
---|
Can we please add the {{sources exist}} tag to the page curation toolbar? This tag would be immensely useful in reducing duplicate work required and would be an easy way of notifying other editors "yes I did a search and I found a bunch of stuff". It would also make it so that NPP reviewers could mark articles as reviewed and AfC reviewers could 'accept' drafts that might not "demonstrate" notability, but were clearly notable when the reviewer did a search (i.e. they could add the tag indicating why they accepted it). All in all just a useful variant of the {{more references}} tag. — Insertcleverphrasehere (or here) 06:31, 22 December 2017 (UTC)
|
59. Wikidata
Not a priority - out of scope for NPR
|
---|
It'd be useful for Special:NewPagesFeed to indicate whether an article is linked to a wikidata item, and where so, to provide the Qid as a link. The indication / link would enable action to be taken to create a link or a wikidata item, and facilitate an inspection of a linked item, from the feed page. Not least, a number of en.wikipedia project have a dependency on good linkage to wikidata - e.g. Women in Red. --Tagishsimon (talk) 22:43, 11 January 2018 (UTC)
[[:d:{{BASEPAGENAMEE}}]]
...Or there's Yair rand's tool (available as a gadget on meta) which may satisfy your needs. Cabayi (talk) 10:44, 30 October 2018 (UTC) |
60. Add information link to 'Notices' message sent to article creator
Closed at Phab. Templates are locally configurable
|
---|
Hi, I received a message on my 'Notices' icon containing 'The page <article name> has been reviewed', a link to the article I had created (which appeared unchanged), a link to the user that performed the review, but nothing to explain the review's outcome or what a review entails. I believe adding the same Learn more link that exists on the New pages feed to the notification text would be beneficial, especially as a new editor such as myself, or if possible a direct link to the details/outcome of the review? – Paul · ✉ 13:12, 12 January 2018 (UTC)
|
61. Articles to go back into NPR queue when overwritten
Proposed here. 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)
- 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)
- See Wikipedia:Village_pump_(technical)/Archive_162#Flagging_overwriting_of_articles for more technical details. — Insertcleverphrasehere (or here) 08:41, 19 October 2018 (UTC)
62. "on behalf of"
Done
|
---|
I recently unreviewed a page (unintentionally), which triggered this note to be posted to Jbhunley's talk page. The note itself is no problem and seems like a good idea, however, it is signed by me as though I personally wrote it and the edit history shows the same, in contrast - for instance - to other auto-generated notices which will often carry the disclaimer, for instance, "Message delivered by Legobot, on behalf of Chetsford" (e.g. [2]). Is there a way to amend the script so it clarifies, when posting messages on behalf of editors, that the tool is posting the message "on behalf of" and that the editor did not personally compose the message him/herself? Chetsford (talk) 18:35, 3 March 2018 (UTC)
@Insertcleverphrasehere, Barkeep49, and Chetsford:-- Done.∯WBGconverse 06:40, 28 October 2018 (UTC) |
63. Capacity to handle 2nd+ AfD nominations
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently, when a page is nominated for AfD using the curation toolbar and there exists a previous nomination, the result is a minor trainwreck - see e.g. my last instance. Such nominations have to carried out manually. Some functionality to detect previous nominations, increment the count, and handle the paperwork would be very welcome. (I'm getting the impression that some articles remain un-nominated because people don't want to tangle with the manual process, which seems counterproductive). --Elmidae (talk · contribs) 13:48, 8 March 2018 (UTC)
- Support This is a pretty major failing of the PC tools, a deficiency that I have not noticed occurring with twinkle (just another reason to use twinkle for all deletions, (in addition to the lack of ability to have a userspace CSD log. — Insertcleverphrasehere (or here) 10:04, 17 March 2018 (UTC)
- It's not a 'major' problem, and in any case,only admins can do deletions. BTW, this is not a RfC. Kudpung กุดผึ้ง (talk) 14:16, 17 March 2018 (UTC)
- Support Among the reasons I still use twinkle. DGG ( talk ) 19:35, 17 March 2018 (UTC)
- Support--Crazy bug! One of the reasons behind Twinkle's constant popularity:)~ Winged BladesGodric 13:24, 22 March 2018 (UTC)
- Support as useful. Object to the notion that AfD it does'n work in Curation. It works oerfectly and it's even easier than Twinkle. Kudpung กุดผึ้ง (talk) 11:06, 18 May 2018 (UTC)
- Strong support - definitely. I do hope this bug will get fixed at some point; it appears to still be occurring.--SkyGazer 512 Oh no, what did I do this time? 23:21, 21 September 2018 (UTC)
- Use Twinkle! There is nothing in the PC's deletion module that can't be done using Twinkle. (This isn't so for the tagging module - TW doesn't allow sending a message to the creator, and the UI/UX is poorer.) But Twinkle's CSD, PROD, XFD modules are simply perfect and have stood the test of time. Any bugs found in them are usually fixed quickly. WMF devs have just wasted their time building something that's totally redundant to, as well as inferior to the already existing functionality in Twinkle. SD0001 (talk) 19:04, 1 January 2019 (UTC)
- According to Phab, this is now done. Someone please check. Barkeep49?. Kudpung กุดผึ้ง (talk) 07:18, 13 September 2019 (UTC)
- @Kudpung: unfortunately, that isn't the case; according the phab, the investigation into feasibility is done, the actual work is at phab:T231357 DannyS712 (talk) 07:57, 13 September 2019 (UTC)
- DannyS712 is correct. The original ticket was an investigation into how feasible this change would be. We might have to put it back on a future wishlist to actually get done. Best, Barkeep49 (talk) 13:13, 13 September 2019 (UTC)
- Barkeep49, I don't think that we need to put it into a future wishlist. MaxSem has already submitted a patch and someone is going to review them, soon enough pending which this ought to go into production .... ∯WBGconverse 13:25, 13 September 2019 (UTC)
- DannyS712 is correct. The original ticket was an investigation into how feasible this change would be. We might have to put it back on a future wishlist to actually get done. Best, Barkeep49 (talk) 13:13, 13 September 2019 (UTC)
- @Kudpung: unfortunately, that isn't the case; according the phab, the investigation into feasibility is done, the actual work is at phab:T231357 DannyS712 (talk) 07:57, 13 September 2019 (UTC)
64. CSD/PRODs: update userspace logs
Continue discussion at #55 above
|
---|
While Twinkle keeps a userspace log of these forms of deletion nomination, the page curation toolbar does not. To maintain interoperability with twinkle, it probably should read the relevant section of twinkleoptions.js, if it exists. ∰Bellezzasolo✡ Discuss 11:24, 30 March 2018 (UTC)
|
65. Reviewer No Decision
Done
|
---|
As someone who tends to hang-out more in the oldest view of NPP, it would be helpful if reviewers had a way, like on the Article Talk page, to indicate that they had undertaken a review of a page but did not reach a decision with the option to include a message about why. If several reviewers all start looking at an article and move on that says something (what it says would depend on circumstances) vs if a reviewer happens to be the first person to actually examine an article. Best, Barkeep49 (talk) 06:07, 18 May 2018 (UTC)
|
66. N articles deleted (of which Z via SD) out of M created
Generating a SD% is too troublesome.Not worth it.
|
---|
As a reviewer I think adding this query would be welcomed by many reviewers: a way to show the number of deleted articles right in the Page Curation tool (e.g. Created by Username (talk | contribs) · XXX edits since dd Month year) - N articles deleted (of which Z via SD) out of M created. This would be useful in cases (and there are many) when a user keeps creating pages without reading the basic policies and on his talk page we see that most of the newly created articles were sd. We'd have a percentage of the editor's sd page percentage. And, seeing a notice in this regard would be some sort of heads up for the reviewer, although sometimes other editors may of been improved the article and obviously we need to take a closer look. Robertgombos (talk) 19:23, 1 June 2018 (UTC)
|
67. [Bug] Cleanup tag preventing marking incorrectly
I cannot replicate either.Was a local bug or was fixed at some point.
|
---|
Not sure if this is the correct spot, let me know if I need to post it somewhere else If you tick the box to tag a page with the Cleanup tag, then uncheck the box and attempt to submit the other tags, the curation tool will inform you that you must add a description to the cleanup tag before submitting it. You can work around this by ticking and unticking the cleanup tag again, but it would still be nice to get this bug fixed. Xevus11 (talk) 05:10, 29 June 2018 (UTC)
|
68. Requesting revision deletion
Adding functionality to the Page Curation tools to allow a reviewer to easily request Revision Deletion is essential. Currently the only options that it gives is to drop a generic {{non-free}} template, or else CSD nomination. There aren't any good tools for requesting Revdel either. I would envision something along the lines of pulling up a scroll-able list of revisions, and the user simply selection ranges to be tagged for Revdel. — Insertcleverphrasehere (or here) 04:02, 4 September 2018 (UTC)
- Support Best, Barkeep49 (talk) 05:35, 4 September 2018 (UTC)
- Support — Yep, this would make a lot easier to request cv-revdel. Regards, SshibumXZ (talk · contribs). 07:41, 19 October 2018 (UTC)
- Best tool for this currently is User:Enterprisey/cv-revdel. This tool is great but it would be really good to have this added as an option in the Page Curation tools as a popup. — Insertcleverphrasehere (or here) 08:56, 19 October 2018 (UTC)
- ICPH,I believe the pop-up addition can be locally implemented.Will take a look:-) ∯WBGconverse 16:21, 21 October 2018 (UTC)
- Insertcleverphrasehere, the copyvio-revision-deletion template (wherein either the set of diff(s) have to be manually inputted or (that I had integrated the copy-patrol functionality into the template), the Copypatrol URL of the violation can be directly inputted) can be easily implemented into the Curation toolbar.
- Would that be any helpful? ∯WBGconverse 20:13, 21 October 2018 (UTC)
- @Winged Blades of Godric: At the very least it would be helpful to simply dump the empty template on the page via a tag. I've noticed that even if you don't fill in the Diffs, if it is simple most admins can figure out which revisions need to go relatively quickly. Thanks for helping out with these tasks. Cheers, — Insertcleverphrasehere (or here) 20:17, 21 October 2018 (UTC)
- Thanks:-) This can be sought as an edit-request but to avoid any messes, I have asked for permission to try the integration at Beta-cluster. ∯WBGconverse 05:53, 22 October 2018 (UTC)
- @Winged Blades of Godric: At the very least it would be helpful to simply dump the empty template on the page via a tag. I've noticed that even if you don't fill in the Diffs, if it is simple most admins can figure out which revisions need to go relatively quickly. Thanks for helping out with these tasks. Cheers, — Insertcleverphrasehere (or here) 20:17, 21 October 2018 (UTC)
- @Galobtter:--Does this look any good? A few system-messages need to be locally created though!∯WBGconverse 09:37, 22 October 2018 (UTC)
- Winged Blades of Godric, looks reasonable, but I'm no js expert or know too much about the configuration of the page triage extension - so testing on testwiki:MediaWiki:PageTriageExternalTagsOptions.js by asking one of the intadmins at Special:ListUsers/interface-admin would be good. Galobtter (pingó mió) 09:50, 22 October 2018 (UTC)
- Thanks:-) Asked Oshwah! ∯WBGconverse 10:29, 22 October 2018 (UTC)
- Tweaked a bit and this is the new diff:-)∯WBGconverse 17:24, 22 October 2018 (UTC)
69. Passive aggressive messaging system
On-wiki templates amended
|
---|
Remove the "Thanks for creating XXXXXX, Author!" from the message template, or at least get rid of the exclamation point. If I want to send negative feedback, especially to say that the page is inappropriate and unsuited for Wikipedia, it comes off as extremely passive-aggressive. — Insertcleverphrasehere (or here) 04:17, 4 September 2018 (UTC)
|
70. Curation toolbar opt-out or opt-in in preferences
Worked upon by Miller.Xao has already provided a nice solution.
|
---|
The page curation toolbar has now been enabled by default for every page you open from the special:newpagesfeed. Not all of us want this though (at least I don't): I do new page patrolling, but don't need or want the curation toolbar, and it is rather intrusive. Having to minimize and remove it on every page is tiresome. Can we please have an option in preferences to opt-in or opt-out of this toolbar? Fram (talk) 14:34, 19 October 2018 (UTC)
|
84. 'Potential Issues' flagged in Page Curation Toolbar Page Info flyout
Fixed
|
---|
As far as I can see, the page curation tool is supposed to flag 'potential issues' in the 'Page info' section of the toolbar (or at least this is what was intended when it was being made [3]). This info is currently visible from the NewPagesFeed, but not from the toolbar. This functionality seems to be nonexistent and was either never implemented properly, or has become bugged and broken. It should contain things like 'Blocked user', 'Orphaned', 'No categories', as well as the ORES stuff that has been added recently: 'Possible Vandalism', 'Possible Spam', 'Possible attack page', and 'Possible Copyvio' which is currently being added to New Pages Feed (this last one should also have a link to the Copyvios report). When a page has issues it should be flagged with a red number on the Page Info Icon as shown in the mockups at the link above. — Insertcleverphrasehere (or here) 13:45, 24 October 2018 (UTC)
|
86. Page Curation toolbar: do not mark pages as 'reviewed' when adding CSD and PROD tags
Done
|
---|
Per this discussion, we have decided that it is best to not mark pages as 'reviewed' when adding CSD and PROD tags to articles (due to the ease at which articles can fall through the cracks if these tags are removed and the reviewer doesn't notice). The Page Curation toolbar currently automatically marks pages as 'reviewed' when adding CSD tags and PROD tags, this should change and simply leave the page unreviewed after the page is tagged for deletion (that way it will fall back into 'unreviewed' pages if the CSD tag is removed inappropriately or if the PROD is removed). |
88. Add Tags and hatnotes
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Doesn't the Add Tags feature recognise hatnotes and place the tags below them, per WP:MOSLAYOUT? I noticed this from this edit. --Paul_012 (talk) 16:14, 12 May 2019 (UTC)
- Currently, tagging is done via a wrapper api that only accepts as parameters what tags to prepend and what to append (and others not relevant here) - this would require reworking the api to parse the current text and place them accordingly DannyS712 (talk) 04:55, 18 September 2019 (UTC)
89. A Curation tool message that's using a non-existant template
Resolved
|
---|
This is maybe already fixed, but it appears CurationTool is trying to subst Template:Sentnote-NPF instead of Template:Reviewednote-NPF, see this example or this which shows a handful of instances. Can this sentnote template redirect to reviewednote or are they supposed to include different text? --148.63.157.82 (talk) 22:59, 23 July 2019 (UTC)
|
93. Have page curation be less hard coded and more controllable by Wikipedia
Right now a lot of things are hard coded into page curation. Given that the WMF has said that they will not devote regular resources to page curation and that instead we need to go through the wishlist, it seems to me that moving as much control as possible to the encyclopedia through templates, would be desirable. IN this way even if the WMF cannot devote resources those volunteers who wish to do so could continue to adapt and change the page curation tool. For instance, the length of time that it takes for a redirect or article to be indexed could be controlled via template rather than be hard coded into the curation tool. There are probably other such things. If/when the WMF extends the curation tool to other wikipedias this sort of local control would only become more important - for instance they might not have the same content tag concerns as us and so there wouldn't be a desire for every tag we have, but on the other hand they might have other warnings that we don't have which they would like to be able to tag on articles. Best, Barkeep49 (talk) 23:15, 11 August 2019 (UTC)
- The way PageTriage code-base is written, it's sheer impossible to incorporate a wiki-agnostic mode. Same for most other stuff. Sans a complete overhaul, not possible, I dare say. ∯WBGconverse 09:19, 13 September 2019 (UTC)
Article patrol status after refund/undelete
Per the discussion, when an article is undeleted per WP:REFUND, it should always be back in the queue. MB 18:51, 25 June 2022 (UTC)
- I'll support that. I'm surprised it's not a;ready done. I guess I kinda took it for granted. Kudpung กุดผึ้ง (talk) 06:34, 26 June 2022 (UTC)
80. Page Curation tools optionally available on any page, not just those in NewPagesFeed
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
It should be possible to make ?showcurationtoolbar=1 and the 'curate this article' link work on any article, not just those in the feed (but currently can only be used on articles that have not expired out of the NewPagesFeed).
It is quite annoying that the Page Curation tools are only available for new pages that haven't expired, it means that I have to use Twinkle whenever a page has been reviewed and expires out of the feed.
It silly that the Page Curation tools are only available on new pages and not, for example, on Broadwater Green. IMO the 'curate this article' link in the toolbar should always be available to New Page Reviewers regardless of the page they are reviewing (It would even be useful for drafts).
Note that the page curation tools should ONLY show up on 'other pages' (pages that aren't in the NewPagesFeed) if that string is added to the URL or if you click the 'curate this article' link. Otherwise I think people would get quite annoyed with it showing up on all sorts of other pages constantly. — Insertcleverphrasehere (or here) 16:07, 19 October 2018 (UTC)
- This can be likely implemented easily, via a patch.Let's see. ∯WBGconverse 20:09, 27 October 2018 (UTC)
Vandalism by Category and Importance?
Is Vandalism on stubs or low rank articles common? And do unwatched articles get more vandalism? I know there can be multiple projects, but the project importance quality table might be good to have in long run, https://wiki.riteme.site/wiki/Wikipedia:Version_1.0_Editorial_Team/Star_Wars_articles_by_quality_statistics Wakelamp d[@-@]b (talk) 08:52, 24 November 2021 (UTC)
- @Wakelamp: There are hundreds of projects on Wikipedia (if not thousands). No priorities are set, or can be set for them. School artcles receive a high dose of vandaliasm, for example, because they attract children, but there are possibly others. As this is not a tool request or a bug report, please consider reposting your question at WT:NPR where it will get more exposure and a faster response. Kudpung กุดผึ้ง (talk) 04:04, 11 April 2022 (UTC)
Mark unpatrolled
This feature, if it doesn't already exist, was suggested by this unanswered question I found while looking at the Help Desk archives.— Vchimpanzee • talk • contributions • 18:00, 23 November 2021 (UTC)
- A patroller can add any page back to the NPP queue by clicking "Add to the New Pages Feed" in the "Tools" left hand menu Polyamorph (talk) 19:58, 23 November 2021 (UTC)
- I'll let the person know. Thanks.— Vchimpanzee • talk • contributions • 20:25, 23 November 2021 (UTC)
Please move the “mark as reviewed” checkbox
I do all my reviewing on iPad and the checkbox for “mark as reviewed” is about one fifteenth of a fingertip away from the green bar for “add selected tags”. This means I frequently make fat finger errors and have to go back and unreview an article. Instead of appearing just above the green bar could the checkbox move over to the right to allow clear space between them? Thanks Mccapra (talk) 11:48, 14 November 2021 (UTC)
- Hey @Mccapra. Thanks for your suggestion. You're talking about the check mark in the vertical toolbar right? The vertical toolbar is already all the way to the right of the screen, leaving no space to move it further right, so I think I am missing something. Feel free to clarify. –Novem Linguae (talk) 06:36, 23 July 2022 (UTC)
- Thanks for following up. I’ve added a screenshot above. What I’m asking is for the “Mark this page as reviewed” checkbox to be moved away to the right so it takes two distinct finger movements to add tags and to mark as reviewed. At the moment it’s too easy to accidentally mark as reviewed when I only mean to add tags, since the two are so close together. Thanks Mccapra (talk) 07:28, 23 July 2022 (UTC)
- Got it. That's an easy one. I'll prioritize it. Thanks for suggesting. –Novem Linguae (talk) 07:53, 23 July 2022 (UTC)
- Woo hoo! Tick box has moved! Thank you! Mccapra (talk) 08:00, 29 July 2022 (UTC)
- Got it. That's an easy one. I'll prioritize it. Thanks for suggesting. –Novem Linguae (talk) 07:53, 23 July 2022 (UTC)
- Thanks for following up. I’ve added a screenshot above. What I’m asking is for the “Mark this page as reviewed” checkbox to be moved away to the right so it takes two distinct finger movements to add tags and to mark as reviewed. At the moment it’s too easy to accidentally mark as reviewed when I only mean to add tags, since the two are so close together. Thanks Mccapra (talk) 07:28, 23 July 2022 (UTC)
Page feed introduction
At the top of the Page feed, there is the intro text beginning with "Rather than speed..." I would like a way to remove that to maximize the number of articles shown on the screen. I know you can scroll it off, but it comes back if you are scrolling within the article list. Can this be collapsed to hide it (with the collapse button being in the unused space in the header bar). MB 15:13, 19 August 2022 (UTC)
- @MB. The code for that is located at MediaWiki:Pagetriage-welcome. Maybe sandbox something then propose it at MediaWiki talk:Pagetriage-welcome. I've watchlisted the page and will be sure to weigh in. –Novem Linguae (talk) 20:06, 19 August 2022 (UTC)
- I tried to create a sandbox over there, but unlike a protected template, I couldn't edit the sandbox. I made this with a simple hide button. It's not exactly what I wanted, but now knowing how that is done, it's close enough. What do you think? MB 06:39, 20 August 2022 (UTC)
- Thanks for sandboxing it. Looks great. Let's move forward by doing an {{Edit fully-protected}} on the talk page. –Novem Linguae (talk) 08:43, 20 August 2022 (UTC)
- Before I do that, do you know if there is a way to hide it instead of just collapse it, so there isn't even a line with "show" visible. The notifications on the top of the watchlist are dismissible. I know they use cookies to keep messages dismissed, and I don't mean that. Just a way hide the message knowing it would come back every time the page is reloaded. I couldn't figure out how the watchlist dismiss feature works to even be able to make a non-persistent version. MB 20:24, 21 August 2022 (UTC)
- Looks like MediaWiki:Gadget-watchlist-notice-core.js is what makes the dismiss button work. This is a gadget that is enabled by default for everyone, although it is possible to turn it off. A dismiss button could probably be hacked to work outside the watchlist, but could be a bit fragile. Might be better to just move forward with the collapse box. Or you can make a request over at WP:Requested templates to create a new Template:Dismissable or similar. –Novem Linguae (talk) 02:03, 22 August 2022 (UTC)
- Before I do that, do you know if there is a way to hide it instead of just collapse it, so there isn't even a line with "show" visible. The notifications on the top of the watchlist are dismissible. I know they use cookies to keep messages dismissed, and I don't mean that. Just a way hide the message knowing it would come back every time the page is reloaded. I couldn't figure out how the watchlist dismiss feature works to even be able to make a non-persistent version. MB 20:24, 21 August 2022 (UTC)
- Thanks for sandboxing it. Looks great. Let's move forward by doing an {{Edit fully-protected}} on the talk page. –Novem Linguae (talk) 08:43, 20 August 2022 (UTC)
- I tried to create a sandbox over there, but unlike a protected template, I couldn't edit the sandbox. I made this with a simple hide button. It's not exactly what I wanted, but now knowing how that is done, it's close enough. What do you think? MB 06:39, 20 August 2022 (UTC)
Page Curation toolbar not displaying
The page curation tool hasn’t been showing up for a while now. I thought it would with time, but it hasn’t. It stopped working after it glitched when I used it to nominate an article for deletion (which didn't work right, btw). Any help? Any suggestions? R E A D I N G Talk to the Beans? 04:33, 7 August 2022 (UTC)
- Hey @Reading Beans. Thanks for the question. AFD is super buggy, I've been working on fixing that one for a couple weeks. It's been a tricky set of bugs to crush, hopefully my patch coming out this Thursday finishes fixing it.
- As for your toolbar not showing up, can you click on Kuala Pembuang and see if this page displays the toolbar after a few seconds? If not, can you take a screenshot and post it here? Can you also follow the directions at WP:CONSOLEERROR and see if there's any relevant errors? –Novem Linguae (talk) 04:41, 7 August 2022 (UTC)
- I had to remove every other script present in my common.js page. It’s working now, thank you. Reading Beans (talk) 05:24, 7 August 2022 (UTC)
- @Reading Beans. If you can figure out exactly what other script is interfering with PageTriage, I'd be happy to take a look. Otherwise I'll probably archive this soon. I'm glad you got it working :) –Novem Linguae (talk) 03:42, 24 August 2022 (UTC)
- @Novem Linguae, I cannot really tell. Archiving it 100% fine. Reading Beans (talk) 22:48, 24 August 2022 (UTC)
- @Reading Beans. If you can figure out exactly what other script is interfering with PageTriage, I'd be happy to take a look. Otherwise I'll probably archive this soon. I'm glad you got it working :) –Novem Linguae (talk) 03:42, 24 August 2022 (UTC)
- I had to remove every other script present in my common.js page. It’s working now, thank you. Reading Beans (talk) 05:24, 7 August 2022 (UTC)
Add "were created by autopatrolled users" to filter list
Abuse by UPE, spammers, and simply editors who totally fail to create their new pages in the spirit of the user right. These problems are being increasingly discovered through better due diligence and patroller intuition and the rate is alarming. These new pages are still listed on new page lists and feeds, but are listed with the green check mark as if they have been reviewed by a patroller. I'm therefore requesting the addition of 'were created by autopatrolled users' as an option in the prefs panel. I'm sure this was asked for during the development of the panel, but it was overlooked at the time. See themw:Page_Curation development page. Kudpung กุดผึ้ง (talk) 21:41, 7 July 2022 (UTC)
- This patch got approved today. It will deploy next Thursday 8/11. –Novem Linguae (talk) 11:36, 3 August 2022 (UTC)
Prod does not write reason
PageTriage pops up an error message "Tag subst:prod is missing required parameter"
Have redirects be indexed after same length of time as articles
Quoting Rosguill The backlog length for the New Pages Queue for articles is 90 days, but several weeks ago editors realized that redirects were dropping off of the queue after only 30 days. In practice, this means that many if not most redirects will not be reviewed. This problem would be solved if the backlogs were both 90 days long. Note that currently there should be no redirects older than 20-something days in the queue, as once we noticed the problem a few editors made sure to keep the back of the queue patrolled.
. Best, Barkeep49 (talk) 23:10, 11 August 2019 (UTC)
- Implementing this is trivial. But, it can't proceed unless MusikAnimal is done with his calculations on the impact of this on database-storage or some DBA gives clearance. ∯WBGconverse 10:32, 13 September 2019 (UTC)
- @Winged Blades of Godric: That task was removed from Community Tech's board because it wasn't on the wishlist. It is super trivial to fix (which is why we were going to do it), but as we discovered, some years ago redirects were intentionally changed to be removed from the queue after only 30 days. We're not sure why! I can only suspect it's because the massive number of rows that would be added as a result. I think the decision is going to be with the DBAs, who may not take kindly to that much extra storage. Not that it's your responsibility, but anyone can do the math if you know how to run some SQL queries. Basically there are a bunch of "tags" for each entry in the queue, and we'd need to multiply that times however many redirects would be added from the extra 60 days worth of data, then evaluate the costs/benefits. This of course would be a rough estimate. Frankly I think phab:T228952 should happen first, which is very non-trivial. Most of this is because of decisions that were made in the design of PageTriage from well before we worked on it. We've improved it quite a bit, but it's still a painful battle trying to make any architectural changes. — MusikAnimal talk 19:50, 13 September 2019 (UTC)
- @Rosguill, Winged Blades of Godric, MusikAnimal, Barkeep49, and Insertcleverphrasehere:, I remember discussing the drop off time with the devs some time ago - I think it was during the run uo to ACTRIAL - and we agreed to fix it at 90 days. However, in view of the lack of enthusiasm to patroll pages, even that may not be long enough. At the time, I naturally assumed that all pages that come under review at NPP would be subject to 90 days, so it was not queried. I think this is important because redirects are the one way that spammers game the system to recreate deleted pages. More important than phab:T228952, - which I don't understand - and which has already been shelved anyway. Kudpung กุดผึ้ง (talk) 02:43, 14 September 2019 (UTC)
- Kudpung, we're missing the 90 days mark some of the time now but I think that roughly a quarter of a year is a fair compromise between not letting bad stuff appear in Google and giving us a reasonable amount of time to get to articles. Plus to some degree deadlines help. The fact that redirects just disappear from the queue rather than sitting there makes sense to me - redirects are cheap and the cost of not patrolling them is less. However combining this with the 30 day drop-off is not a great combo. MusikAnimal's point about the painful battle of PageTriage (one I'd love for him to repeat at our current conversatoin but understand if he can't) is why addressing that for me is the biggest priority. Best, Barkeep49 (talk) 02:58, 14 September 2019 (UTC)
- @Rosguill, Winged Blades of Godric, MusikAnimal, Barkeep49, and Insertcleverphrasehere:, I remember discussing the drop off time with the devs some time ago - I think it was during the run uo to ACTRIAL - and we agreed to fix it at 90 days. However, in view of the lack of enthusiasm to patroll pages, even that may not be long enough. At the time, I naturally assumed that all pages that come under review at NPP would be subject to 90 days, so it was not queried. I think this is important because redirects are the one way that spammers game the system to recreate deleted pages. More important than phab:T228952, - which I don't understand - and which has already been shelved anyway. Kudpung กุดผึ้ง (talk) 02:43, 14 September 2019 (UTC)
- @Winged Blades of Godric: That task was removed from Community Tech's board because it wasn't on the wishlist. It is super trivial to fix (which is why we were going to do it), but as we discovered, some years ago redirects were intentionally changed to be removed from the queue after only 30 days. We're not sure why! I can only suspect it's because the massive number of rows that would be added as a result. I think the decision is going to be with the DBAs, who may not take kindly to that much extra storage. Not that it's your responsibility, but anyone can do the math if you know how to run some SQL queries. Basically there are a bunch of "tags" for each entry in the queue, and we'd need to multiply that times however many redirects would be added from the extra 60 days worth of data, then evaluate the costs/benefits. This of course would be a rough estimate. Frankly I think phab:T228952 should happen first, which is very non-trivial. Most of this is because of decisions that were made in the design of PageTriage from well before we worked on it. We've improved it quite a bit, but it's still a painful battle trying to make any architectural changes. — MusikAnimal talk 19:50, 13 September 2019 (UTC)
- Support much longer drop-off time. What we don't get to now, we should still get to if we can. We won't get to all the old ones any more than now, but they will be there for people who, like myself, try to look for ones whose title or some other indication suggests that there might be a problem. I really do not see the point of having the drop off at all. DGG ( talk ) 04:44, 14 September 2019 (UTC)
- Until a page has been viewed and reviewed, nobody knows what's on it. The face of the waterfall at NPP has changed. There is no denying that while an encyclopedia can never be complete, most of the traditional encyclopedic topics are catered for and being updated and maintained. What we are left with are the incessant non notable bios and autobios, footballers whose footy SNG has an even lower bar than BASIC or GNG, reality shows, Bollywood, and more bios. The new enhancements to the entries in the feed provided by ORES provide an excellent overview already, although some things might be missed by newer reviewers through banner blindness, or those who patrol too fast. It's therefore essential that nothing gets indexed before it has been checked. I think here is now a very strong argument to extend the 90 day drop off, or even have it open ended per DGG. The disadvantage with the latter however, is that reviewers will continue to go for the low hanging fruit knowing that there would no longer be a sense of urgency. Kudpung กุดผึ้ง (talk) 05:31, 14 September 2019 (UTC)
- That will need a site-wide RFC ..... ∯WBGconverse 13:43, 14 September 2019 (UTC)
Redirects - issue 1
Redirects when an RfD tag or any other material is added to them, but they remain redirects, should not be in the New Page feed. Done please verify. Kudpung กุดผึ้ง (talk) 02:38, 13 September 2019 (UTC)
- Concur.- MrX 12:45, 2 September 2016 (UTC)
- Agree Lineslarge (talk) 00:05, 25 September 2017 (UTC)
Orphan in possible issues
Hi greetings, I'd like to suggest an improvement in page curation toolbar. We know, while using the page info in the tool, we can see the possible issues such as No citation, Orphan, etc. The article is seem to be orphan when there is no links from other pages in the main article namespace. But the tool considers the links from pages in all namespaces, not only from mainspace. Sometimes new articles may not have links from other articles, but from pages in other namespaces such as talks, user talks, etc. The tool does not determine it as orphan, but actually the article is orphan. It will be a great help, if the tool consider the links only from mainspace while determining whether the article is orphan or not. Hope that this issue will fixed. Regards.--PATH SLOPU 11:45, 28 September 2019 (UTC)
- Agreed, although it isn't much of a problem to be honest as users will rarely link non-existant articles in talk pages, unless they are linked in the small window between the page being created and the page being reviewed. Nonetheless, if this is the case, I would support a change. Willbb234Talk (please {{ping}} me in replies) 21:07, 24 November 2019 (UTC)
- Support Mccapra (talk) 11:39, 14 November 2021 (UTC)
- Support MarioGom (talk) 12:46, 14 November 2021 (UTC)
Done Expect the number of pages that are tagged as orphaned to slowly tick up. For reference, that number was 30 yesterday, it is around 65 now. -MPGuy2824 (talk) 03:07, 30 September 2022 (UTC)
This page is only X minutes old
Messages like "This page is only 4 minutes old. Consider waiting to tag it, unless the issue is serious." appear on the page curation tab even if a page is a few hours old. This doesn't seem to appear for article created more than 6 hours back. -MPGuy2824 (talk) 02:48, 5 August 2022 (UTC)
- @MPGuy2824. Likely a timezone bug. I've never seen this message myself, probably also because of a timezone bug. What button do you click that causes this notice to appear (when opening tag menu, or when placing tag?) Also, where does the warning appear (inline somewhere, as a browser popup window, as a mediawiki alert on the top right?) –Novem Linguae (talk) 03:19, 5 August 2022 (UTC)
- Right now, for a 2-hour old article picked at random, Darren Oved, i can see it after clicking the "delete" and "tag" buttons. My Wikipedia prefs are set to IST. -MPGuy2824 (talk) 03:23, 5 August 2022 (UTC)
Done -MPGuy2824 (talk) 03:53, 30 September 2022 (UTC)
New Page feed statistics
The stats in the footer show the total backlog (without redirects), and the number of pages reviewed in the past week (including redirects). Requesting this be improved to show number of non-redirect pages reviewed separately. MB 00:26, 8 June 2022 (UTC)
Page Curation messages
The messages handed out by the PC tool should be embodied in templates on the local wiki rather than hard-boiled into the software.
Last month I received a "I have unreviewed a page you curated" message for the first time. Because the page's author had mangled the CSD template the message I received bore no resemblance to the facts as I knew them so I tried to investigate. However, the message is bare text and offers no clue to its origin - whereas most messages are transcluded or substed templates which show where they came from.
The message did not conform to the norms of this wiki:
- it wasn't signed;
- it invited a continuation of the discussion on another page rather than keeping the discussion together in one place; and
- there was no edit summary.
The first two issues would easily be resolved if the message were embodied in a template rather than the software. This change could also resolve the #Removing the 250 character limit issue raised by Mz7. Cabayi (talk) 17:42, 28 November 2016 (UTC)
- I agree. I raised this years ago to a WMF developer liaison only to have it dismissed. It's poor design. Sending a message to the reviewer when a page is unreviewed should also be optional, and should not be the default. It would be better to have any such message in the revision history as an edit summary anyway.- MrX 16:02, 15 June 2017 (UTC)
- Strongly agree Ican think of no reason why this would not be a major improvlement, in letting us make changes without waiting for years. DGG ( talk ) 19:33, 17 March 2018 (UTC)
- @Cabayi: -- Done. The first and last have been already, in place for long. I updated the language of the templates to keep the discussion, entirely on reviewer's talk.Check it out:-)Best, ∯WBGconverse 08:27, 28 October 2018 (UTC)
- Thanks Winged Blades of Godric. Yes, I saw Galobtter closed off the ticket this morning. How did it take two years for the existence of the messages at Category:New Pages Feed templates to come to light?? (*ahem* poor documentation) Now that they are in the daylight, it seems just as bizarre that they're not protected in any way - pinging interested admins TonyBallioni, DGG, Mz7 to ponder that issue. -- Cabayi (talk) 11:13, 28 October 2018 (UTC)
- The most intuitive solution would be to prevent a message from being sent when the note
textarea
is empty. << FR (mobileUndo) 08:06, 22 February 2019 (UTC)
- The most intuitive solution would be to prevent a message from being sent when the note
- Thanks Winged Blades of Godric. Yes, I saw Galobtter closed off the ticket this morning. How did it take two years for the existence of the messages at Category:New Pages Feed templates to come to light?? (*ahem* poor documentation) Now that they are in the daylight, it seems just as bizarre that they're not protected in any way - pinging interested admins TonyBallioni, DGG, Mz7 to ponder that issue. -- Cabayi (talk) 11:13, 28 October 2018 (UTC)
- All have been done. But, MrX, I see that WMF has fulfilled your request by eliminating the need to send any customized message in case of un-reviewing, altogether. Now, whenever we un-review any reviewed page, a standard boilerplate is delivered to the t/p of orig. reviewer. LOL; this ought be a bug and shall be fixed. ∯WBGconverse 13:25, 14 September 2019 (UTC)
Automated messages while reviewing a page or unreviewing it must be optional
Please add a check box at the window to mark the page as reviewed, where it says send a message to the page creator or the reviewer. The sending of message should be optional. --DBigXrayᗙ 17:43, 20 February 2020 (UTC)
Funky wording when messaging past reviewers
I noticed a funky wording with the tool when sending a message as I was marking a page as unreviewed. Under the section header "I have sent you a note about a page you reviewed", the tool automatically writes "Thank you for creating XXX", even though (with the exception of autopatrolled users) the recipient is the reviewer and not the creator. This is what the tool automatically did; I believe it should instead write "Thank you for reviewing XXX" or, better yet, omit that line altogether when messaging a reviewer. ComplexRational (talk) 00:24, 21 June 2022 (UTC)
- PageTriage is loading Template:Sentnote-NPF. Would likely need to create a 2nd template with the new wording, then update the logic in mark.js and extension.json to use the new template when messaging reviewers. I might work on this one sometime, when I feel like learning the custom system Gerrit uses, which is a prerequisite for submitting code. –Novem Linguae (talk) 11:51, 21 June 2022 (UTC)
"Set filter" button isn't accessible
The filter popup of the New pages feed is now quite large. I'm barely able to click the (almost) hidden "Set filter" button. Could all the "Were created by X" be clubbed into one drop-down option? Maybe the "were created by username" can be left out of this, since it uses a text-box input as well. -MPGuy2824 (talk) 07:11, 19 August 2022 (UTC)
- Good idea. We either need to do that (move those options into a combo box as you suggest), or unfloat the "set filters" bar, which would give a scroll bar when opening the filters panel. As a workaround, if the "Set filters" button is off the screen, you can zoom out in your browser to reveal it. –Novem Linguae (talk) 08:11, 19 August 2022 (UTC)
- I just suggested rearranging this on the discussion page as an alternative. I think multiple columns would work also and be simpler. MB 15:15, 19 August 2022 (UTC)
The following was moved from Wikipedia talk:New pages patrol/Reviewers to keep all related discussion together with the associated phab ticket.
cc @Andrew Davidson, MPGuy2824, and Extraordinary Writ:
I'd like some help in deciding what to do about the Special:NewPagesFeed -> "Set filters" green button being nearly off or completely off the screen, because the top bar floats and the menu is nearly full. Here's a couple potential solutions:
- Unfloat the top bar (will give you a scroll bar)
- Move the "Set filters" button to the top of the panel
- Combine "Were created by X" into one option, and allow the user to pick what specifically via a combo box. (hardest to write code for)
If you have a preference, please reply and let me know. Current workaround is to zoom out your browser. –Novem Linguae (talk) 08:22, 19 August 2022 (UTC)
- Moving the "Set Filters" button would be enough but maybe one/some the last few options might be unclickable. If the combo box is quite hard to do, then your first option "Unfloat" would be my choice. -MPGuy2824 (talk) 08:27, 19 August 2022 (UTC)
- If possible, my preference is to move the green button into the centre of the filter dialog box, where there's plenty of empty space for it. And I'd also adjust the float so that there's always a scroll bar if needed, just in case the user has a small screen/window for some reason. Zooming out is not ideal as some users have weak eyesight and so can't read tiny text. Andrew🐉(talk) 08:36, 19 August 2022 (UTC)
- It looks to me that there is a lot of white space within the "Set Filters" box. Have you considered just moving things around. If "Date range" was right under "In namespace" and the space between the columns was reduced, then "State" and "Type" could be moved up into a fourth column making better use of the width of the box. Then "That" would start higher up. Alternatively, put the options of "That" into two columns. MB 15:02, 19 August 2022 (UTC)
- Unfloat seems like the simplest solution. People are used to scroll bars, so the interface would be easy to understand. Changing the menu structure seems like a brittle solution, as future changes in the menu could cause the problem to appear again. — rsjaffe 🗣️ 16:03, 19 August 2022 (UTC)
- I really don't like multiple scroll bars - there is already the main pages feed scroll bar and the two could be adjacent, depending on the window size, making it easy to mis-click. Also, I find it can be confusing knowing which window is active when using the scroll wheel on a mouse. For these reasons, anything with two scroll bars would be my last choice. MB 03:16, 20 August 2022 (UTC)
- There would just be one scroll bar. Hard to explain, but unfloating it would work and would just use the existing scroll bar. –Novem Linguae (talk) 04:04, 20 August 2022 (UTC)
- I really don't like multiple scroll bars - there is already the main pages feed scroll bar and the two could be adjacent, depending on the window size, making it easy to mis-click. Also, I find it can be confusing knowing which window is active when using the scroll wheel on a mouse. For these reasons, anything with two scroll bars would be my last choice. MB 03:16, 20 August 2022 (UTC)
- I would propose doing both unfloating and moving the button. So the button is always visible for most screen resolutions, but there is also easy scroll for whatever gets off screen. MarioGom (talk) 06:30, 23 August 2022 (UTC)
- I had this discussion at WT:NPPR to get increased traffic. We may have moved it too early. This still isn't a very strong consensus. I may just make an executive decision and move forward with the unfloat option. –Novem Linguae (talk) 23:26, 25 August 2022 (UTC)
@MarioGom, Novem Linguae, MB, and Andrew Davidson: I distinctly remember suggesting somewhere recently that the Predicted Class and Potential Issues choices should be default displays in the feed and removed from the filter prefs panel to reduce clutter. Kudpung กุดผึ้ง (talk) 02:07, 26 August 2022 (UTC)
Show purple icon for autopatrolled articles
NL, can you also use the same purple color in the toolbar, for autopatrolled articles. -MPGuy2824 (talk) 07:02, 14 September 2022 (UTC)
- Great idea. Ticket created for turning the Page Curation toolbar "marked as reviewed" checkmark purple if the article was autopatrolled. –Novem Linguae (talk) 07:13, 14 September 2022 (UTC)
AfD with invalid input
AFD through the page curation tool, if you enter invalid input (e.g. leave the text input empty) the form will still submit. MB 21:27, 14 July 2022 (UTC)
Deletion edit summary tag
When an article is marked for deletion using the Article for Deletion tag, PageTriage makes an edit to the article. The edit summary does not include the "afd" tag. MB 04:20, 15 July 2022 (UTC)
Make header and footer of Special:NewPagesFeed not float?
Any interest in this? It bugs me enough that I use a browser plugin to unfloat these, which sticks them back at the top and bottom. Screen real estate is valuable and I see these as a vice squeezing what I really want to look at: the article list. If others feel the same way, let me know and I can unfloat them. Pausing for consensus. –Novem Linguae (talk) 06:57, 23 July 2022 (UTC)
- Consider me interest in the top, but not the bottom. Because when the list expands I wont get to the bottom bar. Happy Editing--IAmChaos 21:25, 23 July 2022 (UTC)
- It's never bothered me in all these years and I have never even thought about it. I work either on a 27" iMac or a 13" MacBookPro and my screens are big enough for what I want to see. I would be surprised if any serious reviewer is using a device with a much smaller screen unless they are whiling their time away in a departure lounge or a doctor's waiting room. Nice, but I don't see it as a priority. If it's easy to do, go for it.
- That said, talking about screen real esate, the Curation tool is supposed to be 24-07-2022achable and resizable. It was certainly a main feature in the scope of the original project. If anyone thinks it would be helpful perhaps we should list it. Again, I'm fairly neutral. Kudpung กุดผึ้ง (talk) 07:13, 24 July 2022 (UTC)
- The screenshot above is on a pretty big screen, but I am using a high zoom. As you can see it only fits like 2 articles. –Novem Linguae (talk) 13:03, 16 August 2022 (UTC)
- Un-floating the top one would fix this bug that was reported today: phab:T315308 –Novem Linguae (talk) 13:02, 16 August 2022 (UTC)
- Sounds like a good idea, at least for the top. It's not a problem most of the time, but when I'm using my laptop it can be a pain—there's not enough room for the "set filters" button to appear unless I manipulate it a bit. If there's an easy fix, I at least would appreciate it! Extraordinary Writ (talk) 23:17, 16 August 2022 (UTC)
- It'd be easy to un-float, just need consensus. You might already know this, but in the meantime zooming out in your browser is a good workaround for the issue in your screenshot. –Novem Linguae (talk) 23:22, 16 August 2022 (UTC)
AFD not fully created
AFD through the page curation tool does not complete all steps. MB 21:27, 14 July 2022 (UTC)
AfD tagging behaving inconsistently
AFD through the page curation tool is erratic in several ways. MB 21:27, 14 July 2022 (UTC)
Page feed refresh button doesn't work
@MPGuy2824, I noticed this yesterday. I confirmed it today with a different computer/operating system/browser, so it appears to be the tool itself. I have to use reload the page to get a "refresh", the button does nothing. It changes color from grey to white for a very short time to show that it was clicked, but there is no action. MB 03:15, 15 October 2022 (UTC)
- Haven't used this ever, so let me verify the following:
- When do you remember this working last? The info might make it easier to debug.
- Also what did it do exactly? Update the feed without refreshing the page, I'd guess.
- -MPGuy2824 (talk) 03:45, 15 October 2022 (UTC)
- I can't remember exactly when it worked last, but probably a few days ago. I think this is recent. Yes, it removes refreshes the feed without an entire page reload. MB 04:25, 15 October 2022 (UTC)
- Confirmed that is working in the version from a week back. Created a phab ticket. -MPGuy2824 (talk) 05:54, 15 October 2022 (UTC)
- I can't remember exactly when it worked last, but probably a few days ago. I think this is recent. Yes, it removes refreshes the feed without an entire page reload. MB 04:25, 15 October 2022 (UTC)
Special:NewPages to not highlight pages if tagged for deletion, even if unreviewed.
Per this discussion, we are going to stop marking CSDs and PRODs as 'reviewed' in the new pages feed, to stop things falling through the cracks if the CSD tags are inappropriately removed or the PROD removal is missed. However, this presents a problem at Special:NewPages, which currently will highlight all 'unreviewed' or 'unpatrolled' pages in yellow, with no filtering feature like Special:NewPagesFeed. The simple fix is to un-highlight pages tagged for deletion, even if unreviewed. Ideally this should be added as a filtering option similar to the existing:
Show patrolled edits | Hide bots | Show redirects
buttons. An additional button that toggles "un-highlight tagged for deletion" (toggled on by default) would be ideal. — Insertcleverphrasehere (or here) 16:52, 4 November 2018 (UTC)
- I'll be archiving this since it is about Special:NewPages and a ticket has been filed. -MPGuy2824 (talk) 03:49, 24 November 2022 (UTC)
Provide related pages in the info panel to help catch forks
Following up from the discussion at Wikipedia talk:New pages patrol/Reviewers#Catching forks, I suggest that the related pages extension be used to display roughly three articles in the "Page Info" panel of the curation tool to help catch content forks and allow reviewers to better familiarize themselves with the context of an article's topic. {{u|Sdkb}} talk 06:08, 22 December 2020 (UTC)
- 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:21, 29 October 2022 (UTC)
Allow us to specify the topic of stub articles
There is only one tag available in the tool right now, which is
But, an option to specify would be quite neat, such as
When a stub is placed in a specific stub category, there is a greater chance for an expert to see and expand it. – 333-blue at 09:24, 21 June 2022 (UTC)
- Workaround: Use User:SD0001/StubSorter -MPGuy2824 (talk) 09:39, 21 June 2022 (UTC)
- Thanks. – 333-blue at 08:27, 29 June 2022 (UTC)
- 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:23, 29 October 2022 (UTC)
- Comment - There are hundreds, if not 1000s of different stub tags and guessing the right one is a hit-and-miss affair. This suggestion is not a priority, tagging for these missing elements should suffice. It's not within a reviewer's remit to do any of these things such as adding thematic stub tags, adding cats, adding short descriotion, or even adding the required BLP template or a project banner to the talk page. Kudpung กุดผึ้ง (talk) 11:22, 29 October 2022 (UTC)
"Go to next page in queue" bug
When I press the "Go to next page in queue" button while reviewing redirects it brings me to articles instead of my filtered queue.
Not sure when this change happened, but I believe in the last couple of weeks. I'd love for it to go back to progressing through my filtered queue instead of the default selection. Hey man im josh (talk) 15:18, 9 November 2022 (UTC)
- @Hey man im josh: I am unable to reproduce this issue when I follow the steps shown in the ticket. Please look at the ticket and correct the steps mentioned. If you aren't comfortable with Phabricator, then you can mention the correct steps here. -MPGuy2824 (talk) 08:51, 10 November 2022 (UTC)
- @MPGuy2824, I'm no longer experiencing this issue and I'm happy to report that the Page Curation bar is now working properly. I commented on the Phabricator task but I'm unable to close it (or I'm missing the button). Hey man im josh (talk) 14:01, 10 November 2022 (UTC)
- The button is hiding under "change status". All fixed :) –Novem Linguae (talk) 17:24, 10 November 2022 (UTC)
- @MPGuy2824, I'm no longer experiencing this issue and I'm happy to report that the Page Curation bar is now working properly. I commented on the Phabricator task but I'm unable to close it (or I'm missing the button). Hey man im josh (talk) 14:01, 10 November 2022 (UTC)
Redirects - issue 4
"Make "redirects" included by default in PageTriage" - This was suggested in phab:T42135 - essentially setting the default to "on" for the "Redirects" filter. Is this [still] wanted? Quiddity (WMF) (talk) 23:15, 5 October 2016 (UTC)
- @Quiddity: Well, that depends. There are issues with the way the new pages filter handles redirects. A brand new redirect should probably show up in New Pages to be patrolled (we want to catch people creating a redirect from insert bad word here to BLP). A former redirect that has been changed to an article should still show up, but it should be indexed by the date significant content was added, not the date the redirect was created. Redirects that have had a WP:RFD tag placed on them should not show up. ~ ONUnicorn(Talk|Contribs)problem solving 21:50, 6 October 2016 (UTC)
- @Quiddity: Yes, it's definitely wanted. All new redirects should pass through NPP. But it's note one of the high priority issues requiring urgent engineer attention. (For me personally, most of the suggestions on this page are urgent because we've been waiting 5 years for them, but I'm realistic in knowing only too well what a) lightens the load for both admins and patrollers, b) what more efficiently helps us to prevent and/or destroy serious cases of spam and trolling. Kudpung กุดผึ้ง (talk) 06:22, 9 October 2016 (UTC)
- This is still desirable, and using my old account I confirmed that the 'redirects' button is still unticked by default (It ticks the 'all others' button and the 'Nominated for Deletion' button, and includes both reviewed and unreviewed articles). — Insertcleverphrasehere (or here) 22:03, 16 October 2018 (UTC)
- Novem and I couldn't agree on whether this was a good idea to do. Since this is a 6 year old discussion, I started a new discussion at Wikipedia talk:New pages patrol/Reviewers#Proposal to change the default filters for fresh NPPers to gain a fresh consensus from the current NPPers. If any of you still feel strongly about this, please comment there. -MPGuy2824 (talk) 02:23, 29 October 2022 (UTC)
- Closed the ticket as declined as current consensus is against this. -MPGuy2824 (talk) 04:45, 18 November 2022 (UTC)
Special:NewPagesFeed autorefresh
Auto refresh. MusicAnimal, Kaldari (can this be implemented fairly quickly? It doesn't sound complicated.) The feed should auto refresh every 5 seconds like the other one does. This is the other main reason why so many patrollers won't move over to Page Curation. Whatever we encourage them to do, they will hover with their mouses over that feed ready to pounce as soon as they can add a deletion tag to a new article. The rest of the stuff, even low hanging fruit, they leave untouched. Suggestion: In the feed's user settings ('Set filters"), provide a choice of manual refreshing using the existing button, or auto refreshing. Then rename 'Set filters' to 'Preferences' (everyone on the Internet knows what preferences means). --Kudpung กุดผึ้ง (talk) 06:04, 9 October 2016 (UTC)
- @Kudpung: We originally decided to not auto-refresh the Special:NewPagesFeed interface for two reasons: First, it doesn't work that well with infinite scrolling. If you've loaded several pages worth of articles via infinite scrolling and then the list refreshes, you have to basically start over. Second, the Special:NewPagesFeed interface is geared more towards actual analysis of pages (via the snippets and metadata) than Special:NewPages, which is more tailored towards fast scanning. When you're actually reading the snippets and metadata to analyze a page, it's more disruptive to do an auto-refresh. However, both of these issues could be mitigated with a user preference as you suggest (for people that only want to patrol from the very top). 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] Are there any discussions or other evidence that people actually want such an option at Special:NewPagesFeed? Kaldari (talk) 04:43, 12 October 2016 (UTC)
- @Kaldari:. I understand. I also fully understand decision fatigue (I studied that on my PhD research for KommWiss}. So you're right about not offering too many choices - by contrast however, the Twinkle prefs panel is a minefield - have you seen it?. There are no discussions or other evidence that people actually want such an option, but my own research (unfortunately it's something that metrics can't prove) clearly demonstrates that people really enjoy hanging with their mouses over that real-time live feed gadget from User:Lupin/recent2.js, ready to pounce and tag. That's how I figured that however quickly I refresh the Special:NewPagesFeed, a very significant number of pages come through that are already tagged, and of course with various kinds of deletion tags, while none of them are simply 'patrolled' or tagged for minor issues. These people aren't even using Special:NewPages, which as you say, is more tailored towards fast scanning and is fine in the hands of really expert patrollers - but I'm an expert patroller and I think the Page Curation system with its Special:NewPagesFeed is one of the best things the WMF has come up with - ever. I wouldn't be able to recognise socks and corporae spammers without it.t
- So we have to wean people away from Special:NewPages, and that real-time gadget, and get them all singing from the same page, otherwise our endeavours at WP:NPPAFCwill be wasted even if we set a user right limitation for access to Page Curation. The only solution as I see it therefore, is to offer the Special:NewPagesFeed with the options: Refresh mode with infinite scrolling, and Real-time live feed (display 5 pages), refresh every 10 seconds. We can then deprecate that live feed, User:Lupin/recent2.js, in the side bar altogether, its creator hasn't edited Wikipedia for 9 years and we don't need a consensus to do it. Kudpung กุดผึ้ง (talk) 06:13, 12 October 2016 (UTC)
- An alternative is to do it like Twitter does, where after 5 seconds or so a banner will appear at the top saying "View 5 more tweets", etc. This is effectively the same as a live feed but won't be so obtrusive, and won't require an additional user option to turn it on/off (those who don't want it simply won't click on the banner). To take it a step further, automatically removing pages from the list that have already been patrolled seems like a lot of work and I suspect performance would be an issue. From my own experience I'm happy with manually refreshing, but I also usually work from the bottom of the backlog — MusikAnimal talk 23:36, 15 October 2016 (UTC)
- The effort is to understand that we must wean people away from their favourite gadgets and attract them to using Page Curation. There are many problems associate with technical conflicts that arise from using two systems. Working from the front of the queue is also important for catching certain types of editors while they are still online, espcially the drive-by SPA. Kudpung กุดผึ้ง (talk) 10:02, 16 October 2016 (UTC)
- So we have to wean people away from Special:NewPages, and that real-time gadget, and get them all singing from the same page, otherwise our endeavours at WP:NPPAFCwill be wasted even if we set a user right limitation for access to Page Curation. The only solution as I see it therefore, is to offer the Special:NewPagesFeed with the options: Refresh mode with infinite scrolling, and Real-time live feed (display 5 pages), refresh every 10 seconds. We can then deprecate that live feed, User:Lupin/recent2.js, in the side bar altogether, its creator hasn't edited Wikipedia for 9 years and we don't need a consensus to do it. Kudpung กุดผึ้ง (talk) 06:13, 12 October 2016 (UTC)
- An auto-refresh similar to the new Watchlist 'Live Updates' button would be extremely advantageous (without disrupting scrolling). — Insertcleverphrasehere (or here) 07:16, 19 October 2018 (UTC)
- Barkeep49, MusikAnimal, can you follow up at Phab and decipher what the actual status of this ticket is? If it's been shunted into a holding pen like they often quietly do, maybe it should be considered for the next Wishlist. I think it's extremely important to wean people away from using Twinkle to patroll pages. It's OK for people like DGG who knows what he is doing with the old feed, but he vast majority of reviewers do not have his experience. Kudpung กุดผึ้ง (talk) 03:51, 13 September 2019 (UTC)
- Kudpung, this was marked as medium-priority over our internal discussions and hence were not submitted to WMF. So, you ought not expect any work, at-least in this year. ∯WBGconverse 12:43, 13 September 2019 (UTC)
Update stub spacing in Page Curation tool
I noticed that the when Page Curation tool tags stubs, it only enters a single line before the tag (Special:Diff/1069309679 for example). WP:STUBSPACING says to leave two blank lines before the first stub tag (I'm guessing the curation tool only inserts the basic tag for others to sort). It looks like at least the User:SD0001/StubSorter script automatically insert the second blank line, but if someone sorts manually, it might leave only the single line. Can the tool be updated to add one more blank line before the {{stub}} tag? A bit of a nit, but seems like a low-hanging fruit update. -2pou (talk) 17:29, 1 February 2022 (UTC)
- @2pou:Thanks for posting this here. Unfortunately it takes months (sometimes years) of wrangling with the WMF to get minor issues like these addressed. Let's be thankful that it works at all and let's not worry about it too much. Maybe one of the more active patrollers will add it to this year's WMF 'wish list' in December. Kudpung กุดผึ้ง (talk) 03:55, 11 April 2022 (UTC)
- 2pou, Kudpung, I have been trying to find our why there should be two blank lines before a stub template. Wikipedia:Stub does not give a reason, and Wikipedia:Manual of Style/Layout does not even mention two blank lines. Do either of you know where it is explained? Cheers, · · · Peter Southwood (talk): 06:34, 7 August 2022 (UTC)
- Sorry, Peter, I'm the wrong person to ask. Best to ask the coords MB and Novem Linguae. Kudpung กุดผึ้ง (talk) 06:38, 7 August 2022 (UTC)
- Thanks, this already helps. · · · Peter Southwood (talk): 06:49, 7 August 2022 (UTC)
- Peter Southwood, I don't think the reason why can be answered by anyone at NPP. WP:STUB is the place. Perhaps Wikipedia talk:Stub/Archive 8#Spacing. I think it is just purely aesthetic - to separate article content from non-content. I do know that AWB genfixes follows this, so I think it is well accepted that two blanks lines is correct. MB 07:02, 7 August 2022 (UTC)
- MB, I asked there, and it seems that there is no actual functional reason, and no agreement that it is actually correct, necessary, or even really desirable, and could be superseded by bit of CSS. As I understand it, one blank line should be enough for any functional issues, (assuming that means pressing "enter" twice in Wikitext editor). See Two blank lines, again. Cheers, · · · Peter Southwood (talk): 15:02, 7 August 2022 (UTC)
- Peter Southwood, a reason has been given there. Unless there is a further change there, I think this Phab is valid. I also note that there is not much maintenance for AWB either, and if it becomes out-of-sync with current practice there will be no consistency. I think it is better to leave the long-standing double-space as the standard. MB 19:16, 7 August 2022 (UTC)
- MB, I asked there, and it seems that there is no actual functional reason, and no agreement that it is actually correct, necessary, or even really desirable, and could be superseded by bit of CSS. As I understand it, one blank line should be enough for any functional issues, (assuming that means pressing "enter" twice in Wikitext editor). See Two blank lines, again. Cheers, · · · Peter Southwood (talk): 15:02, 7 August 2022 (UTC)
- Peter Southwood, I don't think the reason why can be answered by anyone at NPP. WP:STUB is the place. Perhaps Wikipedia talk:Stub/Archive 8#Spacing. I think it is just purely aesthetic - to separate article content from non-content. I do know that AWB genfixes follows this, so I think it is well accepted that two blanks lines is correct. MB 07:02, 7 August 2022 (UTC)
- Thanks, this already helps. · · · Peter Southwood (talk): 06:49, 7 August 2022 (UTC)
- Sorry, Peter, I'm the wrong person to ask. Best to ask the coords MB and Novem Linguae. Kudpung กุดผึ้ง (talk) 06:38, 7 August 2022 (UTC)
- 2pou, Kudpung, I have been trying to find our why there should be two blank lines before a stub template. Wikipedia:Stub does not give a reason, and Wikipedia:Manual of Style/Layout does not even mention two blank lines. Do either of you know where it is explained? Cheers, · · · Peter Southwood (talk): 06:34, 7 August 2022 (UTC)
Can't send message to creator of an unreviewed article
The 'send message' option is not working. Neither to the creator nor to the user. Kudpung กุดผึ้ง (talk) 12:11, 18 October 2022 (UTC)
- Possibly related to phab:T204465, which recently deployed. @MPGuy2824, can you take a look when you get a chance? –Novem Linguae (talk) 00:59, 19 October 2022 (UTC)
- I've split the bug from the feature request below. I've submitted a patch which resolves the bug.
- I think the feature request will get some traction from other reviewers, it just needs to be clarified a bit. I'll reply to that when i get a chance. -MPGuy2824 (talk) 03:52, 19 October 2022 (UTC)
Changing redirect target should unreview redirect
Right now we only re-queue a redirect if it is flipped to an article. This is a security feature to prevent UPEs from hijacking the article. However someone wrote a patch for PageTriage to also unreview an article if the target is changed at all. Are we interested in this feature?
I'm leaning no. I think it could add a lot of work to the redirect queue. I'm open to being convinced though. cc Rosguill. –Novem Linguae (talk) 07:52, 4 November 2022 (UTC)
- Leaning no too. How many are there? My guess is that there are more redirect target changes every day than new redirects. There might be some value in putting them in a separate queue (a new type in the Feed filter menu) if someone wanted to systematically look at them (Redirect target reviewer?), but they are already tagged with "mw-changed-redirect-target" - so there is probably a way to do that already. I think this is straying too far from our mission. MB 15:19, 4 November 2022 (UTC)
- I struggle to see how this is within the remit of new page patrolling. Retargets surely constitute, if not a majority, then a significant chunk of edits to redirects? – Joe (talk) 15:36, 4 November 2022 (UTC)
- I agree. Best, Barkeep49 (talk) 16:56, 4 November 2022 (UTC)
- I would argue on the side of no as well. While there might be some maliciousness, if a non-autopatrolled user changes the target, then it would, I believe, be added to the queue, as I've seen that happen in my years of editing the back of the queue.Onel5969 TT me 18:43, 4 November 2022 (UTC)
- I think it's requeued for redirect to article, but not redirect target 1 to redirect target 2. –Novem Linguae (talk) 20:53, 4 November 2022 (UTC)
- The patch was abandoned on 7th November, following this community consensus. -MPGuy2824 (talk) 04:35, 18 November 2022 (UTC)
Curation tool marks pages with harv refs as uncited
Just a general comment, but the tool currently marks articles that use harv refs such as the {{Sfn}}
template as being uncited. Iazyges Consermonor Opus meum 15:46, 8 October 2021 (UTC)
Filters don't save
Whenever I open Special:NewPagesFeed, pages tagged for deletion are included by default in the queue. However, when I uncheck this option and refresh (purge) the page, or when I browse to another page and return later, the filters get restored to their initial configuration with such pages continuing to appear. I only noticed this within the last few days; was there a recent update that could be causing this bug? Complex/Rational 22:42, 11 November 2022 (UTC)
- Yes. It's probably phab:T322480. Sorry about that. Will try to fix soon. –Novem Linguae (talk) 00:16, 12 November 2022 (UTC)
Fix large screen New Pages Feed display to save space
There is a lot of wasted space on the new pages feed. When viewed very zoomed in, it is fine (I guess), and makes use of each line on the left due to test that wraps around. When zoomed out however, it fails to remove this extra line of space, and simply makes each box bigger than it needs to be. The three images at right indicate the problem best. the final one indicates how the feed could be modified to show more items per page. This would be helpful because it would make it easier to see repeated submissions from the same users, and allow scanning a larger number of pages at the same time. — Insertcleverphrasehere (or here) 21:39, 8 November 2018 (UTC)
- Support anything that makes scanning easier. Some people go through one at a time systematically,andthe tool seems to have them principally in mind, but I know I'm not the only frequent patroller who works by scanning ay one time as large a set at I can. DGG ( talk ) 04:47, 14 September 2019 (UTC)
- Support this is a small incremental fix that should be uncontroversial, and probably not so hard to implement? MarioGom (talk) 12:45, 14 November 2021 (UTC)
Rcats (adding redirect categories)
MB recently posted:
Here is something that seems inconsistent. When reviewing/patrolling redirects, I use the curation tool. If I want to add a Rcat (and its one Twinkle knows about), I click on the Tag/Twinkle tab. I add the Rcat and mark it reviewed at the same time by clicking those two choices, then hit "Submit Query" one time (done in four clicks). If the redirect is auto-created from a page move, it already has a Rcat (R from move). If I go to Twinkle to add a second Rcat, there is no choice to mark it reviewed, so I have to go back to the curation tool and review it there (two steps, five clicks total). Not a big deal, I can still move pretty fast. But still, why is the option to review these redirects missing? It seems to be related to the move.
I have tried to replicate it but I don't know where the 'move' situation fits in. However, I do think that Rcat tagging from Page Curation should be possible as the same feature in Twinkle and it's a feature we missed when we designed the tool. Maybe it wasn't even a feature in Twinkle in those days because I didn't know about it and I've always added Rcats manually. Again, this would keep all the PageTriage options in one place to avoid dashing back and forth between Page Curatin and Twinkle, which was the original purpose for the design of the Curation tool in the first place. Kudpung กุดผึ้ง (talk) 05:46, 28 August 2022 (UTC)
- @MB: there are a huge number of Rcats at Twinkle; about a hundred. It would be a major pain to scroll through all of these to get to the one/s you want to add. Maybe we can narrow it down to the most used 10-15 and add those? -MPGuy2824 (talk) 07:09, 9 November 2022 (UTC)
- I don't think so. IMO, this wouldn't be worth implementing if it didn't contain everything in Twinkle. Even Twinkle is missing some, I wish Twinkle had them all since it is quite a bother to go find one that is not in the menu and add it manually. As far as scrolling, I personally never do that in Twinkle. By using the filter box, I narrow the choices so the one I want is always visible without scrolling. There was some discussion with the WMF about "plugging in" Twinkle modules so some things didn't have to be rewritten and separately maintained. This seems like a perfect candidate for that, even if we can't get it right away. @Novem Linguae ? MB 01:15, 10 November 2022 (UTC)
- Yeap, worth thinking about either copying the list of templates that Twinkle has (and Twinkle's awesome type-to-filter box), or figuring out a way to plug in Twinkle directly for certain modules. It's a big job though. The kind of thing we'd want the WMF to help with. –Novem Linguae (talk) 01:59, 10 November 2022 (UTC)
- I don't think so. IMO, this wouldn't be worth implementing if it didn't contain everything in Twinkle. Even Twinkle is missing some, I wish Twinkle had them all since it is quite a bother to go find one that is not in the menu and add it manually. As far as scrolling, I personally never do that in Twinkle. By using the filter box, I narrow the choices so the one I want is always visible without scrolling. There was some discussion with the WMF about "plugging in" Twinkle modules so some things didn't have to be rewritten and separately maintained. This seems like a perfect candidate for that, even if we can't get it right away. @Novem Linguae ? MB 01:15, 10 November 2022 (UTC)
Message punctuation
See report at Wikipedia:Village_pump_(technical)#Feedback_from_New_Page_Review_Process about extra punctuation in messages. MB 04:19, 11 December 2022 (UTC)
- Software patch written. Give it around 2 weeks to get deployed. –Novem Linguae (talk) 08:00, 11 December 2022 (UTC)
- This change was on enwiki last Friday. -MPGuy2824 (talk) 09:19, 20 December 2022 (UTC)
Button size on tablets
Improve button size/spacing for ease of use on touch screens. MB 21:37, 14 July 2022 (UTC)
- @MB: Would you elaborate a bit please? -MPGuy2824 (talk) 14:55, 1 December 2022 (UTC)
- I just added this after NL opened Phab:T313094, but I forgot to link the phab here. Looks like this was fixed. MB 15:50, 1 December 2022 (UTC)
- You had linked the phab ticket, but I removed it, since internally it was linked to phab:T313651, which didn't seem related. Anyway, it looks like you aren't facing this problem. I'll archive this section then, after a week. -MPGuy2824 (talk) 02:28, 2 December 2022 (UTC)
- I just added this after NL opened Phab:T313094, but I forgot to link the phab here. Looks like this was fixed. MB 15:50, 1 December 2022 (UTC)
New Page feed filtered article count off
When I have no filters set, the number of filtered articles does not match the total number of unreviewed articles as listed in the footer. It is off for me by around 100. I asked Barkeep49 what they saw, and then initially said their numbers matched but later it was off by 1. MB 00:10, 8 June 2022 (UTC)
- MB, the stats in the footer of NewPagesFeed are cached for 10 minutes, while the filtered pages number, at the top, is more live. -MPGuy2824 (talk) 03:21, 20 September 2022 (UTC)
- That's interesting. Everyone I asked about this thought the number in the footer was "correct" and the filtered number probably wasn't calculated correctly. MB 03:50, 20 September 2022 (UTC)
- MB, given this, is it OK to close the ticket? -MPGuy2824 (talk) 07:10, 28 September 2022 (UTC)
- @MPGuy2824, I don't think a 10 minute caching explains this. I just checked the numbers over 40 minutes (kept reloading the page periodically) and I saw (footer#/filtered number) 6230/6259, 6256/6222, 6252/6222, 6252/6221, 6250/6219. The numbers never matched or nearly matched, always around 30 off.
- I looked at the phab you linked, phab:T205741, and that seems to account for this. It says that the query for the number in the footer does not include "ptrp_reviewed" (I don't really know which articles are missing, but apparently around 30 right now). I guess this can be closed as a duplicate.
- NL, there is a note in there from 2018 saying this would be a candidate to fix
as part of a larger refactoring of backend or frontend code.
Is that another opaque reference to a "rewrite"? MB 21:15, 28 September 2022 (UTC)- Hmm, depends. I usually think of a rewrite as more extensive than a refactor. A rewrite can change features, change appearance, etc. A refactor usually just reorganizes code under the hood without changing features or appearance.
- As for this ticket, I'd be in favor of making the numbers match if it is as easy as just tweaking an SQL query and it has no side effects. –Novem Linguae (talk) 21:54, 28 September 2022 (UTC)
- MB, given this, is it OK to close the ticket? -MPGuy2824 (talk) 07:10, 28 September 2022 (UTC)
- That's interesting. Everyone I asked about this thought the number in the footer was "correct" and the filtered number probably wasn't calculated correctly. MB 03:50, 20 September 2022 (UTC)
AfD Bug?
After an AfD is created, if the template is removed from the article (which enraged creators sometimes do), it ceases to display in the feed with the trash can icon. Kudpung กุดผึ้ง (talk) 13:09, 23 October 2022 (UTC)
- This is by design. There is no easy way for the software to distinguish between an irate creator/sockpuppet removing an AfD tag v/s a legitimate removal after a properly closed AfD. In any case, there is a bot (Cyberbot I) which re-adds AfD templates (example) where the discussion isn't closed yet. After this happens, the article should again display in the feed with the trash can icon. -MPGuy2824 (talk) 09:48, 26 October 2022 (UTC)
Request
Hey, hardworking patrollers,
I have a request to make but I'm not sure how easily it can be implemented. I just deleted a draft that has been recreated multiple times by sockpuppets. In fact, page creation had been prevented by having the draft page have extended confirmed protection on it. However, a well-meaning patroller moved the draft from a sandbox to the draft page. And so it needed to be deleted again, for the 4th or 5th time. And given the requirements to be a patroller, they were extended confirmed so they could move it easily to this protected page. Is there any way, you coud check the destination page where you are planning to move a User space draft and make sure it isn't create protected? Or could your page curation tools send up a warning notice when you are moving a page that the destination page is protected? This doesn't happen a lot but it does happen. Thanks! Liz Read! Talk! 07:31, 6 November 2022 (UTC)
- Thanks for the idea. This may be a bit too uncommon to add it as a feature. Seems like it might also be out of the scope of PageTriage, which is primarily for reviewing new pages, not necessarily listening to all moves and detecting moves to salted drafts. Although I'm happy to hear other opinions. –Novem Linguae (talk) 07:49, 6 November 2022 (UTC)
- I've come across the same issues myself but not while patrolling. Much as I'm in favour of creating as many features as possible for streamlining the work at NPP, I do feel this is rare and somewhat out of scope. Kudpung กุดผึ้ง (talk) 11:39, 6 November 2022 (UTC)
Any edit that changes a number or numbers without an edit summary should be flagged "r" in the watchlist
This is an extremely common form of vandalism. There is never a reason to change numbers without leaving an edit summary. I suggested this at Help talk:Watchlist also and if there is a more appropriate place for it please let me know. —DIYeditor (talk) 18:35, 29 April 2023 (UTC)
I've started a discussion at WP:Village pump (technical)#Numerical changes without edit summary should be flagged "r" in watchlist. —DIYeditor (talk) 19:22, 29 April 2023 (UTC)
- Hey there. This particular page is for suggesting changes to Special:NewPagesFeed and the Page Curation toolbar, so this probably isn't the best page. I'll go ahead and comment at your Village Pump thread. –Novem Linguae (talk) 22:36, 29 April 2023 (UTC)
G8 (CSD)
I think that G8 - Pages dependent on a non-existent or deleted page - should be added to the Speedy Ddletion part of the Mark for deletion section of the tool, as it is a redirect-related deletion tag which is used often. greyzxq talk 20:56, 23 May 2023 (UTC)
- Done The G8 tag is available at the bottom of the CSD list in the toolbar (after the other two redirect CSD tags). -MPGuy2824 (talk) 03:06, 19 June 2023 (UTC)
Remove userspace from Special:NewPagesFeed?
Does anybody use Special:NewPagesFeed to patrol userspace? Are we even supposed to patrol userspace? I propose removing it. Benefits:
- Decrease the maintenance burden (for example, there's some ancient MFD code that I have no idea if works or not)
- Discourage NPPs from using valuable patrol time to patrol a namespace that we don't normally patrol
- Shrink the size of some PageTriage SQL tables
Effects:
- Would remove the page curation toolbar from userspace pages (instead there would be a "Mark this page as patrolled" link at the bottom right of the page)
- Would remove "In namespace: User" from the list of filters in Special:NewPagesFeed.
Thoughts? –Novem Linguae (talk) 23:56, 25 August 2022 (UTC)
- From the tutorial:
Namespaces subject to review – Mainspace and userspace are the two namespaces where the page curation toolbar displays. NPPs do not need to patrol userspace
. Maybe User:Kudpung knows why userspace was added to the NewPagesFeed's purview, and if it is needed anymore. -MPGuy2824 (talk) 01:33, 26 August 2022 (UTC)- @Novem Linguae and MPGuy2824: I do not know, nor do I recall why this is - although I created the user right and was directly involved in the creation of the prefs panel and the major author of the tutorial, it's too long ago. I guess that it was probably because user pages and user subpages are sometimes used against policy. Is there a query that could be run that would reveal how often/how many reviewers patrol the user pages? As it is nevertheless only an option in the filter preferences at Special:NewPagesFeed, unless the purely technical reasons mentioned by NL are truly compelling I would be inclined to leave it as it is rather than create yet another ticket in Phab. Kudpung กุดผึ้ง (talk) 01:52, 26 August 2022 (UTC)
- Here's a count of # of userspace patrols per month. Averages out to 118. Many of these may not be methodical patrolling, but rather NPPs marking userpages as reviewed as they randomly stumble on them. –Novem Linguae (talk) 02:19, 26 August 2022 (UTC)
- Query:[5] mostly patrols, but some curation as well. -MPGuy2824 (talk) 02:28, 26 August 2022 (UTC)
NPPs do not need to patrol userspace.
I think I added that recently to reflect reality. I posted about it at WT:NPPR one time and I think people responded that we shouldn't spend our time patrolling userspace. –Novem Linguae (talk) 02:08, 26 August 2022 (UTC)- Maybe I'm naïve but I still fail to understand the technical difference in the 'review' and 'patrol' user logs. As far as I know, we're only concerned with the use of PageTriage, for which the user log is 'Page Curation'. Kudpung กุดผึ้ง (talk) 02:44, 26 August 2022 (UTC)
- Doesn't patrolled also include those pages by autopatrolled users who are not part of NPP? Atsme 💬 📧 11:44, 27 August 2022 (UTC)
- It's not 100% clear to me either. But my understanding is "patrol" is 1) people who click the "Mark this page as patrolled" link at the bottom right of non-mainspace, non-userspace pages, and 2) most but not all of PageTriage "mark as reviewed" button presses, because PageTriage usually marks in both logs, but not 100% consistently. In general, we almost always want to check the Page Curation Log instead of the Patrol Log. Hope that helps. –Novem Linguae (talk) 13:09, 27 August 2022 (UTC)
- I think we are agreed that as far as NPP is concerned, 'Page Curation log' is authoritive ifnot 100% accurate. It's the one that NPP coords need to know. Looking again at 'Effects' above, the curation toolbar is only seen by accredited reviewers (or should be) , and maybe occasionally a reviewer might want to make a random stab at "In namespace: User" so personally I think it might as well be left as it is. Kudpung กุดผึ้ง (talk) 15:13, 27 August 2022 (UTC)
- In Twinkle, pressing "Mark this page patrolled/reviewed" also seems to update both. MB 03:13, 28 August 2022 (UTC)
- I think we are agreed that as far as NPP is concerned, 'Page Curation log' is authoritive ifnot 100% accurate. It's the one that NPP coords need to know. Looking again at 'Effects' above, the curation toolbar is only seen by accredited reviewers (or should be) , and maybe occasionally a reviewer might want to make a random stab at "In namespace: User" so personally I think it might as well be left as it is. Kudpung กุดผึ้ง (talk) 15:13, 27 August 2022 (UTC)
- It's not 100% clear to me either. But my understanding is "patrol" is 1) people who click the "Mark this page as patrolled" link at the bottom right of non-mainspace, non-userspace pages, and 2) most but not all of PageTriage "mark as reviewed" button presses, because PageTriage usually marks in both logs, but not 100% consistently. In general, we almost always want to check the Page Curation Log instead of the Patrol Log. Hope that helps. –Novem Linguae (talk) 13:09, 27 August 2022 (UTC)
- Doesn't patrolled also include those pages by autopatrolled users who are not part of NPP? Atsme 💬 📧 11:44, 27 August 2022 (UTC)
- Maybe I'm naïve but I still fail to understand the technical difference in the 'review' and 'patrol' user logs. As far as I know, we're only concerned with the use of PageTriage, for which the user log is 'Page Curation'. Kudpung กุดผึ้ง (talk) 02:44, 26 August 2022 (UTC)
- @Novem Linguae and MPGuy2824: I do not know, nor do I recall why this is - although I created the user right and was directly involved in the creation of the prefs panel and the major author of the tutorial, it's too long ago. I guess that it was probably because user pages and user subpages are sometimes used against policy. Is there a query that could be run that would reveal how often/how many reviewers patrol the user pages? As it is nevertheless only an option in the filter preferences at Special:NewPagesFeed, unless the purely technical reasons mentioned by NL are truly compelling I would be inclined to leave it as it is rather than create yet another ticket in Phab. Kudpung กุดผึ้ง (talk) 01:52, 26 August 2022 (UTC)
- Support - If NPP is instructed not to bother patrolling the userspace, and no one actively does so, then why bother keeping it? It's an unnecessary backlog. Hey man im josh (talk) 15:02, 7 October 2022 (UTC)
- Would this be technically easy to implement? Nobody is actually using Special:NewPagesFeed to monitor userspace, I'm reasonably certain; I just mark userpages as reviewed when I happen to encounter them. So it's not hurting anything, and unless it would be an easy deployment, I don't see reason to waste what little technical support we get on implementing this. —Compassionate727 (T·C) 18:14, 7 October 2022 (UTC)
- The advantage would be time saved by reviewers because it'd be clearer they don't need to patrol that namespace. –Novem Linguae (talk) 14:17, 8 October 2022 (UTC)
- Support - A small change, but a reasonable one. ASUKITE 17:10, 13 October 2022 (UTC)
- Support - Before the PageTriage software was created, no one patrolled user pages anyway. Why should they now? Kudpung กุดผึ้ง (talk) 11:37, 29 October 2022 (UTC)
- I have used this before for:
- Dreamy Jazz talk to me | my contributions 22:21, 20 February 2023 (UTC)
- @Dreamy Jazz. Thanks for your comment. If we do end up removing this (probably will eventually unless consensus changes), the uglier Special:NewPages will still allow seeing a list of recent new userpages. And a [Mark this page as patrolled] link will appear at the bottom right of user pages. Hope this helps. –Novem Linguae (talk) 00:17, 21 February 2023 (UTC)
- Yeah. I would note that for the first that page would work and for the second a search using Special:Search performed on the user namespace usually covers what I look for. That means this isn't necessarily a loss in functionality for me. Dreamy Jazz talk to me | my contributions 00:38, 21 February 2023 (UTC)
- @Dreamy Jazz. Thanks for your comment. If we do end up removing this (probably will eventually unless consensus changes), the uglier Special:NewPages will still allow seeing a list of recent new userpages. And a [Mark this page as patrolled] link will appear at the bottom right of user pages. Hope this helps. –Novem Linguae (talk) 00:17, 21 February 2023 (UTC)
Extend NOINDEX beyond 90 days
Mainspace articles should be NOINDEXED until reviewed per 2012 RFC. See Phab ticket for links to related discussions. MB 23:04, 19 June 2022 (UTC)
- MB, as I warned, this might not be easy to convince the devs. History has demonstrated that they often see themselves as the gatekeepers of all the local projects or they don't understand the priorities. Your best ally there is MusikAnimal, at least he knows what it is to be a Wikipedia editor and he's an excellent technician. Kudpung กุดผึ้ง (talk) 10:08, 20 June 2022 (UTC)
- I see you have commented on the ticket, so you saw that Novem_Linguae added MuskikAnimal as a subscriber. I see you have added yourself too. Thanks. MB 13:30, 20 June 2022 (UTC)
- You guys are moving a bit faster than I was planning. A 10 year old consensus, no recent village pump discussion yet, the # of days not firmly decided, and unanswered technical questions I was still asking MA about. Could be a bumpy ride. We'll see how it goes. –Novem Linguae (talk) 17:16, 20 June 2022 (UTC)
- I have answered your question to the best of my ability. The folks servicing site requests are probably not super experienced with PageTriage and any side effects, they just want to see clear consensus. Please assume good faith. Since this effects all articles created by non-autopatrolled users, I feel like we could use at least a "see this discussion" kind of notice at WP:VPT. A year is kind of a long ṫime… I know NPP is backed up, but maybe let's try a shorter duration first, such as
three orsix months? Assuming many NPPers work from the end of the queue, if that much time goes by and no one has marked it an article as reviewed, that might suggest it's one of those really 'tricky' ones. If enough eyes still can't make a decision, perhaps it's not too farfetched to assume the article is worthy of inclusion? - I am fairly confident that a 365 day hold on indexing will have no technical issue, but the social impact is worth giving thought to. I've seen first hand how many go to WP:VPT to ask about why their article isn't being indexed. Do we really want to keep them waiting for up to a year?
- As an aside, I did see this request with regards to the top new article reviewers report, and hope to work on it soon. — MusikAnimal talk 22:06, 20 June 2022 (UTC)
- Thanks for the answers.
I know NPP is backed up, but maybe let's try a shorter duration first, such as three or six months?
Quick FYI, both enwiki __NOINDEX__ (per the documentation) and enwiki PageTriage $wgPageTriageMaxAge durations are currently set to 90 days. I assume they are separate settings. –Novem Linguae (talk) 11:57, 21 June 2022 (UTC)- I figured it was something specific to enwiki, as I could not find anything about automatic indexing on mediawiki.org (but the docs could also be incomplete, something not unusual for mediawiki.org!). Anyway, my reading of the code suggests PageTriage acts completely independently. There is some logic to respect a __NOINDEX__ if it is present on a page, but even then it still checks against $wgPageTriageMaxAge in determining whether to noindex the page, so there should be no concern here.
- Did someone want to advertise this at WP:VPT? MB perhaps? I suggest making a concrete proposal for the number of days, starting with a smaller value (180 days, perhaps). I think 180 days would be safer -- both in terms of social and potential technical impact. We can always increase it later if need be. I do not think we should jump straight to indefinite even if possible, and certainly not without broader input. — MusikAnimal talk 14:49, 21 June 2022 (UTC)
- A follow-up NPP discussion rejected extending the period from 90 to 180 or 365 days and was clearly in favor of indefinite. Additional feedback was solicited from WP:VPP and in two days there were no comments. MB 05:05, 26 June 2022 (UTC)
- Thanks for the answers.
- I have answered your question to the best of my ability. The folks servicing site requests are probably not super experienced with PageTriage and any side effects, they just want to see clear consensus. Please assume good faith. Since this effects all articles created by non-autopatrolled users, I feel like we could use at least a "see this discussion" kind of notice at WP:VPT. A year is kind of a long ṫime… I know NPP is backed up, but maybe let's try a shorter duration first, such as
- You guys are moving a bit faster than I was planning. A 10 year old consensus, no recent village pump discussion yet, the # of days not firmly decided, and unanswered technical questions I was still asking MA about. Could be a bumpy ride. We'll see how it goes. –Novem Linguae (talk) 17:16, 20 June 2022 (UTC)
- I see you have commented on the ticket, so you saw that Novem_Linguae added MuskikAnimal as a subscriber. I see you have added yourself too. Thanks. MB 13:30, 20 June 2022 (UTC)
Declined Noting that this task has been declined. -- Sohom (talk) 09:00, 12 November 2023 (UTC)
Redirect category shells
I remember the Page Curation Tool adding rcat shells when you add an rcat to a redirect, but recently I've noticed it no longer adds them. Is this intentional or not. If it is intentional, is there any reason why? And if it's unintentional, can it be added back? greyzxq talk 21:35, 28 October 2023 (UTC)
- This is a bug. Will be fixed. -MPGuy2824 (talk) 05:56, 29 October 2023 (UTC)
Expand language
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
(Brought here from reviewers talk page) As suggested by Bada Kaji - Could we include an option on the Page Curation toolbar to add the tag Expand (language), give us a list of the most common languages translated from and a space to add the foreign language title(s)? I am noticing more pages needing this template lately. Thank you JW 1961 Talk 22:47, 14 November 2021 (UTC)
- Yes, this feature would be great. Bada Kaji (talk • श्रीमान् गम्भीर) 13:23, 15 November 2021 (UTC)
- What is the name of the template that you want added? There is already an "Expand Language" tag that is available in the toolbar. -MPGuy2824 (talk) 03:55, 24 November 2022 (UTC)
- Template:Expand language should usually not be placed on article pages directly. Instead, language-specific templates from Category:Expand by language Wikipedia templates are preferred if only one language is linked. There are nearly 200 languages in that category to choose from.
- Note that placing a naked {{expand language}} on an article is an error –
- click
[show]
on the template to see the Error: No language code specified {{error}} message.
- click
- Also the Curation Toolbar let me check the box for "Expand language" on both the "All tags" and the "More tags" forms, and when I did that, it posted the identical template twice. – wbm1058 (talk) 13:49, 2 September 2023 (UTC)
- Done This specific issue has been resolved. Sohom (talk) 21:12, 21 November 2023 (UTC)