Wikipedia talk:New pages patrol/Reviewers: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 13:27, 26 October 2018

Tutorial

Discussion

New page feed

Reviewers

Curation tool
Suggestions

Coordination

Backlog drives

NPP backlog

Articles: 11279 ↑81
Oldest article: 3 years old
Redirects: 34450
Oldest redirect: 5 months old
Article reviews: 1398
Redirect reviews: 2191

There is a very large articles backlog
The articles backlog is growing very rapidly (↑1097 since last week)
There is a very large redirects backlog

Shortcut

WT:NPP/R

Tip: When you see a page that appears to be obviously a commissioned work, take a moment to check the history. If it's a recreation of a page that has previously been deleted three or more times, please add the {{salt}} tag below the CSD tag to request that the responding administrator SALT the article. In addition, consider adding a note to the talk page requesting a block of the account per WP:SPAM. For more information please see this section and if you are still in doubt, don't hesitate to post a question here.

NPP Backlog edit

Archives

1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22, 23, 24, 25, 26, 27, 28, 29, 30
31, 32, 33, 34, 35, 36, 37, 38, 39, 40
41, 42, 43, 44, 45, 46, 47, 48, 49, 50
51

This page has archives. Sections older than 21 days may be automatically archived by when more than 5 sections are present.

Archives of

Page Curation: 1, 2, 3, 4. 5, 6, 7, 8, 9

This page has archives. Sections older than 21 days may be automatically archived by when more than 5 sections are present.

Error/issues?

In page curation, I'm unable to scroll past the first 20 new pages, I've tried this while logged out, logged in, IE, Chrome, Firefox, Safari and on my phone. Same issue. Am I the only one experiencing it? CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 15:21, 25 August 2018 (UTC)[reply]

The new pages feed works for me on Firefox 61.0.2, Safari 11.1.2, Chrome 68.0.3440.106 on Mac OSX 10.13.6, and Safari on iOS 11.4.1. It doesn't work on Tor Browser 7.5.6, where it shows "This extension requires a JavaScript enabled browser" and in mobile mode on my phone (https://en.m.wikipedia.org/wiki/Special:NewPagesFeed) where is just shows "Please wait..." Vexations (talk) 16:10, 25 August 2018 (UTC)[reply]

@Chrissymad: thanks for posting this. the team is looking into it now and seeing if we can reproduce the issue. Other reviewers, please let us know if you are seeing the issue. We will give an update tomorrow. — MMiller (WMF) (talk) 18:40, 25 August 2018 (UTC)[reply]

I'm able to scroll past when it sorted by newest but not oldest Galobtter (pingó mió) 18:47, 25 August 2018 (UTC)[reply]

Same for me. I have also been having an occasional error in the last day where I am unable to click the next button on certain pages. screenshot Best, Barkeep49 (talk) 18:55, 25 August 2018 (UTC)[reply]

It's working fine for me today. Natureium (talk) 18:50, 25 August 2018 (UTC)[reply]

Actually, there's a problem for me too that I didn't notice at earlier. If I sort by oldest first, two things happen: scrolling breaks and in the curation tool, the next button stops working before I reach the end of the unreviewed queue. --Vexations (talk) 19:34, 25 August 2018 (UTC)[reply]

I have the same problem. I can scroll by newest but not oldest. AmericanAir88^(talk) 15:38, 26 August 2018 (UTC)[reply]

Something is definitely off. Even when sorting by newest, scrolling stops working at about two days worth of logs. I can get to 20:39, 24 August 2018 (BlackBoxTV) Vexations (talk) 18:39, 26 August 2018 (UTC)[reply]

Hi all -- thank you for your patience. One of our team's engineers is working on this today, and we are tracking the work in T202815. It would be helpful if you can post with your browser, exact filter and sort settings, the number indicated in the top right of the list (e.g. "2872 pages in your filtered list"), and the exact behavior you're seeing (e.g. "I can scroll twice, but it stops."). I will be back with another update later today or tomorrow morning. Chrissymad, Vexations, Galobtter, Barkeep49, Natureium, AmericanAir88. -- MMiller (WMF) (talk) 19:52, 26 August 2018 (UTC)[reply]

MMiller (WMF) I took a screenshot of the dev tools errors when it happened. Will it help to post that to the phab ticket? CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 11:38, 27 August 2018 (UTC)[reply]

I noticed today that when patrolling from the front, the tool works as usual, but when patrolling from the oldest end, I was only shown one article. Natureium (talk) 15:11, 27 August 2018 (UTC)[reply]

Hi everyone -- our team pushed out a fix this morning, and we believe that the feed should be scrolling again as normal. Please refresh the page and let us know if this is not the case. Thank you for patiently specifying what you were seeing; it helped our engineers diagnose what was wrong. We had been doing some backend performance improvements so that the feed will continue to load quickly even as we add more data (AfC, ORES, and copyvio). Those changes inadvertently caused the scrolling issues, so we rolled back that change for now. When we fix the patch and add it back in, we'll be adding some more instrumentation so we can see more clearly the source of any performance issues. Thank you to Chrissymad, Vexations, Galobtter, Barkeep49, Natureium, AmericanAir88. -- MMiller (WMF) (talk) 20:53, 27 August 2018 (UTC)[reply]

@MMiller (WMF): Is indeed now working for me. Best, Barkeep49 (talk) 21:31, 27 August 2018 (UTC)[reply]

I was able to scroll though the entire queue both from Newest and Oldest without any problems. Thanks for the fix MMiller (WMF) and team. Vexations (talk) 21:49, 27 August 2018 (UTC)[reply]

New Issue?

Periodically throughout today, and again only when viewing articles from the oldest end of the NPP queue, the curation toolbar will not appear for unpatrolled articles. Sometimes refreshing or purging the page brings it back but sometimes not. Again it's working fine from the new side. Best, Barkeep49 (talk) 20:22, 29 August 2018 (UTC)[reply]

@Barkeep49: thanks for bringing this up. We're looking into it now. In the meantime -- are any other reviewers seeing this? Let me know. -- MMiller (WMF) (talk) 23:46, 29 August 2018 (UTC)[reply]

I haven't noticed the issue that Barkeep49 describes, but I also haven't been doing reviews from the back of the queue. I did notice that when I bring up [[Special:NewPagesFeed, it is not current and I need to click Refresh list. Could that be related? --Vexations (talk) 00:31, 30 August 2018 (UTC)[reply]

@MMiller (WMF): More details. This only seems to happen when going from Special:NewPagesFeed. If I advance to the next article using the curation toolbar itself it has yet to disappear on me. It also seems, but I have only replicated twice so I wouldn't say with confidence that it's true and not just luck, but if I go to a page with the toolbar and then go back to a page that was not displaying the toolbar, the toolbar then appears for me. Best, Barkeep49 (talk) 17:11, 30 August 2018 (UTC)[reply]

@Barkeep49: thanks for the details. I have a few follow-up questions from the engineers on the team:

Could you provide links to two or three articles that this is happening on?
When the toolbar doesn't load for a page, do you see the link for "Curate this article" under the Tools menu in the left navigation menu?
And if you click on that "Curate this article" link, does the toolbar load then?

Thank you. -- MMiller (WMF) (talk) 00:00, 31 August 2018 (UTC)[reply]

@MMiller (WMF): It just happened for me on Española Way and Zurmat. Clicking the curate this page resolved both times. Best, Barkeep49 (talk) 16:24, 31 August 2018 (UTC)[reply]

MMiller (WMF), in response to what you asked, yes it’s the same or similar issue and it’s erratic. I just pulled up Great Public Schools from the queue - curation bar appeared, I left the article page to check article history, saw a former redirect, so I brought up that page from article history and when I returned to the current article, the curation bar was missing. It returned after I left the page, came here to type this message, clicked on the wikilink I added here, and the curation bar appeared on that article again. I had similar occurrences with a few other articles yesterday. The majority of disappearances occurred when I left the article, but 2 occurred right from the queue. ^{Atsme✍🏻📧} 03:28, 22 September 2018 (UTC)[reply]

Atsme and Barkeep49 -- just wanted to give you an update that the fix is written and code reviewed, and that it will deploy to English Wikipedia a week from today. I'll get back in touch at that time to check in on whether it has, in fact, fixed the issue for you. Thanks for your patience. -- MMiller (WMF) (talk) 16:39, 27 September 2018 (UTC)[reply]

Thank YOU for staying on top of this, MMiller - it is much appreciated. ^{Atsme✍🏻📧} 16:56, 27 September 2018 (UTC)[reply]

Atsme and Barkeep49 -- we think this issue is fixed now. Please let me know if you are still seeing it! -- MMiller (WMF) (talk) 19:55, 5 October 2018 (UTC)[reply]

So far, so good with that particular issue, MMiller (WMF). But...see the following from yesterday - began with an article in the queue because of a redirect - User talk:Lee Vilenski#A page you started (2019 World Seniors Championship) has been reviewed!. The notice went to the editor who created the 1st redirect rather than the article creator. I'm thinking it might be better to give the reviewer the choice of whom to notify if they want to notify anyone at all considering some end-up going to blocked users/socks/t-banned editors, etc. ^{Atsme✍🏻📧} 22:38, 5 October 2018 (UTC)[reply]

@Atsme: thanks for posting. Do you remember if that is behavior that you've always seen, and you wish were different? Or if it seems to be a new thing that didn't used to happen? -- MMiller (WMF) (talk) 00:10, 10 October 2018 (UTC)[reply]

@MMiller (WMF): I haven't really patrolled today but was at E. K. Johnston and did not have the curation bar pop up twice and had to do so manually (it did the third time I visited). Best, Barkeep49 (talk) 03:21, 6 October 2018 (UTC)[reply]

@Barkeep49: I'm sorry you're still seeing the issue. That's definitely frustrating. We've created this task to track things as we look into it, because we're hearing some similar things from a few other editors. Does logging out and back in fix it at all? -- MMiller (WMF) (talk) 00:10, 10 October 2018 (UTC)[reply]

MMiller (WMF), it was the first time I’ve had the notice go to the editor who created the redirect but it could be an old issue. I recall some discussion in the recent past about notifications going to blocked users, etc. but can’t remember the details. I have a vague recollection of Kudpung either saying we had the option to send or not send notice, or that it was something on the wish list. Perhaps another reviewer with a sharper recollection than my own can provide some input. ^{Atsme✍🏻📧} 00:24, 10 October 2018 (UTC)[reply]

@MMiller (WMF) and Atsme: there has never been a choice. As in Twinkle, PROD, BLPPROD, CSD, and AfD tags send a message to the original creator (or the person who moved a draft to mainspace through Curation). What we have been asking for is that all tags placed on new pages at Curation send an alert to the creator, otherwise those pages simply remain perma-tagged forever - and do. But of course the developers have stated they are not interested to address the issues on our list. They have hinted that we, the volunteers, should either do their programming for them, or join that Xmas stocking wish list of convenience gimmicks. That might work though if Insertcleverphrasehere can drum up his 640 reviewers to vote for them. And that's one of the reasons why after shepherding NPP for a decade, I've retired from it. That's how the WMF treats it productive volunteers. Kudpung กุดผึ้ง (talk) 08:10, 13 October 2018 (UTC)[reply]

Atsme and Kudpung -- thanks for the details. Yes, unfortunately, our team won't be able to tackle that change to the way the workflow behaves, and the 2019 wishlist survey is definitely the right place to bring it up so that the Community Tech team can address it. -- MMiller (WMF) (talk) 22:17, 15 October 2018 (UTC)[reply]

@MMiller (WMF): Sorry to disagree yet again, but the wish list is definitely not the place - you know it, Danny knows it, Toby knows it. The CEO is travelling , unreachable for the volunteers, and is kept unaware of it. The NPP system is a vital, indispensable core function of the en.Wiki - it is not something to be 'wished' for. The backlog is growing again, and you/we will end up with no one guarding the gate at all, and all the spam, attack pages, and other junk slipping quietly and permanently into the encyclopedia corpus after being unprocessed for 90 days, and new articles being wrongly tagged for deletion by raw newbies who are still permitted to do it despite our efforts. FYI: @Atsme, Barkeep49, Insertcleverphrasehere, and Usernamekiran:. Kudpung กุดผึ้ง (talk) 02:28, 16 October 2018 (UTC)[reply]

@MMiller (WMF), Atsme, Kudpung, and Barkeep49: Hi. I put forward a temporary solution to the visibility of curation bar at special:diff/863686810. —usernamekiran(talk) 08:25, 13 October 2018 (UTC)[reply]

@Usernamekiran: thanks for posting that workaround. Our engineers are currently working on toolbar disappearance issues with this task, and I should have an update this week. -- MMiller (WMF) (talk) 22:17, 15 October 2018 (UTC)[reply]

I've experienced this as well. It is a very urgent issue that needs fixing immediately. This sort of issue leads to less patrolling, and the backlog is raising again. — Insertcleverphrasehere ^{(or here)} 03:18, 16 October 2018 (UTC)[reply]

@MMiller (WMF): OK, I can't get the Page Curation tools to launch at all, even when navigating directly from the New Page Feed, even for pages from the 'newest' end of the queue. See screenshot at right that shows what I get when navigating to an unreviewed new page directly from Special:NewPagesFeed. No wonder the NPP backlog has spiked by 400 pages in the last couple days, nobody can use the tools! Usernamekiran's temporary solution also does not work, as the ULR clearly shows the ?showcurationtoolbar=1 string is there, but with no tools. Logging out and back in has been suggested, but this also had no effect. This needs to be fixed ASAP. — Insertcleverphrasehere ^{(or here)} 12:24, 16 October 2018 (UTC)[reply]

@Insertcleverphrasehere: Thank you for the report, a few questions for you: 1) have you tried with ?safemode=1 in the URL? 2) Do you see the text "Curate this article" in the "Tools" menu on the left? 3) In Firefox or Chrome, if you right-click and select "Inspect Element" and click anywhere on the page, then click "Console" in the developer tools bar, then reload the page, do you see any errors printed to the console? KHarlan (WMF) (talk) 17:48, 16 October 2018 (UTC)[reply]

Also, Insertcleverphrasehere, we're hoping this isn't a widespread issue, since we know reviews are occurring. But even so, all NPP reviewers need to be able to review, so we're taking this seriously. -- MMiller (WMF) (talk) 19:14, 16 October 2018 (UTC)[reply]

@KHarlan (WMF): ?safemode=1, didn't do anything to help, but the "Curate this article" link in the tools did finally make it pop up and now it seems to be working when navigating from the NewPagesFeed, or when navigating to a page in the feed in a tab where I have previously navigated from the New Pages feed, but it still does not come up when navigating to a page in the feed in a new tab from anywhere other than the new page feed. — Insertcleverphrasehere ^{(or here)} 21:57, 16 October 2018 (UTC)[reply]

@Insertcleverphrasehere: OK, thank you for the update. We're working on a fix in T206580. Thank you for your patience, we'll update everyone here when it's fixed. KHarlan (WMF) (talk) 23:11, 16 October 2018 (UTC)[reply]

Insertcleverphrasehere, Usernamekiran, Atsme, Barkeep49, Elmidae -- the team deployed a fix today that we think will keep the curation toolbar appearing when you want it to appear. The work was done in this Phabricator task. Though there are still a couple edge cases for which we might add some extra fixes, we think that for the most part, the toolbar's appearance should be in working order. Please let me know if you see otherwise. -- MMiller (WMF) (talk) 22:22, 18 October 2018 (UTC)[reply]

Step-by-step play - went to NPP queue, clicked on review for Jeff Yang - toolbar was present - clicked on edit history to see why it was in queue - saw it was a redirect (vandal) - back to article page and the toolbar is now gone. I went back into the queue and clicked on review - page loaded but had JavaScript error messages - when they disappeared the toolbar displayed. I attached a screen capture of the errors - maybe it will help, maybe it won’t. ^{Atsme✍🏻📧} 22:58, 18 October 2018 (UTC)[reply]

After loading up Chrome and navigating to my watchlist, I clicked directly to Lani Daniels from my sidebar new page list (this script), no toolbar showed, 😞. Clicking directly from the New Page Feed the toolbar does show up, and opening it in a new tab from the history page of that article it also shows up. After opening that page from the New Page Feed, If I open any page from my sidebar it now does show up. This is pretty much how I remember it working previously, where I had to visit the New Page Feed at least once after opening Chrome up the first time. It would be nice if it didn't do this. I can't recreate the history page and back bug that Atsme experienced.

Could you please clarify what you would prefer when you say "It would be nice if it didn't do this"? KHarlan (WMF) (talk) 13:51, 19 October 2018 (UTC)[reply]

@MMiller (WMF): @KHarlan (WMF): Also, would it be possible to make ?showcurationtoolbar=1 and the 'curate this article' link work on any article, not just those in the feed? It is quite annoying that the Page Curation tools are only available to me 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. — Insertcleverphrasehere ^{(or here)} 06:23, 19 October 2018 (UTC)[reply]

Could you please file an issue in phabricator to track this feature request? KHarlan (WMF) (talk) 13:51, 19 October 2018 (UTC)[reply]

It is a good point; it would be handy to have an option to have the bar always available. However, it might actually be annoying to always have it float around even while you are doing non-curation things. Say, just reading articles (happens, every so often ;). So I suggest that would have to be optional. --Elmidae (talk · contribs) 08:33, 19 October 2018 (UTC)[reply]

@Elmidae: You can minimize the toolbar then click the "X" to hide it. If ?showcurationtoolbar=1 is not in the URL, then you won't see the toolbar appear unless you click "Curate this article" in the tools menu.

Since today, I get the curation toolbar every time I open a page from Special:NewPagesFeed. This didn't happen for me in the past, and I much prefered it that way. Everything I need there, I get from the much less intrusive Twinkle if I want it. Can this toolbar be made opt-in or opt-out (whichever is most convenient for others) so that those of us who patrol new pages but don't use the curation toolbar don't need to see it every time (I can close it on a per article base, but not for all pages at once). Fram (talk) 13:25, 19 October 2018 (UTC)[reply]

@Fram: You can minimise it by hitting the little X. — Insertcleverphrasehere ^{(or here)} 14:03, 19 October 2018 (UTC)[reply]

Wait... where did the little X go? There used to be a way to minimise it to a tiny bit of 'curation' text on the edge, but this has disappeared mysteriously. — Insertcleverphrasehere ^{(or here)} 14:05, 19 October 2018 (UTC)[reply]

Ah HA! sorry... I'm silly. The top button minimises it, then the X appears. If you then click the X it will disappear and won't reappear unless you click the 'curate this article' link in the toolbox. It does re-appear if you navigate to a page via the 'review' button at Special:NewPagesFeed. Perhaps a 'disable Page Curation' in Preferences would be the fix that we need for people that don't want the tool to load at all. — Insertcleverphrasehere ^{(or here)} 14:10, 19 October 2018 (UTC)[reply]

Yes, I can disable it on a per page basis, but not as a general preference. For me, it's just an annoying floating bar obscuring part of the text but which I'll otherwise not use in my new page patrolling (which I do quite often). Fram (talk) 14:24, 19 October 2018 (UTC)[reply]

@Fram: it is very odd for a gadget to not be able to be disabled in the preferences pane (perhaps unique), can you make a request on the Wikipedia:Page_Curation/Suggested_improvements page to add this as an option in Preferences? I'll make a Phab Task for it. — Insertcleverphrasehere ^{(or here)} 14:28, 19 October 2018 (UTC)[reply]

Thanks, request is made. Fram (talk) 14:35, 19 October 2018 (UTC)[reply]

Apologies if this is a dumb question, but how are the pages marked as reviewed and removed from the queue if we don’t use the toolbar? Is it automatic with our user rights? ^{Atsme✍🏻📧} 14:53, 19 October 2018 (UTC)[reply]

Changes to New Pages Feed on Sept 17 / question about bug fix

Hi all -- I'm Marshall Miller; I'm a product manager with the Growth team at WMF. I last posted here a couple weeks ago because upgrades to the New Pages Feed started becoming available for testing in Test Wiki. Thank you to the reviewers who have commented on the changing feed and the addition of ORES scores. I'm writing now about two things.

Releasing the first upgrades on September 17

The first of the three main improvements will be rolled out on September 17. This change will add an "AfC" button to the top of the feed, and Articles for Creation reviewers will be able to use that button to show drafts in the New Pages Feed to help their review process. This first release will leave the existing NPP workflow unchanged. The next releases will have (hopefully very positive) impacts on NPP: they will add ORES quality predictions and copyvio indicators to all pages. Click here to read more, and click here to participate in the discussion.

Question about "nominated for deletion" and "redirects" bug fix

The New Pages Feed currently has checkboxes under the "State" filter to select "Nominated for deletion" and "Redirects". But it's not possible to select those without also selecting one of "Unreviewed pages" or "Reviewed pages", and when those are also selected, the nominated for deletion articles and redirects are mixed in with the much larger set of other pages. This means it is not possible to generate a list of only articles nominated for deletion, or only redirects.

This bug has been underscored by Insertcleverphrasehere, Vexations, and Barkeep49, and is filed here in Phabricator.

The fix that we have bandwidth to execute now is to move "Nominated for deletion" and "Redirects" from being checkboxes under "State", to being radio buttons under "That". This means that it will be easy to produce lists of just "Nominated for deletion"/"Redirects" articles that are unreviewed or reviewed. But it means that it will not be possible to produce lists where "Nominated for deletion"/"Redirects" are combined with "normal" articles. It will also not be possible to create lists that are "Nominated for deletion"/"Redirects" that are also another button in the list under "That", such as "Were created by bots" or "Were created by blocked users". Will this break any workflows that reviewers are using now?

-- MMiller (WMF) (talk) 22:45, 31 August 2018 (UTC)[reply]

There was a discussion at some point where the emerging consensus appeared to be that articles that have been tagged for deletion should not be marked as "reviewed". I don't remember where that discussion took place (someone?) As I recall it, there was no definitive outcome of that discussion, and reviewers may have developed different workflows. I for one, would welcome the change because I think it makes more sense from a UX perspective. I am a fan of software that is both process and policy-agnostic; tools should not dictate workflows or implement policy. I don't think the proposed change does that, so I'm happy to support. Vexations (talk) 23:01, 31 August 2018 (UTC)[reply]

@Vexations: If you find that I would love to see it. In my own process I will mark all articles nominated for AfD reviewed because one way or another a decision is going to be made. I tend not to mark CSD or PROD articles but will if I'm then willing to watch it and nominate it for deletion myself if the CSD or PROD doesn't go through. If this is against consensus I would like to know to change my practices. Best, Barkeep49 (talk) 23:27, 31 August 2018 (UTC)[reply]

At the current time, should pages marked for deletion be marked as patrolled? And if so, is it limited to CSD, PROD, etc.? So far, I've been going with the complex flow chart, which says that a page that is marked for deletion in any way, including copyvios, attack pages, vandalism, etc. should be marked as patrolled, but I'm willing to change if necessary.--SkyGazer 512 ^{Oh no, what did I do this time?} 23:10, 31 August 2018 (UTC)[reply]

I think there was a (weak) consensus in that conversation that articles tagged for deletion should be marked as reviewed, as otherwise they constantly come up for other reviewers when clicking 'next'. For AfDs, the tag can't be removed, so there is no reason not to mark them as reviewed, and a decision is going to be made one way or the other. That being said, if you know you aren't going to be checking back on it, you might leave CSDed or PRODed articles for someone else to review (someone that will check on it to make sure that the tag doesn't get removed improperly). Also, adding maintenance tags in addition to nominating for deletion is good if you don't plan on checking back on it. There are some people who review articles and redirects at the same time, so the change might get in their way. I also don't like the idea that an article would disappear from the new page feed, even if unreviewed, just because it has a deletion tag on it. Still, I don't think it would be the end of the world, and would probably be better than what we have now. — Insertcleverphrasehere ^{(or here)} 00:10, 1 September 2018 (UTC)[reply]

Thanks for the explanation. I personally would support marking pages as reviewed when they are tagged for deletion, particularly due to what you said about constantly coming up for other reviewers. However, it is true the majority of articles that come through the feed aren't and don't need to be marked for deletion, due to ACPERM (honestly, I can't imagine what NPP was like when any registered user could create articles), so I don't think this would be a huge problem. I do usually like to put any articles that I mark as reviewed on my watchlist, so I would probably want to mark pages I tagged for deletion as reviewed as long as I don't think it would be beneficial to have another patroller take a look at the page and check over everything.--SkyGazer 512 ^{Oh no, what did I do this time?} 00:21, 1 September 2018 (UTC)[reply]

I think that fix is a highly desirable and in fact reflects the way I've tried to use it and thus would support it. Best, Barkeep49 (talk) 23:27, 31 August 2018 (UTC)[reply]

@MMiller (WMF): I'm not sure I understand. If this is implemented, will articles that are tagged for deletion no longer appear in the "default" list of unreviewed articles? (Because I think that's the behaviour we really need.)

The former consensus that articles should be reviewed when tagged for deletion was predicated on this bug, so if it's fixed we will need to revisit it. As many editors have said in the past, relying on a single reviewer to check up on CSDs and PRODs creates a loophole that bad-but-not-CSDable articles can slip through. If these articles no longer appear in the feed while they are tagged, there is no reason to keep that loophole open. – Joe (talk) 06:28, 1 September 2018 (UTC)[reply]

If the new situation will be that deleted tagged articles are put in the other category and won't come up when scrolling with the 'next page' button, then I agree that the current practice of marking deleted articles as reviewed should be revisited (as there would be no reason for that practice any more). In fact, we should also probably modify the page curation tools to not automatically tag articles as reviewed when tagged for deletion. — Insertcleverphrasehere ^{(or here)} 22:21, 1 September 2018 (UTC)[reply]

Looking at this and the phab task again, I don't think the WMF have understood that this is the bug. I'll try and explain on phabricator. – Joe (talk) 06:49, 2 September 2018 (UTC)[reply]

Actually, looking at it now, it seems that bug was fixed at some point. Unchecking "nominated for deletion" removes them from the feed and the "next page" button respects your feed setting. MMiller (WMF) whatever happens this behaviour (which honestly was broken for a long time, though I can't prove it now!) should be retained.

So getting back to the original question, I think the following states are useful for normal NPP workflows (in rough order of importance):

Unreviewed articles excluding redirects and xxDs – for most reviewers
Redirects only – for redirect-reviewers
xxDs only – for patrolling admins

Combined lists of unreviewed articles including redirects/xxDs aren't particularly useful to anyone. – Joe (talk) 07:04, 2 September 2018 (UTC)[reply]

Thank you, Joe Roe (and Vexations, Barkeep49, and Insertcleverphrasehere) for laying this out -- this makes substantially more sense now. Here's what happened. We started pursuing the question of it being impossible to create a list of only articles nominated for deletion or only redirects. As we were looking into it, we realized that the "Nominated for deletion" checkbox wasn't working, causing it to be impossible to exclude those articles from the "Unreviewed" list. We didn't yet know that this was a longstanding bug that reviewers had been working around, and we partially fixed it last week in this Phab task. Since last week, new articles nominated for deletion have been being filtered correctly. This week, we will complete the fix by running a script to correct the statuses of all the other articles in the feed that are nominated for deletion. This means that it will now be possible to exclude articles nominated for deletion by simply leaving that box unchecked, whether they are marked "Reviewed" or "Unreviewed". I apologize for not giving advance notice of that fix -- I didn't know that it was a longstanding major issue that affects workflows.

With the additional change of making "Nominated for deletion" and "Redirects" into buttons under "That", instead of checkboxes under "Show", it would then be possible to create lists of only articles nominated for deletion or only redirects. That is in this Phab task. But now that the issue I discussed in the previous paragraph is fixed, is this still desired?

The details on that additional change are:

The checkboxes for "Nominated for deletion" and "Redirects" would no longer be under "Show". Instead, they would be radio buttons under "That".
All articles would still either be "Unreviewed" or "Reviewed".
By default, "Nominated for deletion" and "Redirects" would be excluded from the feed, regardless of whether they are "Unreviewed" or "Reviewed".
When the "Nominated for deletion" or "Redirects" buttons are selected, the feed would show only articles of that status, that are also "Unreviewed" and/or "Reviewed, according to how those two checkboxes are set.
It will not be possible to create a list of "Unreviewed" articles that includes "Nominated for deletion" or "Redirects".
The only way to review redirects will be by making the New Pages Feed only show redirects.
Those two new radio buttons will therefore be following slightly different logic than the others, such as "Were created by bots", which constrains the feed when selected, but includes bot articles when unselected. In this case, when the "Nominated for deletion" or "Redirects" buttons are unselected, they will be excluded from the feed. There are likely more intuitive and thorough ways to redesign the New Pages Feed so that all possible combinations are available, but the team does not currently have bandwidth to make such a major change.

With all that said, I think the two questions remaining are:

1. Given that the "Nominated for deletion" bug is fixed, should we still change the behavior of the "Nominated for deletion" and "Redirects" checkboxes to make it possible to create lists containing only those types of articles?

2. If we do make that change, will it be okay that it will not be possible to create a list of all "Unreviewed" or "Reviewed" articles that also contain "Nominated for deletion" or "Redirect" articles?

-- MMiller (WMF) (talk) 20:34, 4 September 2018 (UTC)[reply]

@MMiller (WMF): Thanks for the update. My answers are a strong yes for Q1, Q2 isn't ideal but I think a better state of affairs than the status quo. Best, Barkeep49 (talk) 20:39, 4 September 2018 (UTC)[reply]

@MMiller (WMF): It isn't ideal. I still don't understand why the feed can't be designed to have the buttons under 'show' just work like the "unreviewed" and "reviewed" buttons (all you have said is that you "don't have the bandwidth for it", but that doesn't make a lot of sense). Ideally we would have #1 without #2. I know that some people will not like #2, because some reviewers review redirects and articles at the same time in the same feed. If you can't change the functionality of the "redirect" and "nominated for deletion" under 'show', can't you leave the current buttons under 'show' and add buttons under 'that' so that we can have both types of functionality? — Insertcleverphrasehere ^{(or here)} 21:17, 4 September 2018 (UTC)[reply]

Thanks MMiller (WMF). It all makes more sense now. I always thought the nominated for deletion bug was in phabricators, because I'd been misreading phab:T169244. Oops!

It seems several editors would find Q1 useful and I don't think Q2 is a big deal. There's no good reason to use unreviewed+xxD anymore and those people using unreviewed+redirects are a) in a minority and b) can adapt their workflow quite easily by just opening the feed in two tabs. – Joe (talk) 05:18, 5 September 2018 (UTC)[reply]

Joe Roe, Insertcleverphrasehere, Barkeep49, Vexations -- it's been a couple weeks, but I'd like to revisit this with a new proposal that we on the team think will be a more flexible fit. See the messy mockup below (that I made by slicing up an screenshot and typing on it; nothing fancy). Here's what happening in there:

We separate the "reviewed/unreviewed" dimension from the type of page. We do this by adding a new section called "Type" that has checkboxes for "Nominated for deletion", "Redirects", and "All others" (we would need a better word for this last type -- I am trying to say "normal" pages).
Then a reviewer could generate any of the 21 possible combinations. For instance, by checking "Unreviewed", "Nominated for deletion", and "All others", a reviewer would have a list of all pages, including those nominated for deletion, that are unreviewed. Or by checking "Unreviewed", "Reviewed", and "All others", a reviewer would have a list of all pages, excluding redirects and nominated for deletion, that are any review status.
At least one box must be checked in both those top two sections.
All the things in the "That" section could be layered on top.

Here is the mockup:

What do you think? -- MMiller (WMF) (talk) 21:38, 20 September 2018 (UTC)[reply]

I think this is a really good implementation. Thank you and the team for your work MMiller (WMF). Best, Barkeep49 (talk) 21:43, 20 September 2018 (UTC)[reply]

This looks great. Thanks very much for implementing it in a way that didn't need serious compromises one way or the other. This looks like it will support existing workflows. — Insertcleverphrasehere ^{(or here)} 21:50, 20 September 2018 (UTC)[reply]

Fantastic, thanks very much MMiller. – Joe (talk) 22:53, 20 September 2018 (UTC)[reply]

Joe Roe, Insertcleverphrasehere, Barkeep49, Vexations -- we've coded up this change, and it is slated to be in English Wikipedia on Thursday. We're first going to deploy it to Test Wiki on Tuesday (tomorrow) so that you can try it before it is rolled out, and I'm hoping you can take a few minutes on Tuesday or Wednesday to make sure we implemented it correctly. The changes should be on Test Wiki at about 21:00 UTC on Tuesday. Thanks, and please post here with your thoughts! -- MMiller (WMF) (talk) 18:54, 1 October 2018 (UTC)[reply]

I will be off Wikipedia the rest of the week so I can't test but again want to express my thanks to the team for working on this. Best, Barkeep49 (talk) 19:51, 1 October 2018 (UTC)[reply]

Just taking a look now. It seems to work as I hoped it would. I see only two articles that have been nominated for deletion in the dataset, so it takes a while to see them in the feed with both "Nominated for deletion" and "All others" checked, but now I can see only articles nominated for deletion, only articles that have not been nominated for deletion and both. Still thinking about an alternative for "All others". Thanks, --Vexations (talk) 22:20, 2 October 2018 (UTC)[reply]

Thanks, Vexations. We're going to roll out this change to English Wikipedia tomorrow, as I announced below. -- MMiller (WMF) (talk) 19:45, 3 October 2018 (UTC)[reply]

Joe Roe, Insertcleverphrasehere, Barkeep49, Vexations -- this change is now in production, so everything should be as we planned! Let me know if you see anything to the contrary. -- MMiller (WMF) (talk) 19:53, 5 October 2018 (UTC)[reply]

I've had a quick look and it looks good. I'll let others investigate in more detail as I have little time online at present (currently on holiday in the USA). Thanks. — Insertcleverphrasehere ^{(or here)} 20:28, 5 October 2018 (UTC)[reply]

I have had a quick look myself. Overall I think you and the team have done good work. Thank you. One small quibble. I clicked on the first article I could find Margareth Angelina which as it would have it didn't have the trash icon and sure enough someone had removed the speedy delete tag. So the icon was correct but the feed it was in wasn't correct. Any chance that could be fixed? Best, Barkeep49 (talk) 01:51, 6 October 2018 (UTC)[reply]

@Barkeep49: thanks for noticing that. We see the same issue, and we're putting together a fix today in this task. I'll let you know when it's deployed. -- MMiller (WMF) (talk) 19:26, 10 October 2018 (UTC)[reply]

@Barkeep49: this issue is now fixed. Let me know if you see anything else! -- MMiller (WMF) (talk) 20:08, 11 October 2018 (UTC)[reply]

Thanks MMiller (WMF) - looks good. On a related note is there a reason that the RfD template isn't recognized as a deletion by the queue? Best, Barkeep49 (talk) 20:21, 11 October 2018 (UTC)[reply]

@Barkeep49: are you referring to when a page has the AfD template? If so, I think we noticed the same thing yesterday, filed here, which we will plan to fix. -- MMiller (WMF) (talk) 17:32, 12 October 2018 (UTC)[reply]

@MMiller (WMF): What I'm talking about is use of the Template:RFD as can be seen on Unicode 31. The page shows up in the feed because it's no longer a redirect which is good but ideally it would be thought of as a deletion for purposes of sorting in the queue. Best, Barkeep49 (talk) 19:06, 12 October 2018 (UTC)[reply]

@Barkeep49: okay, I understand now. I see the reasoning by which an RfD would be considered related to deletion. I think this is more of a question of policy than a technical one. If the NPP community decides that RfD should be included in the feed in that way, we could probably alter the logic to accommodate it. -- MMiller (WMF) (talk) 22:06, 15 October 2018 (UTC)[reply]

Collection of independent scripts to bundle into a 'NPR helper tool'

While the page curation toolset is nice and user friendly in a lot of ways, it is also difficult to fix, and by virtue of being hard-coded into Mediawiki, it is difficult to modify or add/remove features. It has been pointed out that pretty much all of the tasks that can be completed by the page curation tool can be completed by various user scripts and gadgets, which in most cases are less buggy, and in a lot of ways can be more user friendly. For me personally, it has taken me quite some time to collect various scripts together that give me all the tools I need for new page reviewing, and it would be much more convenient to have them collected in a single cohesive toolset (this was I imagine the original vision of the page curation software-Kudpung will probably know more).

I've been mulling this over for a while, and I think we should have a bit of collaboration to see what features we would like this combined tool to have, highlight existing scripts and gadgets that we already have, and identify sub-par scripts or areas where we are reliant on the Page Curation software. We also need to make a decision whether we want this helper tool to duplicate or to supplement the existing page curation toolset. I've had a stab below at identifying scripts which duplicate existing functionality of the PC tools, as well as scripts which fill in gaps or are generally useful during new page reviewing.

Existing page curation functionality and scripts which duplicate this:

Metadata for this page: Having the page history and basic creator stats available at the click of a button (without having to navigate away from the page is very useful, and I'm not aware of a script which duplicates this functionality. Moremenu actually provides a ton more data than this, such as page logs etc, but these links all require navigating away from the page.
Wikilove: I'm sure there are some scripts that provide this sort of functionality, but probably require that you visit the user's talk page. I'm currently not aware of them, but this would be a useful feature. Welcome messages at the click of a button would also be useful.
Message author: There are a number of issues with the existing page curation messaging system. The inability to distinguish the real creator of the current content (vs accidentally sending it to the creator of an expanded redirect), the need to un-review/re-review to send a message, the hard-coded passive-aggressive non-customisable message templates, inability to also send feedback to the talk page of the article as well, etc. This could be significantly improved and currently isn't going to happen in the vanilla PC tool unless we win the holiday popularity contest.
Maintenance tagging: This functionality is duplicated by the Twinkle gadget, and while I prefer the interface of the page curation tool for tagging, twinkle has some additional options (such as all the redirect tags that aren't in the PC tool at all). The page curation tool also has some additional options that Twinkle doesn't, such as the ability to simultaneously send a message to the author when adding a maintenance tag, which is quite useful.
Deletion tagging: This functionality is much better in Twinkle in my opinion. While there are deletion tag logs for the PC tool (where it lumps CSD, AfD and PROD together), twinkle has CSD and PROD user space logs that are much better IMO, and there is always the AFD stats tool to track AfD nominations. There are a number of significant bugs with the PC tools with regard to deletion or missing features, such as the [to correctly parse 2nd or third nominations] (it just posts the nomination to the original AfD page), or decline CSD/PRODs from other reviewers/editors (Twinkle has this), or Sort AfDs when nominating (twinkle does this, and User:Enterprisey/delsort.js is also a useful tool for this).
The 'Next' button: To my knowledge, this button tracks your sort preferences at Special:NewPagesFeed, then shows you the next article in line (earlier or later depending on whether you sort by youngest or oldest first). There is no script that duplicates this feature, but it might be able to be implemented by a bodge which just finds the button on the page curation tools and clicks it; an experienced coder will know more.

Missing features that the Page curation doesn't have, but which is required/advantageous for new page review (and scripts that fill these roles):

Moving to draft; has become more-and-more a core NPR function, the excellent tool by Evad37 currently fills this role, which is customisable in a number of different ways.
Categories; Hotcat is in my view essential for NPR, and should be turned on by default for all reviewers. While it isn't our job, technically, and you can just put an uncategorised tag on the article, Often you will know several good tags to put on it.
Page logs/User Logs; MoreMenu provides links to all these, and give you info about who previously 'reviewed' an article, etc. You can also look up various user logs in the moremenu options as well.
Copyright violation tool: The PC toolset currently doesn't have this functionality, though copypatrol is going to be added to the New page feed next month in a limited way. MoreMenu provides a link to the Earwig Copyright violation checking tool, though it is a bit of a pain to navigate to, and User:The Earwig/copyvios.js adds a link in the 'tools' section, which I slightly rewrote to move this link so that it is in the same place as the other NPP tools and opens in a new tab rather than the current window: User:Insertcleverphrasehere/copyvios.js. A link to this should also be included prominently in any NPR bundle tool (ideally without having to navigate away from the page, or automated in some other way). I have made a script request for an automated or semi-autmoated copyright violation tool here.
Revision Deletion for copyvios: In the same vein, requesting revision deletion is not part of the PC tool at present. User:Enterprisey/cv-revdel seems to do this perfectly, but is new and might need still need testing.
Previous Deletions: A huge oversight with the current tool is that it doesn't tell you when the page has previously been deleted, or that it was previously taken to AfD. Checking these manually for each article is tiresome. User:Writ Keeper/Scripts/deletionFinder.js adds links that appear next to the title when either of these apply, and some kind of functionality like this should be added to any NPR bundle (ideally without having to navigate away from the page).
Wikiproject templates: Adding Wikiproject templates to the talk pages of articles is pretty useful as part of the NPR process, and while all reviewers don't do it, I think it is advised as it has the potential to draw editors from various wikiprojects to help out with expanding/fixing articles. User:Evad37/rater provides this functionality.
Stub tagging: Hot off the press, we have a hierarchy search based stub tag adding tool: User:Danski454/stubsearch.js.
Vandalism/Page protection/user warnings: Other 'Twinkle stuff' which is commonly useful to New Page Reviewers.
Fix bare URLS/duplicate refs: I've found MoreMenu's link to Refill to be very useful when I come across an article that has lots of bare URL refs, or references that are copied multiple times (instead of named and cited). This not only improves the article, but can make the list of references easier to parse.
Easy search for sources: User:Writ Keeper/Scripts/googleTitle.js adds a nice link next to the article title which allows you to instantly search google for sources.
Superlinks: User:Bradv/Scripts/Superlinks is an insane tool that we all need to have installed. It allows to to view page logs, history, and talk pages without having to navigate away from the page, and also includes a link to the NPP Flowchart that displays in a scrollable window onscreen (or the AfC flowchart if reviewing a draft). Largely covers the same stuff as moremenu, but in a much more convinient form.

I'm certain that I've missed quite a few things, but perhaps this can start the ball rolling with regard to discussing the features/scripts that we would want to have in an 'NPR helper tool' (or what features we would prefer to leave out). If anyone has any other suggestions for useful scripts that should be included, please mention them! Cheers, — Insertcleverphrasehere ^{(or here)} 02:26, 19 September 2018 (UTC)[reply]

@Insertcleverphrasehere: Thank you for this compilation. –Ammarpad (talk) 06:41, 21 September 2018 (UTC)[reply]

Full recommended gadget/script list

Gadgets

Core User Scripts

Other Scripts

User:TheJosh/Scripts/NewPagePatrol or User:Bradv/Scripts/Powerbar.js (whichever you prefer)
User:Danski454/stubsearch.js (new tool for stub tagging with hierarchy based stub searching)
User:Enterprisey/delsort.js
User:Writ Keeper/Scripts/googleTitle.js or User:Bradv/SearchLinks.js (whichever you prefer)

Discussion of 'NPR helper tool'

Please discuss here. — Insertcleverphrasehere ^{(or here)} 02:45, 19 September 2018 (UTC)[reply]

I think there are a lot of advantages to having additional functionality as well as ALL of the existing PC functionality in the script bundle, rather than just supplementing the existing features of the PC tool. Some might like this or not, but non-reviewers would be able to install the bundle and use it to practice new page reviewing. Non-NPR reviewers could mark them as 'patrolled', which shows up in the patrol log for that user, but the page won't be marked as 'reviewed' or appear in the user's review log unless they have the NPR userright, so learners could safely practice without risk of pages falling through the cracks). This would help address some current issues with applicants being turned down for not having any review experience (it is currently a bit of a chicken and egg situation as applicants do not get a chance to use the page curation tools prior to requesting the NPR userright). Additionally, having buggy/incomplete features in the PC toolset is bad, it is better to just discontinue it altogether if we can duplicate the existing functions without the bugs. I hate the idea that we basically throw out all the work that the WMF has done for the page curation toolset, but I don't see any other practical way forward with those tools. Even if we were to win the Christmas popularity contest, you can guarantee that we won't get half of what we ask for, and we will be begging for bugfixes for years. Of course, someone actually has to be willing to put in some work coding such a tool, which is not a guarantee, but I think there is WP:NODEADLINE, and could perhaps be done by a team of editors talented at coding. We could always put in a request at the Wishlist for the WMF to re-create the page curation tools as a script (implementing existing scripts as appropriate), then however they invariably fuck up, at least we can then fix it ourselves. Regardless of which direction we want to go in, clarifying what we want/do not want in our NPR tools is essential. — Insertcleverphrasehere ^{(or here)} 03:10, 19 September 2018 (UTC)[reply]

I use a lot of the scripts listed above. I used to have them installed via my common.ja but I just bundled them in a little suite of NPP tools at User:Vexations/scripts/NPP.js I suppose we could create something similar here, at say Wikipedia:New pages patrol/scripts/NPP suite.js? Vexations (talk) 03:24, 19 September 2018 (UTC)[reply]

@Vexations: That's the quick and dirty solution for sure. We have a few options though, depending on what we really want/need/can get. I'm sure that someone talented with coding could do a little better by getting all of them to populate a single toolbar item. Making a single popup window tool that acts as a hub for elements of the various other scripts is probably ideal, as well as some development of a few missing pieces, but would take considerably more work. — Insertcleverphrasehere ^{(or here)} 04:25, 19 September 2018 (UTC)[reply]

Thank you for this initiative and the substantial work that seems to have gone into it. This is quite timely. I admit to being quite cheesed off by having been referred to the Wishlist for improvements of the tool, with all the immense delays, blackboxery and popularity contest aggravation that entails. If a user-curated bundle of equal or greater functionality could be constructed, that would be most welcome. - In your list above you appear to have covered all the desirable features that would occur to me. Can't really weigh in on the technical side; toolbars are nice for the one-click monkey in us, of course. --Elmidae (talk · contribs) 09:09, 19 September 2018 (UTC)[reply]
Someone, I can't remember who ATM, said that if Curation Toolbar 2.0 didn't have keyboard shrotcuts they'd make a script. ^Thanks,L3X1 ◊distænt write◊ 02:08, 21 September 2018 (UTC)[reply]

Yeah... the keyboard shortcuts on Evad37's WP:RATER are the freaking bomb. I can add multiple wikiprojects to a page and only have to use my mouse of a single click at the end to confirm. Very convenient and saves a lot of time. — Insertcleverphrasehere ^{(or here)} 09:24, 21 September 2018 (UTC)[reply]

Here's a brand new script hot off the coding blocks which could be useful to a great many NPP's in helping them do Revdel's: User:Enterprisey/cv-revdel Best, Barkeep49 (talk) 23:50, 21 September 2018 (UTC)[reply]

Handy, cheers! --Elmidae (talk · contribs) 07:12, 24 September 2018 (UTC)[reply]

This is exactly what we wanted. Thanks Enterprisey! I've added it to the list above. — Insertcleverphrasehere ^{(or here)} 15:49, 24 September 2018 (UTC)[reply]

Been playing around a bit in my sandbox, and that script works great. It will definitely prove to be useful for my NPPing. Thank you!--SkyGazer 512 ^{Oh no, what did I do this time?} 16:00, 24 September 2018 (UTC)[reply]

I'm in the habit of tagging the author of non-English articles on their talk page with :

==English please==
{{subst:contrib-XX1}} ~~~~

where I manually enter the language code where the example has XX, using AutoHotKey. I think that would be a useful part of a full toolset if it were scripted. Cabayi (talk) 09:03, 8 October 2018 (UTC)[reply]

@Cabayi: Hmm, I see what you are saying here. I think that a NPP bundle would be relying on Twinkle for the majority of tagging, so it would probably be difficult to code a custom message to the page creator for this specific tag. It might be worth requesting this directly at Wikipedia talk:Twinkle, or at [1]. — Insertcleverphrasehere ^{(or here)} 12:18, 16 October 2018 (UTC)[reply]

OK, given how the comminity wishlist discussion is shaping up, I think we should regard an 'NPR helper tool' to essentially be a bundle of other essential/useful scripts to complement Page Curation, rather than a straight alternative. We will see which of these are needed after the Page Curation tools are worked on (assuming that we do well in the Wishlist). — Insertcleverphrasehere ^{(or here)} 21:26, 22 October 2018 (UTC)[reply]

Sports teams articles

I often happen across articles like 1997–98 North Carolina Tar Heels men's basketball team when NPPing. Are articles for a specific year for a specific team for a specific sport notable? L293D (☎ • ✎) 16:20, 3 October 2018 (UTC)[reply]

Hi L293D - The appropriate guideline is WP:NSEASONS. With programs like North Carolina, Kentucky, UCLA, Kansas, etc., almost every year will be deemed notable. In fact, many folks think that every season of every DI team is notable. I don't get that from the guideline, but I've given up arguing about it. For DII and DIII teams, it definitely applies. If the 1941 Podunk Warriors had a 1-10 season, I would not consider that notable, but if they won the DIII with a record of 9-2, than that would seem to be notable as per the criteria. Hope this helps. Onel5969 ^{TT me} 17:29, 3 October 2018 (UTC)[reply]

Oh, and my examples of elite programs were in men's basketball. If it were DI football, then the list would include teams like USC, OK, AL, etc... Softball: AZ, UCLA, OK, ASU... etc...

Quality scoring and improved filter logic to be added to New Pages Feed tomorrow

Two enhancements are planned to be added to the New Pages Feed tomorrow as part of this project. This post summarizes them briefly, and I will post again with more information once they are in the feed and verified to be working correctly.

Quality scoring with ORES: previously announced here, this will add two new sets of filters to the feed, and new information for each page in the feed.
Improved filter logic: discussed in-depth here, this is a fix to a long-standing limitation to the filters. Previously, reviewers could only review redirects and pages nominated for deletion by lumping them in with all other pages. Going forward, reviewers will be able to make the feed show any combination of pages so they can produce exactly the list they need for their workflow. Specifically, the "Reviewed / Unreviewed" checkboxes will be separated from checkboxes for "Redirects / Nominated for deletion / All others". "All others" refers to pages that are not redirects or nominated for deletion. We will be migrating all reviewers' existing filter settings such that they reflect the same logic as they currently do.

If all goes as planned, these changes will appear in the feed over the course of tomorrow. However, if something goes wrong in the deployment, we will add the changes at the beginning of next week instead. Please let me know if you have any questions, and please speak up right away if anything looks wrong in the New Pages Feed tomorrow! -- MMiller (WMF) (talk) 19:43, 3 October 2018 (UTC)[reply]

Hi, I've just had a look at the changes to the new page feed. Theres a slight but not major issue. If I select a filter with no articles (such as Vandalism) it is not possible to see and click the "Set filters" to change the filters back as it extends out of the page. I have however found a temporary fix, which is to to zoom the site out till the page elements are smaller and the button can be seen again. ~ Araratic | talk 08:12, 5 October 2018 (UTC)[reply]

Thanks for trying things out, Araratic. Yes, that's always been an issue with the feed -- but I see now that it will occur more frequently, because with more ways to the filter the feed, it is easier to end up with zero pages in the list. We filed it here, and I'll talk with our team about whether there is a quick and easy way to fix this. -- MMiller (WMF) (talk) 17:53, 5 October 2018 (UTC)[reply]

MMiller (WMF) - I suspect I'm encountering the same issue: if I go into the history and revert to a previous version, then the resulting article does not display the sidebar anymore (so I can't mark as reviewed or add tags that way). I've been going back to the feed interface and selecting the article again, at which point it reappears. Bit of a speed bump! --Elmidae (talk · contribs) 15:21, 5 October 2018 (UTC)[reply]

@Elmidae: this sounds like an issue that we expect should be fixed by now. Are you saying that when you go into the "View history" tab of an article, revert, and then try to use the Page Curation toolbar, the toolbar is gone? Has that worked for you in the past? Could you give an example of article for which it happened? Thank you. -- MMiller (WMF) (talk) 17:53, 5 October 2018 (UTC)[reply]

@MMiller (WMF): yes, that was the issue at time of posting; however now it seems to work (as just tested when reverting John Paul's Rock to redirect) - bar was present upon reverting to version n-2. So I suppose I got the last of the pre-fix behaviour :) --Elmidae (talk · contribs) 19:17, 5 October 2018 (UTC)[reply]

@MMiller (WMF): I'm sorry to say the issue still persists (not sure why it worked for a spell there). Multiple instances in sequence, the latest with Konstantin Kastrioti: article displayed with sidebar; went into history, from there reverted to previous version; deployed; sidebar absent from article. Had to follow link from NPP browser again for it to reappear. --Elmidae (talk · contribs) 16:04, 8 October 2018 (UTC)[reply]

@Elmidae: I'm sorry you're still seeing that issue; very frustrating. We've heard a couple related issues, and we're tracking here, if you want to follow along. Could you log out and back in again, and let me know if you're still seeing it? I'll keep you updated as we look into this. -- MMiller (WMF) (talk) 00:07, 10 October 2018 (UTC)[reply]

@MMiller (WMF): Persists after logging out and back in. I'm surprised I appear to be the only one with that issue - as it's pretty in-your-face, I suspect no one else is encountering it. If it's somehow caused by my personal config then I guess it's unliley there will be an easy fix. --Elmidae (talk · contribs) 12:31, 12 October 2018 (UTC)[reply]

Deployment complete -- next steps

Hi all -- the deployment was successful yesterday, and in our testing we are seeing all pages in the New Pages Feed having the "Predicted class" and "Potential issues" classifications that we expect. The expanded filters related to "Nominated for deletion" and "Redirects" also seem to be working as planned. Please let us know if you see anything different.

In this post, I want to give some more background on how the new ORES classifications can be used for new page review. As this community updates any documentation around the New Pages Feed and how to review pages, our team is happy to help with any explanations or screenshots. Let me know!

ORES is a system built by the WMF Scoring Platform team, led by Halfak (WMF), that automatically classifies edits and pages using machine learning. ORES models are in use at the Recent Changes and Watchlist feeds, where they estimate "content quality" and "user intent". We have added two different models to the New Pages Feed, which estimate the "predicted class" and whether an article has "potential issues". The models are built by looking at existing examples of articles that have been given a class, or shown to have issues, and then the algorithm learns what it looks like when future articles have those same characteristics. The classifications will update in real time as pages change. As as an editor works on their new page, its "predicted class" may rise "Stub" to "Start" in the New Pages Feed.

For instance, as I write this, there are 5 articles in the New Pages Feed marked as potentially spam, vandalism, or attack. Those might be pages to review soon, because they might have the most egregious issues associated with them. There are also 31 pages predicted to be "B-class" or better. Those also might be good pages to review soon because of their high quality.

It's important to note, as was referenced many times in the community discussion around planning these enhancements, that these predictions are only predictions. Because they are only suggestions from an algorithm, they are often wrong. Reviewers are meant to use them to find pages that are more likely to have those characteristics, in order to help make reviewing work more efficient. They can also be taken into account when doing a review. But at the end of the day, as several experienced reviewers emphasized in the community discussion, human judgment is still what should be deciding whether a page is of high quality or not.

As reviewers work with these models, cases will come up where the models seem to be wrong. It is really helpful to the Scoring Platform team to report those cases! They can use those to recalibrate and improve the models. Here is where and how to do that.

Please let us know if you have any questions, concerns, or bugs with the new ORES classifications. Our next (and final) enhancement to the New Pages Feed will be the addition of copyvio detection, planned for the week of October 15 or October 22. I will be back with more information on that. -- MMiller (WMF) (talk) 18:33, 5 October 2018 (UTC)[reply]

IP reviews?

Something strange I noticed over at Wikipedia:Database reports/Top new article reviewers: there is an IP (with no other contributions) which has inexplicably marked 20 redirects as reviewed. These also appear in the patrol log, which would usually mean they were marked as reviewed using Twinkle, but that doesn't make any sense as I'm pretty sure that you can't even use Twinkle without being logged in. I can't really find anything to explain it. Any ideas folks? — Insertcleverphrasehere ^{(or here)} 17:03, 4 October 2018 (UTC)[reply]

Confirmed as a bug T206130. A patch is ready too, just waiting for deployment. –Ammarpad (talk) 17:11, 4 October 2018 (UTC)[reply]

(edit conflict) +1, this puzzled me, too. I even welcomed them. It’s an IPv6 IP if that is of any gravity to the matter at hand.

I would like to note, however, that it’s [probably] possible for one’s contributions to appear on the patrol log without using Twinkle, as, I think when I patrol pages when I am on mobile, my contributions appear on the patrol log. Again, I am not totally sure, nor am I java script wizard. Regards, SshibumXZ (talk · contribs). 17:21, 4 October 2018 (UTC)[reply]

Thanks, Ammarpad. Yes, Xaosflux reported this yesterday in T206130 -- people were able to review via the API without having the right role. We think this was open in that way for about 6 weeks, introduced by accident in a code change. The fix was deployed late yesterday, and so this shouldn't be possible anymore. -- MMiller (WMF) (talk) 17:49, 4 October 2018 (UTC)[reply]

Is there a list of these reviews somewhere so we can make sure nothing egregious was approved? Natureium (talk) 17:58, 4 October 2018 (UTC)[reply]

@Natureium: See: [2]. They seem like totally fine redirects (with pretty random subjects) to the point that I was wondering if the bug had been because an NPR reviewer's reviews had accidentally been assigned to an IP somehow. — Insertcleverphrasehere ^{(or here)} 18:18, 4 October 2018 (UTC)[reply]

That's assuming the only person who patrolled without having the perm was that one IP. Do we know if that's the case? Natureium (talk) 18:19, 4 October 2018 (UTC)[reply]

If they do they will be listed at Wikipedia:Database reports/Top new article reviewers. I do notice one more IP that did a couple reviews [3] (they actually marked two articles unreviewed). — Insertcleverphrasehere ^{(or here)} 18:29, 4 October 2018 (UTC)[reply]

The full list of IPs that have ever marked something as patrolled or reviewed/unreviewed is: 2606:A000:83C5:7200:556E:7DD2:BCA6:57AD, 136.24.142.114, 87.172.114.16 and 98.26.4.244. --Roan Kattouw (WMF) (talk) 19:00, 4 October 2018 (UTC)[reply]

Phab task closed as resolved. — Insertcleverphrasehere ^{(or here)} 21:44, 20 October 2018 (UTC)[reply]

comment

was reverted several times by this individual Special:Contributions/Pinkbeast while trying to link orphan articles...left this note [4](BTW this is the page curation log[5])--Ozzie10aaaa (talk) 11:07, 5 October 2018 (UTC)[reply]

Please remove the NPR permission

Since I was granted the new page reviewer right on 3 September, my browser has been gobbling up gigabytes of memory on English Wikipedia pages; see this VP-Tech thread for details. The issue is being tracked,[6] but has not be resolved yet. I would like this permission to be temporarily removed from my account, to see if it correlates with the memory leak or just a coincidence. — JFG ^talk 09:48, 6 October 2018 (UTC)[reply]

Done TonyBallioni (talk) 13:53, 6 October 2018 (UTC)[reply]

@JFG: Hi. Any updates on the memory overuse issue? —usernamekiran(talk) 00:31, 20 October 2018 (UTC)[reply]

@Usernamekiran: Diagnosis is ongoing at T205127. We have determined that it's unrelated to the NPR right. Accordingly, I'd like to recover this permission. @TonyBallioni: please? — JFG ^talk 12:43, 20 October 2018 (UTC)[reply]

Done TonyBallioni (talk) 14:27, 20 October 2018 (UTC)[reply]

Requesting immediate archiving...

NPP Browser broken?

I found that the NPP browser at https://tools.wmflabs.org/nppbrowser/ no longer works for me. It still lists redirects, but not articles. Anyone else? --Vexations (talk) 16:35, 8 October 2018 (UTC)[reply]

Vexations, Broken for me as well. ^Thanks,L3X1 ◊distænt write◊ 16:39, 8 October 2018 (UTC)[reply]

Ping Rentier if he’s still about. TonyBallioni (talk) 18:03, 8 October 2018 (UTC)[reply]

(same here) --Elmidae (talk · contribs) 07:52, 10 October 2018 (UTC)[reply]

@Vexations, L3X1, TonyBallioni, and Elmidae: It should be fixed now. There seems to have been an undocumented change in the MediaWiki API. Rentier (talk) 22:31, 11 October 2018 (UTC)[reply]

So it is. Thank you :) --Elmidae (talk · contribs) 06:56, 12 October 2018 (UTC)[reply]

However, I do not get the curation toolbar when following a link from the browser, which makes it kind of pointless. Anyone else having that problem? --Elmidae (talk · contribs) 07:32, 12 October 2018 (UTC)[reply]

@Rentier, Vexations, L3X1, TonyBallioni, and Elmidae: It is most probably because of some change in mediawiki API. If you stumble upon freshly created page from anywhere except new pages feed, even then you dont get to see the curation toolbar. In old days, one could get toolbar for reviewed pages even after few days. But you can get it by entering ?showcurationtoolbar=1 in the address bar after the current address, and ?redirect=no&showcurationtoolbar=1 for redirects. I think we should contact someone from WMF/tech team to show the curation bar upto 15 days even after the page was patrolled.Apologies for the mass ping. —usernamekiran(talk) 10:29, 12 October 2018 (UTC)[reply]

I added the parameter to links in the NPP Browser, so the curation toolbar will get displayed. Rentier (talk) 10:40, 12 October 2018 (UTC)[reply]

One would think that setting showcurationtoolbar=0 would hide the toolbar, but it doesn't. Is there another way to turn it off? I don't always want to see it. Vexations (talk) 11:03, 12 October 2018 (UTC)[reply]

I did not know that; very useful. Cheers. --Elmidae (talk · contribs) 12:29, 12 October 2018 (UTC)[reply]

If you are having trouble with the Page Curation Toolbar not coming up, try clicking the "Curate this article" in the "Tools" menu on the left, it finally fixed my bugged PC toolset which refused to come up anywhere on any articles regardless of the ?showcurationtoolbar=1 string or where I navigated from. — Insertcleverphrasehere ^{(or here)} 22:00, 16 October 2018 (UTC)[reply]

recent changes

@MMiller (WMF): I've noticed that I no longer see the mark as patrolled link that used to appear on unreviewed pages when I did not have the curation toolbar open. I also can't close the curation toolbar anymore. Is this intentional? --Vexations (talk) 13:02, 9 October 2018 (UTC)[reply]

@Vexations: thanks for posting. That definitely is not intended behavior, and sounds annoying. We created this task to track this issue and related ones. We've been looking into it today, and will do some more tomorrow. For now, it's helpful if you tell us what pages you see this behavior on. And also whether it goes away from logging out and back in. If anyone else sees something similar, please speak up! Thank you, and I will keep you updated. - MMiller (WMF) (talk) 00:05, 10 October 2018 (UTC)[reply]

Thanks for looking into this, MMiller (WMF). For example, after logging out and logging in again, when I visit Wan Mohamad Nazarie Wan Mahmood, the page curation toolbar is not open, and no "mark as patrolled" link is displayed. when I click on "curate this article" it opens the toolbar, but that now no longer has a way to close it. --Vexations (talk) 00:13, 10 October 2018 (UTC)[reply]

@MMiller (WMF): My experience mirrors Vexations. If I open a NPP from the queue I get the toolbar (no doubt thanks to ?showcurationtoolbar=1) but if I navigate directly to any page in the queue I do not ever get the toolbar. This is different than what I originally reported which was just affecting some pages and where if I navigated directly most pages would still automatically show the toolbar. Best, Barkeep49 (talk) 00:17, 10 October 2018 (UTC)[reply]

I noticed the same problem several days ago. If I navigate to a new page, I do not see a toolbar, but I still see a link inviting me to mark the page as patrolled (similar to e.g. such links on user pages). If I click the link, it disappears, but the page does not make it to my review log.--Ymblanter (talk) 07:54, 10 October 2018 (UTC)[reply]

MMiller (WMF) - just finished promoting a few drafts in AFC (on an iPad nonetheless) and love the tools (copyvio detect, etc.) being in the drop down menu at my disposal. Also love that the newly promoted page already has the curation tool in place and it’s checked ✅ as reviewed, so we’re now getting twice the work done in half the time. Thank you for this major improvement. ^{Atsme✍🏻📧} 13:42, 15 October 2018 (UTC)[reply]

redirecting talkpage(s) here

There is clear consensus to redirect/merge the pages discussed below, except for Wikipedia talk:Page Curation/Suggested improvements. As it is mostly about the technical side of a toolset, and not exactly about the immediate process of page reviewing; it should remain attached with its parent page for better convenience. I will perform the merger over the next 24-48 hours. Regards, —usernamekiran(talk) 00:26, 20 October 2018 (UTC)[reply]

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.

Hello. In February 2018, I suggested to redirect/soft redirect Wikipedia talk:Page Curation to here. There is no point in having discussions scattered over multiple vrnues which arent watched by many. In the original discussion, there were no opposes, and two supports. I think we should discuss it again here, including any other talkpages that might require to be redirected here. —usernamekiran(talk) 08:35, 13 October 2018 (UTC)[reply]

Updates

Currently only Wikipedia talk:New pages patrol/School redirects here (excluding shortcuts).

From the header of this talkpage:

"Curation tool" links to Wikipedia talk:Page Curation/Help (no redirect). The talkpage of Wikipedia talk:Page Curation/Help redirects to Wikipedia talk:Page Curation.
Ppage feed" links to special:newpagesfeed.
The "R&D" section links to Wikipedia:The future of NPP and AfC (no redirect). It has the talkpage Wikipedia talk:The future of NPP and AfC. I think this should not be redirected here, for a few different reasons.
The "suggestions" section links to Wikipedia:Page Curation/Suggested improvements. Talkpage of that has been edited 20 times in total, including a "wrong venue" discussion, and closing of it.
"Coordination" section is for co-ordination of the project, mostly used for preparing the newsletters. Other co-ordination related stuff usually takes place here. The talkpage of co-ordination isnt a redirect, but mostly inactive.
"Reviewers" section Standard wikipedia user rights page. The talkpage of it, is this page. —usernamekiran(talk) 13:30, 14 October 2018 (UTC)[reply]

Proposal

I hereby formally propose to redirect following three pages to "Wikipedia talk:New pages patrol/Reviewers", and to move their archives to the archives of this page.

—usernamekiran(talk) 13:30, 14 October 2018 (UTC)[reply]
Note: I can perform the merger if others think it would be too boring/lengthy/complicated, and/or time consuming. —usernamekiran(talk) 13:30, 14 October 2018 (UTC)[reply]

Survey

Based on how I was quite unaware of what was going on at that talk page - yes, seems like a good idea :) --Elmidae (talk · contribs) 11:01, 13 October 2018 (UTC)[reply]

Still in favour post-update. Let's streamline this a bit. --Elmidae (talk · contribs) 13:52, 14 October 2018 (UTC)[reply]

I've suggested this at least 3 times, so I would be in favor, but you may want to find and read the past discussions on this. Natureium (talk) 13:06, 13 October 2018 (UTC)[reply]

Here is what I believe to be the most recent discussion on this topic. Best, Barkeep49 (talk) 16:56, 13 October 2018 (UTC)[reply]

Support: yes, this makes sense. --K.e.coffman (talk) 16:34, 13 October 2018 (UTC)[reply]

pinging @Elmidae, Natureium, and K.e.coffman:, as they had commented before the proposal was updated. —usernamekiran(talk) 13:33, 14 October 2018 (UTC)[reply]

Yes, redirect all, unless #2 needs to stay put. --K.e.coffman (talk) 04:34, 16 October 2018 (UTC)[reply]

Support — Insertcleverphrasehere ^{(or here)} 14:29, 14 October 2018 (UTC)[reply]
Support 1 & 3. Not sure about 2. Best, Barkeep49 (talk) 15:12, 14 October 2018 (UTC)[reply]
support--Ozzie10aaaa (talk) 15:28, 14 October 2018 (UTC)[reply]
Support except for Wikipedia talk:Page Curation/Suggested improvements which should stay attached to Wikipedia:Page Curation/Suggested improvements, which should stay as a reminder of how the WMF neglecteth its children. ^Thanks,L3X1 ◊distænt write◊ 13:04, 15 October 2018 (UTC)[reply]
Support - organize, organize, organize - ❤️ - thanks for all you do, Kiran! ^{Atsme✍🏻📧} 13:33, 15 October 2018 (UTC)[reply]
Support - Consolidation is beneficial. Vermont (talk) 15:01, 15 October 2018 (UTC)[reply]
Support TonyBallioni (talk) 15:03, 15 October 2018 (UTC)[reply]
Support - consolidation cuts down on wasted time. Onel

5969 ^{TT me} 11:59, 17 October 2018 (UTC)[reply]

Support — Per reasoning put forth by Usernamekiran; one of the few instances in which consolidation is good. Regards, SshibumXZ (talk · contribs). 07:44, 19 October 2018 (UTC)[reply]

The discussion above 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.

Update

I finished the redirecting/mergers of the talkpages here. The archives of the redirected talkpages have been moved into the subpages of Wikipedia talk:New pages patrol/Reviewers/Archives/Page Curation/, and Wikipedia talk:New pages patrol/Reviewers/Archives/Coordination/ accordingly. I have also added an archive box (below the current one) of the moved talkpages. Regards, —usernamekiran(talk) 23:25, 22 October 2018 (UTC)[reply]

@Usernamekiran: thanks for taking care of this. — Insertcleverphrasehere ^{(or here)} 12:41, 24 October 2018 (UTC)[reply]

New bot trial for copyvios

Hello reviewers. Please see Wikipedia:Bots/Requests for approval/EranBot 3 for a bot task that will soon be trialing. If you have any questions, or see any issues please let us know at Wikipedia:Bots/Requests for approval/EranBot 3. — xaosflux ^Talk 18:39, 15 October 2018 (UTC)[reply]

What does that mean for NPP? Natureium (talk) 18:47, 15 October 2018 (UTC)[reply]

MMiller (WMF) is this bot doing the work discussed as part of AfC/NPP enhancements underway or is this a separate effort? Best, Barkeep49 (talk) 19:03, 15 October 2018 (UTC)[reply]

Also asked at the BRFA, this had some sample runs on betawiki, but I'm not seeing an interface to use it there either? — xaosflux ^Talk 19:35, 15 October 2018 (UTC)[reply]

During the trial period you'll need to add "copyvio=1" to the Special:NewPageFeed URL to see the interface changes. So https://en.wikipedia.org/wiki/Special:NewPagesFeed?copyvio=1. Nothing has been tagged as a potential copyvio yet, so not much to see at the moment. You can watch what gets flagged by going to the logs at https://en.wikipedia.org/wiki/Special:Log?type=pagetriage-copyvio. Ryan Kaldari (WMF) (talk) 20:19, 15 October 2018 (UTC)[reply]

@Ryan Kaldari (WMF):I'm sorry to be dense but is that a "yes" that this is tied to this project? Best, Barkeep49 (talk) 20:56, 15 October 2018 (UTC)[reply]

Barkeep49 and Natureium -- yes, this is the trial period for the bot written by the Growth Team and ערן that will serve copyvio detection results from CopyPatrol into the New Pages Feed as part of this project. I'm sorry that this has been momentarily confusing -- I had not yet been through the release process for a bot, and I didn't know this trial period would take place. But yes, you will be able to test out copyvio detection at https://en.wikipedia.org/wiki/Special:NewPagesFeed?copyvio=1 within a couple days. We're expecting it to be the same functionality that the community already tested in Test Wiki. Once the bot starts populating the feed, I'll let reviewers know that there is something to play with. -- MMiller (WMF) (talk) 22:43, 15 October 2018 (UTC)[reply]

Appears testing has begun. — xaosflux ^Talk 11:18, 16 October 2018 (UTC)[reply]

I checked the first one on the log - John Bertolino (photographer) - 7.4% chance, and all were the name of a school. I’m wondering if there should be a higher minimum percentage before it’s logged as a potential copyvio. ^{Atsme✍🏻📧} 12:29, 16 October 2018 (UTC) ^Adding... checked the 2nd Dua Allahumma kun li-waliyyik - it came up 37.5% vio unlikely - based on quoted passage. I always check for copyvios anyway, and the main advantage I see is having the tool in the drop down menu for convenience. Is there more that I’m not seeing? 12:52, 16 October 2018 (UTC)[reply]

Two of the three I checked were COPYVIOS and have been deleted as such, Herbert E. Meyer which copied a speaker's bio for him and Baniaganti S. N. Academy School & College which was also a G11. The third was Dua Allahumma kun li-waliyyik which correctly triggered the alert but had a long block of text (a prayer) which is going to be OK to use. I would say those three results were very promising. Best, Barkeep49 (talk) 13:30, 16 October 2018 (UTC)[reply]

@Atsme: If you redo your lookup of John Bertolino (photographer) with the "Use Turnitin" option turned on, you'll see that Turnitin actually caught much more duplicated content than Google did. (You can see the copied content here and here.) Most of that content is quotation and bibliography (and thus OK), but it seems to have functioned correctly. There is a minimum percentage before an edit is flagged, but I don't remember what the current threshold is set to. If it seems too sensitive consistently, let us know. Ryan Kaldari (WMF) (talk) 16:32, 16 October 2018 (UTC)[reply]

Thx, Ryan - will do. ^{Atsme✍🏻📧} 16:38, 16 October 2018 (UTC)[reply]

Copyvio detection ready for testing

Hi all -- I just wanted to post here that copyvio detection is ready for reviewers to test in the New Pages Feed. Thanks to those of you who have already been trying it out after Xaosflux's official announcement that the bot was deployed for its trial period. Here's how you can test the new features:

Go to this URL, instead of the usual New Pages Feed URL.
Open the "Set filters" menu and select "Copyvio" under "Potential issues".
This will filter to the pages that have been flagged by CopyPatrol (via the Turnitin service) as having revisions with potential violations.
You can click the "Copyvio" link in each entry to inspect the potential violating text in the CopyPatrol interface.
Sometimes, the reviewers working in CopyPatrol will already have deleted the violating text, deleted the page, or marked the page as "No action needed".

This testing period will continue into next week, at which point we'll decide whether we're ready to make the feature available at the usual URL. If you have feedback, reactions, or questions, please post here or on the project's talk page. And to read more about the specifics of this implementation and the rules behind how it works, check out this project update. -- MMiller (WMF) (talk) 23:15, 17 October 2018 (UTC)[reply]

RfDs in the New Pages Feed

Over the past week there have been two incidents where about 400 total redirects were mass nominated for deletion (unicode & Australian rail stations). Since these were redirects that were no longer redirects they appeared in the New Pages Feed. I asked MMiller (WMF) if it was possible to treat these like articles nominated for deletion for purposes of filtering the queue. He said probably if there was community support. I am asking here for community support.

Support as proposer. Best, Barkeep49 (talk) 01:22, 16 October 2018 (UTC)[reply]
Support If they are nominated for deletion, then they should be filtered by the 'nominated for deletion' tick box, regardless of whether they are redirects or articles. If you want them to appear in your feed, you can simply leave the 'nominated for deletion' box ticked at Special:NewPagesFeed. — Insertcleverphrasehere ^{(or here)} 03:45, 16 October 2018 (UTC)[reply]
Support ~ Araratic | talk 04:11, 16 October 2018 (UTC)[reply]
Oppose as this defeats the purpose of why we originally decided to have redirects turned into articles in the New Pages Feed: it's one of the easiest ways to sneak paid spam in. As pro-WMF as I am, I'm skeptical of any solution to this problem that wouldn't make the more important issue of catching redirect hijacks more difficult. Additionally, the easiest solution here is to tell anyone who nominates 400 redirects for deletion to stop being disruptive, because that is what nominating that large a number of redirects for RfD is. It floods our capacity both in NPR and at RfD for things that 99/100 don't really matter and are only commented on by a very small subsection of the community. TonyBallioni (talk) 04:34, 16 October 2018 (UTC)[reply]

@TonyBallioni: I am not suggesting any redirects or former redirects leave the feed. Simply that "redirects" with the RfD template be marked with the trash icon and be able to be sorted as nominated for deletion with the now working filtering options. Best, Barkeep49 (talk) 04:42, 16 October 2018 (UTC)[reply]

Meh. I don't really see any benefit to that, but I thought you meant filtering of out the feed rather than the filter list. Not sure how much that goes with the WMF's goal to make Page Curation wiki-agnostic, which is a reason to oppose it, but I guess that wouldn't really harm anything. I guess you can make this "oppose as a waste of limited human resources when there are probably more pressing concerns" since the number of redirects at RfD is normally substantially less than 400. TonyBallioni (talk) 04:48, 16 October 2018 (UTC)[reply]

Compromise (ec x3)Allow them to show up per TB, but have the abilty to filter them out.^Thanks,L3X1 ◊distænt write◊ 04:49, 16 October 2018 (UTC)[reply]
support--Ozzie10aaaa (talk) 10:25, 16 October 2018 (UTC)[reply]

All public Logs don't show 'patrolled by' when patrolled via Twinkle

Tracked in Phabricator
Task T207477

As the Page curation tools currently won't load up, I used Twinkle to patrol Rachel Green (biologist). This adds it to my patrol log, but not my page curation log. It is marked as 'reviewed' at Special:NewPagesFeed, but doesn't show under 'all public logs' for the page (if patrolled via the page curation tools, this does show up in 'all public logs for the page). Why does 'all public logs' contain the log entry from the page curation log, but not the one from the patrol log? Is this a bug? — Insertcleverphrasehere ^{(or here)} 13:57, 16 October 2018 (UTC)[reply]

I logged this as a Phab task as it appears that this is a bug. — Insertcleverphrasehere ^{(or here)} 21:52, 20 October 2018 (UTC)[reply]

Community Wishlist Proposal

Hi everybody,
I trawled through the Suggestions page for as much stuff as I could. I filed Phabricator tasks for all of them, which are listed below. Now we need to decide what of these tasks we should add to the Community Wishlist proposal. Do you want to add all of them? Do you dislike one or two? Do you want to only submit a few key elements? Please add your opinions to the 'Survey' section below, and any other comments in the 'Discussion' section.

The deadlines for the Community Wishlist Survey are:

Submit, discuss and revise proposals: October 29 to November 11, 2018
Community Tech reviews and organizes proposals: November 13 to November 15, 2018
Vote on proposals: November 16 to November 30, 2018
Results posted: December 3, 2018

So we have a bit of time to make up our mind on what the proposal should contain. Sorry the list is so long, but the WMF has been quite neglectful. — Insertcleverphrasehere ^{(or here)} 16:08, 19 October 2018 (UTC)[reply]

Task List/Prioritising tasks

Per the Discussion section below: I hear what you guys are saying, and we need to prioritise what tasks we should ask for first. To this end I have organised the tasks into a sortable table below where I have estimated the difficulty of the task, as well as the estimated benefit to New Page Patrol. You can sort this and see that some items are both high impact, and easy to accomplish (higher priority). Some are low impact, but more difficult to accomplish (probably lower priority). Please feel free to fill in the 'Priority' column with your opinions on the priority of items. I have also noted where we have a script which already accomplishes the task, and where Twinkle is used instead. — Insertcleverphrasehere ^{(or here)} 11:21, 20 October 2018 (UTC)[reply]


Category	Phab ID	Topic	Difficulty	Benefit to NPP	Priority?
Bug Fixes:	*T169441:	Capacity to handle 2nd+ AfD nominations (currently bugs out and posts to the bottom of the first AfD page)	Medium	High^T	High (bug that means it isn't safe to use PC tools to AfD)
Bug Fixes:	*T207477:	'All public logs' for a given page lists the 'page curation log' reviews, but not 'patrol log' reviews	Unknown	Medium	High (sometimes difficult to find who reviewed the article if they used Twinkle)
Bug Fixes:	*T157046:	Redirects with RfD tags should still display in the New Pages Feed as redirects (actually as 'Nominated for Deletion' per above section)	Easy?	Medium	Moderate (consensus above)
Bug Fixes:	*T92621:	Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed (articles converted to redirects are sent to the feed, they should be sent back out again automatically if that edit is reverted)	Hard	Medium	High (results in waste of reviewers time, should be automated)
Bug Fixes:	*T157048:	Redirects converted into articles should appear in the New Pages Feed indexed by the date of creation and creator of the new article, not of the original redirect	Medium	High	High (Frequent annoyance drops them at the back of the queue, or worse, the middle)
Bug Fixes:	*T207234:	Page Curation Tools should automatically remove 'Template:New unreviewed article' when the article is marked as reviewed	Easy?	Low	High (should be easy to fix, obvious oversight)
Page curation toolbar:	*T207485:	Enable page curation tools to be loaded on any page (optionally)	Easy	High	High
Page curation toolbar:	*T207225:	Add "welcome newbie" button to Page Curation Toolbar	Medium	Low^T	Low?
Page curation toolbar:	*T207435:	Decline CSD added to Page Curation Toolbar	Medium	Low^**	Moderate?
Page curation toolbar:	*T207230:	Adding some missing features to Page Curation Toolbar for CSD tagging	Medium	Medium^T	Moderate?
Page curation toolbar:	*T124396:	Allow moving to draftspace and tagging accordingly (add draftification to page curation tools)	Medium	High**	Low (We have a good script, but this could also be ported directly)
Page curation toolbar:	*T207441:	Page curation 'High Quality Submission' options (DYK and autopatrolled suggestion message options for creators)	Easy?	Medium**	Low (would be useful but not essential)
Page curation toolbar:	*T207438:	Page curation toolbar: allow a reviewer to mark a page as 'under review' and warn others at Special:NewPagesFeed	Easy?	Medium	Moderate
Page curation toolbar:	*T207439:	Dragable Corners on Page Curation toolbar windows (for resizing)	Easy?	Medium	High (per DGG, see talk below)
Page curation toolbar:	*T207442:	Send Message to creator without needing to 'unreview'/'re-review' the article	Easy?	High	High (repeatedly requested annoyance)
Page curation toolbar:	*T207444:	Page Curation tools, option to 'report editor to AIV' for blatantly blockably created pages (when CSD tagging articles)	Medium	Medium^T	Moderate (would be nice to bring it up to Twinkle standard)
Page curation toolbar:	*T207450:	Requesting Revdel built into Page Curation Tools.	Medium	High**	Low (we have a good script currently)
~~Page curation toolbar:~~	*T207451:	~~Add `{{sources exist}}` to Page Curation Toolbar~~	Done	~~Low~~^T	Can be accomplished on wiki -requested and being tested
~~Page curation toolbar:~~	*T207482:	~~Curation toolbar opt-out in preferences~~	Done	~~Medium~~	Last gadget in the list at preferences.
Special:NewPagesFeed filtering:	*T169120:	Allow filtering by no citations in page curation	Unknown	High**	Moderate (NPP browser has this functionality)
Special:NewPagesFeed filtering:	*T167475:	Allow filtering by date range in Special:NewPagesFeed	Hard?	High	High (repeatedly requested, even the NPP browser doesn't do this)
Special:NewPagesFeed filtering:	*T207238:	Special:NewPageFeed filter by estimated public interest (e.g. filter by pageviews to enable prioritisation of high traffic articles)	Hard?	High	High (We are article triage, and this would be VERY useful)
Special:NewPagesFeed filtering:	*T189929:	Add "previously deleted" as a possible issue (flagged in red) in the New Pages Feed/Page Curation Tool	Medium	High**	High (to help identify COIs)
Special:NewPagesFeed filtering:	*T157051:	Implement a new icon for patrolled pages that have maintenance tags in the New Pages Feed	Medium?	Low	Low (not essential as once 'reviewed' they aren't our problem)
NPP Messaging System:	*T207452:	Reviewer Notes system in Page Curation Tools: system for reviewers to flag talk page comments on new pages to other reviewers	Hard?	High	High (per unanimous strong support in section below)
NPP Messaging System:	*T207443:	Tagging Feedback in Page Curation Tools should also be sent to talk page	Medium?	High	High (per unanimous strong support in section below)
Uncategorised:	*T207446:	Automatically flag articles that have been overwritten as 'unreviewed'	Hard	High	Moderate (Looks like it might be very difficult, but this would be good for the Wiki)
Uncategorised:	*T207237:	Page Curation Tools to add userspace CSD Log/PROD Log functionality	Medium?	High^T	High (repeatedly requested, hard to track CSD logs in PC Log)
Uncategorised:	*T204464:	Page Curation messages should be configurable (not hard-coded into mediawiki) --also, related: to have different messages for users of different levels (an editor that is newly autoconfirmed should receive a different message than an autopatrolled user)	Medium?	High	Very High (repeatedly requested, we want to be able to fix these issues ourselves)
Uncategorised:	*T204465:	Allow users to disable Page Curation's "I have unreviewed a page you curated" message	Medium?	Low	Low (might be bypassed by T204464 anyway)
Uncategorised:	*T207437:	Special:NewPagesFeed auto-refresh (similar to the 'Live Updates' button for watchlists)	Hard	Medium	Discuss (might be very hard for moderate benefit)
Uncategorised:	*T207436:	Restrict tagging of articles with Page Curation tools to no more than 3 tags at a time (prevent tag bombing)	Easy?	Low	Low (mainly for new reviewers, but not an issue with veterans; also, it might get in the way sometimes)
Uncategorised:	*T42135:	Make "redirects" included by default in PageTriage (tick the redirect button by default for new patrollers)	Easy	Low	Low (mainly to clue new reviewers that redirects are part of the job)

** - Other tool exists (linked).
^T - Currently accomplished via Twinkle.

Survey: What do you support adding to the Wishlist Proposal? What do you oppose?

Support 'all' for now - At present, I'm happy sending through the full list as our proposal, as well as any other good ideas people come up with. But I definitely want to hear some other opinions on the subject and I am super happy to change my mind. Update: Prioritising items is very important if we plan to submit all, and in that case some iems might be so low on the priority list that we might decide we don't need them. We need to be careful not to rub the community the wrong way by asking for too much. — Insertcleverphrasehere ^{(or here)} 16:10, 19 October 2018 (UTC)[reply]
- Support non-specific submission OK. I've changed my mind a bit. I agree with pretty much everyone a bit, and thing that Kudpung hit it on the head the most with "the individual fixes and features should simply be one request without tabulating the individual items." This would be a request for ongoing support, particularly for High priority items. More in the discussion section below. — Insertcleverphrasehere ^{(or here)} 16:08, 23 October 2018 (UTC)[reply]
Support sending through all bug fixes as one wishlist item and then 2 - 4 functional improvements I think we need to be mindful of the broader community here as there are other non-NPP things which should, realistically, get done in 2019. If we do this right we're going to be a really large voting block. If we do it wrong we're going to get nothing. So I'm thinking we think of bug fixes as one request and then selectively choose a few other items from the wishlist for us as an NPP community to get behind. Best, Barkeep49 (talk) 16:19, 19 October 2018 (UTC)[reply]
support all--Ozzie10aaaa (talk) 16:27, 19 October 2018 (UTC)[reply]
Support all — I don't see a proposal that won't beneficial to a patroller/reviewer. Regards, SshibumXZ (talk · contribs). 22:20, 19 October 2018 (UTC)[reply]
I am categorically opposed to proposing all. It is pointy and obnoxious and will backfire spectacularly. Some of the proposals are simply misguided and even wrong. I'm going to respond in great detail later this weekend, when I have a bit more time, but PLEASE, PLEASE let's do everything we can to show that we are serious and competent. [[7]] is required reading, I think. --Vexations (talk) 22:25, 19 October 2018 (UTC)[reply]
Support sending those items which have been marked as of high benefit barring the ones about integration of draftification and revision-deletion, for which our scripts are a bit too good.∯WBG^converse 12:55, 21 October 2018 (UTC)[reply]
Support all those that have been marked as high priority. See my remarks in the comments section below. Kudpung กุดผึ้ง (talk) 02:00, 22 October 2018 (UTC)[reply]
Support items marked "high priority". CASSIOPEIA^(talk) 14:02, 22 October 2018 (UTC)[reply]
Support the high priority ones', but mark "Page Curation messages should be configurable " as especially high priority. Of the Medium ones, I'd want most the Resizable feature (which should I think be easy). I also agree with sending the bugs through now as bugs. DGG ( talk ) 05:47, 23 October 2018 (UTC)[reply]
Support high priority, and agree that the messages need to be configurable. If there's a way to prevent curation messages from auto posting to socks, blocked or banned creators would be helpful, too. ^{Atsme✍🏻📧} 17:50, 23 October 2018 (UTC)[reply]

@Atsme: I know that Winged Blades of Godric was working on a fix so that the G5 deletion talk page notice doesn't get sent out. This can be done on-wiki acording to him via the .js pages. See my talk page for more info. — Insertcleverphrasehere ^{(or here)} 11:56, 24 October 2018 (UTC)[reply]

Atsme, Insertcleverphrasehere:-- Live on test.wiki (which has it's disadvantage that I can't localise the mw.messages) along with a feature of marking drafts under review (to prevent reviewers duplicating each other's work), asking for hist-merges (which is necessary in case of botched copy-paste from drafts and do happen) and asking for revision-deletion, in case of selective-(non-G12able)-copyvio.Another miscellaneous tag as to marking that sources exist for the topic, has also been added.

I do plan to test out the draftification feature, under the deletions tab, forking Evad's script, in a few days' time.

And, whilst I've already asked for a selective implementation over here through an edit-request, it's taking a lot more time for them to get executed courtesy the un-bundling of the right from admins and absence of a separate interface-edit-requests queue et al.∯WBG^converse 12:33, 24 October 2018 (UTC)[reply]

See User:AnomieBOT/PERTable.

Also, it might be prudential to note that I am trying to align the t/p templates that are generated by the NPP-CSD-module with that of Twinkle.Language and all that stuff by taking the better from both of them.If there are any issues, please let me know:-)∯WBG^converse 12:38, 24 October 2018 (UTC)[reply]

Thanks for going the extra mile, WBG. It is much appreciated by this editor, for sure! ^{Atsme✍🏻📧} 14:09, 24 October 2018 (UTC)[reply]

@Winged Blades of Godric: What's the best way for those of who are interested to test this out? Best, Barkeep49 (talk) 14:57, 24 October 2018 (UTC)[reply]

Barkeep49, See my message at ICPH's t/p.∯WBG^converse 15:00, 24 October 2018 (UTC)[reply]

Support all. I think all of these would be significant improvements.--SkyGazer 512 ^{Oh no, what did I do this time?} 13:22, 24 October 2018 (UTC)[reply]
Support high priority only per Vexations above and Elmidae just below. Ajpolino (talk) 05:57, 25 October 2018 (UTC)[reply]

Discussion (feel free to also suggest new ideas here)

@Barkeep49: per your !vote in the survey above: I don't mind the idea of separating bug fixes from improvements. One way to mitigate the workload would be to also have the list of improvements organised by priority level. It is reasonable that our list is really long, we have been neglected for several years. Not all of the above stuff needs to be finished tomorrow, or even in 2019. I expect that some of the lower priority items on the above list will still have the team working on them into 2020, that's OK, but they need to know that NPP is a core function of the wiki that needs support. If they need to hire an extra programmer to work on tools for us, I suggest we nominate Evad37 for the job 😉. — Insertcleverphrasehere ^{(or here)} 22:12, 19 October 2018 (UTC)[reply]

I certainly agree the curation toolbar is an essential function. I also support the idea of prioritizing in theory but worry about our own coordination in something like that. Gaining some buyin for a smaller group we could largely support and then actually showing up at the wishlist to support feels challenging enough. Trying to just overrun the community wishlist doesn't feel in the spirit of a consensus based project. Best, Barkeep49 (talk) 22:51, 19 October 2018 (UTC)[reply]

I agree with Vexations, and Barkeep49. We should categorise them as "wishlist", bugs, and necessities. We should also prioritise them: if something can be done with twinkle, we can live with it for a little while more. —usernamekiran(talk) 01:20, 20 October 2018 (UTC)[reply]

I've got to agree with Vexations - dropping the entire list into the hopper will look like obnoxious and entitled behaviour, since we would essentially be claiming all available development effort for our corner of WP. Nevermind that a good case could be made for superior importance of this stuff; if we tick off everyone else we shan't get anything. Let's isolate a limited number of crucial things and concentrate on those. I'll ponder. --Elmidae (talk · contribs) 08:46, 20 October 2018 (UTC)[reply]
Yeah, I think we got to work out whether we want Page Curation to duplicate or compliment Twinkle and then from there work out which features we want to request, and obviously the bugs need to be fixed which could be done either separately or bypassing the wishlist altogether. ~ Araratic | talk 11:10, 20 October 2018 (UTC)[reply]
I always thought page curation tool compliment twinkle. As almost all (if not all) reviewers use twinkle. Also, it is safe to assume that before gaining the reviewer perm, the editor is familiar/comfortable with twinkle. I still find it difficult to search for few particular maintenance tags in the tool if I want to simultaneously want to send message to creator. In such cases, I add tags using twinkle (it marks page as patrolled/reviewed), then I unreiview it; and then review it again with sending the message. There are small things like these, which make me want to keep the tool and twinkie separate from each-other, doing different tasks. We can, should add other specialist functions to the tool. —usernamekiran(talk) 00:43, 21 October 2018 (UTC)[reply]
@Usernamekiran: Yeah, but they use Twinkle because the page curation tools has missing features (not actually that many features, there are only a few tasks above which need updating in this way--marked with a 'T'). The other main reason reviewers use Twinkle is that the page curation tools cannot be used on articles that are not in the new page feed. This is a major failing, and I think that I would probably use the Page curation tools for everything if they fixed the deletion issues, userspace CSD logs, and allowed ability to curate other articles/drafts. — Insertcleverphrasehere ^{(or here)} 07:09, 21 October 2018 (UTC)[reply]
I asked this because the question we need to answer is whether we want WMF to use its 'limited resources' on NPP for duplicating things that we can already do (albeit a bit inconvenienced) or to create new features that would help more. I personally feel the reviewer notes system would be very useful and a good thing to put on the wishlist. ~ Araratic | talk 09:22, 21 October 2018 (UTC)[reply]
I would put previously deleted as a high priority, as it helps identify likely COI-based editing and promotionalism. --K.e.coffman (talk) 18:10, 20 October 2018 (UTC)[reply]
I think the individual fixes and features should simply be one request without tabulating the individual items. I do concur with Elmidae however, as regards the load on the wishlist. However, I remain totally adamant that our requirement is not something for the wish list at all. As the only firewall against unwanted new pages, this is a core Wikipedia function and a dedicated team of developers should be allocated to it. The WMF should be helped to understand that the entire page Curation system and its feed was a WMF development designed to make patrolling/reviewing easier as a consolation prize in the aftermath of their refusal to implement the consensus for ACTRIAL 7 years ago. It was not intended as a compliment to Twinkle; it was fully inteended to be a replacement for the functions of Twinkle that concern new page patrolling.I did actually work closely (per Skype videos including live patrolling) with the devs and the VP of the WMF on its development at that time, but they did not include all my ideas and suggestions. At one stage, one staff member decided that the WMF would no longer continue to support the process they had developed.

As regards the mentions here of Twinkle, one of the main objectives in creating Curation was to draw patrollers away from Twinkle and encourage them to standardise on Curation. This was also the main objective in creating a user right for New Page Reviewing two years ago, although this still left open (by a narrow consensus at an RfC) the possibility for all users, whether experienced or not, to tag pages for any of the deletion processes, using Twinkle. The current effort should therefore be to incorporate into Curation any of the features that are in Twinkle but not in Curation, and encourage more, experienced users to apply for the New Page Reviewer right..Kudpung กุดผึ้ง (talk) 02:31, 22 October 2018 (UTC)[reply]

Thank you for your comments Kudpung. This won't be a normal submission to the Community Wishlist. So we should just say what we really want: Ongoing support for improving the NPR process as we respond to the constantly changing landscape of New Page Review. Especially with targeting tasks which have been highlighted as high importance to the project. We should highlight that we don't want to be going through the wishlist, but have been forced to. And we should also perhaps state that we would ideally like to have additional resources allocated to new page review, so that we do not adversely impact the development of other stuff on the Community Wishlist from getting done. I'm getting closer to an idea of what I think the submission should look like and I'll draft something soon and put it to you guys to have a look at. — Insertcleverphrasehere ^{(or here)} 16:17, 23 October 2018 (UTC) [reply]

And we should also perhaps state that we would ideally like to have additional resources allocated to new page review, so that we do not adversely impact the development of other stuff on the Community Wishlist from getting done. I suggest this bears highlighting as an important point (both "politically" and for practical future development). --Elmidae (talk · contribs) 19:38, 23 October 2018 (UTC)[reply]

Off Topic

Not to mention the fact that the devs have now started blocking our people from p;osting on Phab. Tht's their way of finally sweeping all the tickets under the carpet that Insertcleverphrasehere has been creating. Thers's another WMF critical Signpost article lurking there... Kudpung กุดผึ้ง (talk) 11:14, 24 October 2018 (UTC)[reply]

Er... they have? That's a bit rich. --Elmidae (talk · contribs) 11:50, 24 October 2018 (UTC)[reply]

Well, that happened once, and he did swear; but not a good look on their part. Lets wait and see before we jump into full conspiracy theory journalism mode ;D — Insertcleverphrasehere ^{(or here)} 11:52, 24 October 2018 (UTC)[reply]

Please observe the Code of Conduct when contributing on Phabricator. What's described above falls squarely into "unacceptable behavior". If this group decides to endorse, condone or tolerate it, I'm out of here. I will have nothing to do with abuse directed at developers. This has to stop, now. --Vexations (talk) 12:20, 24 October 2018 (UTC)[reply]

Vexations, I agree with you that the Code of Conduct should always be followed, and also agree that WBG was being too vociferous; though I do understand where he is coming from. He did drop an F-bomb, however, I don't see anything in the Code of Conduct that explicitly bans 'strong language', so his ban on Phab (even if temporary) does seem to be a punch at daring to complain (especially given that both comments cited are to do with WMF overreach).[8] — Insertcleverphrasehere ^{(or here)} 12:37, 24 October 2018 (UTC)[reply]

Reviewer Notes System

ICPH has changed status above based on discussion here Best, Barkeep49 (talk) 18:11, 23 October 2018 (UTC)[reply]

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.

A 'Reviewer notes' system could be VERY useful (task T207452 in the table above). What I envision: Reviewers could write a comment in a field in the Page Curation toolbar, which would then copy this note to the talk page and create a section with a unique header "New page reviewers' comments" (or similar). Also, all messages sent to authors would also be copied to this section on the talk page (task T207443 in the table above). The page curation tool would scan for a section with this exact header whenever the page was loaded up and automatically notify future reviewers that another reviewer left a comment, this ensures that whenever another reviewer looks at the page, they immediately know that someone else already left a note on the talk page. While the talk page can currently be used in this manner in the same way, reviewers won't always check this for new articles, as there are rarely content comments on new articles. Reviewers could then comment via the talk page directly (under the same header). I think this would be a useful feature. I would change the NPP flowchart, adding a bit saying that if at any point you are unsure and decide to stop the review, you should leave a note using this system with your findings so far. While a script could be easily written to automatically make a small window briefly pop up saying: "There are reviewer comments on the talk page!" (at least for as long as the article is in the NewPagesFeed), this really needs to be integrated in the PC tools if you want to have the sort of buy-in that will actually make it work (e.g. when you use the system you want some assurance that all reviewers/admins will also be notified of comments). Please discuss! — Insertcleverphrasehere ^{(or here)} 07:45, 21 October 2018 (UTC)[reply]

Strong support-∯WBG^converse 13:11, 21 October 2018 (UTC)[reply]
To make all patrollers/admins see it, one could put the script in MediaWiki:Group-patroller.js. Though of course integration into the actual page curation tools would be ideal. Galobtter (pingó mió) 13:25, 21 October 2018 (UTC)[reply]
support--Ozzie10aaaa (talk) 13:26, 21 October 2018 (UTC)[reply]
Support - excellent idea. Onel5969 ^{TT me} 17:11, 21 October 2018 (UTC)[reply]
Support, K.e.coffman (talk) 23:32, 21 October 2018 (UTC)[reply]
Support This was ICPH's great way of implementing a need I saw so I am pleased to see others supporting it as well. Best, Barkeep49 (talk) 00:16, 22 October 2018 (UTC)[reply]
Strong support - it actually goes far beyond something I have been lobbying for and it is an excellent suggestion. Articles patrolled and tagged with mainenance tags alone, simply become perma-tagged. The creators, especially the SPA, rarely come back to see if their article has been tagged, unless of course they continue to work on the article - which is far from always the case. Many of them are indeed unaware of the existence of article talk pages and personal talk pages, and do not even react to the 'You have new messages' notification when they log in.Kudpung กุดผึ้ง (talk) 02:43, 22 October 2018 (UTC)[reply]
Support – this is a great idea. _signed,Rosguill ^talk 02:47, 22 October 2018 (UTC)[reply]
Support CASSIOPEIA^(talk) 14:02, 22 October 2018 (UTC)[reply]
Support — Per proposal; this seems to be a rather good idea. Regards, SshibumXZ (talk · contribs). 01:57, 23 October 2018 (UTC)[reply]
Support This addresses a number of problems; it reduces duplication of effort by reviewers, improves communication with contributors to a page who are not necessarily the page creator and ensures that reviewers check the talk page as part of the review. --Vexations (talk) 02:42, 23 October 2018 (UTC)[reply]
Very strong support. Along with Kudpung, I've been asking for this from the beginning--and I think it is necessary to the degree that I often do something like this manually. DGG ( talk ) 05:49, 23 October 2018 (UTC)[reply]
Comment Per the strong and unanimous support here, I have recorded the two Reviewer Notes System tasks as 'high' priority. — Insertcleverphrasehere ^{(or here)} 07:36, 23 October 2018 (UTC)[reply]
Support - what a kewl feature!! If we keep getting our priorities satisfied along with all these new features, we're liable to see more editors inspired to review articles!! 😊 ^{Atsme✍🏻📧} 18:09, 23 October 2018 (UTC)[reply]

The discussion above 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.

Do we need solutions, or do we need a toolkit so we can solve problems ourselves

When I was reading over the items in the Wishlist Proposal, it reminded me of an essentially defunct WMF project. Back when the WMF first conceived Flow, they also envisioned something called the Workflow project. Workflow is not specific to patrol, but it could be significant here. The original Workflow concept was badly tied to Flow, but I think the underlying idea has enormous potential if divorced from Flow. As a relatively simple example, consider the steps to nominate a page for AFD:

Add a template at the top of the article.
Create a new page for the discussion. This page will contain some routine AFD wikitext at the top, and add a user-supplied deletion rationale below.
Add that new page to the daily list of AFDs.

An editor could go to the Workflow builder and select options matching those three steps. For step 1 they specify what template to add, for step 2 they supply the standard AFD header text, in step 3 they say where the daily list is. I somewhat simplified things, but it comes pretty close to a point and pick process to define or modify a simple workflow. An admin could then approve that workflow to appear on a Twinkle-type list. (More complicated workflows might need a tech-comfortable editor to be sure that all possibilities are handled correctly.) Depending how powerful the workflow builder is, it could replace Twinkle, many of our work scripts, much of the patrol system, and we could build workflows for many other tasks.

The reason I mention the Workflow project is because I estimate about HALF of these Wishlist items could be fixed by us, on-wiki, if patrol were built around a Workflow type system. We could add or redefine (at least some of) the buttons on the Page Curation Toolbar ourselves, by adding or modifying the workflow for that button.

I also think it's worth noting one of the major motivations the WMF had for Workflows. The WMF can't realistically build and adapt tools like Page Curation to countless other wikis, with their varying needs and varying community processes. (For example Commons adds new deletion-nominations to the bottom of the page of any existing deletion discussion, and small wikis may simply toss assorted tasks onto one Village-Pump type page.) The Workflow system would allow each wiki to copy, modify, or build workflows themselves, as needed.

I don't know if the WMF is willing to revive the Workflow concept. I don't know if they'd be willing to reconceive it independent of Flow. I don't know how much a Workflow builder would be capable of. It would be a major project if they did build it. But I find it painful that the WMF sinks massive resources into questionable projects while allocating a token few percent of time to community requested tasks.

I'm not specifically proposing anything here. I'm tossing this concept on the table to see how much interest it generates. Alsee (talk) 12:31, 22 October 2018 (UTC)[reply]

@Alsee: As for 'Workflows', I don't know much about it, but sounds promising and could be nice as an independent submission to the Community Wishlist. With regards to the Page Curation Toolbar, It actually IS configurable for different language wikis, and at least some of the items above actually are fixable on-wiki by modifying the various .js pages that the toolbar pulls some of its tools from. For example, tags are contained within the .js pages, so we can add/remove tags ourselves, or at least, a tech-admin can. Winged Blades of Godric is actually looking into a number of the tasks that can be completely or partially solved ourselves (see his edits to my talk page, this page, and the suggestions page for more info). Some of the stuff is hardcoded though, like the author messages, which is something that ongoing WMF support would be useful for. — Insertcleverphrasehere ^{(or here)} 12:50, 22 October 2018 (UTC)[reply]

An IFTTT or Zapier for Wikipedia would be a game changer. Even Flow wasn't a bad idea, but its implementation, messing up on-going discussions, was a heavy-handed clumsy disaster. Divorce Workflow from Flow (and its tainted history) and there's the possibility of some interesting & useful developments. Cabayi (talk) 10:47, 25 October 2018 (UTC)[reply]

Copyvio bot testing

Hello Reviewers, the testing for the new copyvio bot tagging has been completed and results are listed at Wikipedia:Bots/Requests_for_approval/EranBot_3#Trial_results. Please review and let us know if you found any technical issues that should prevent this from going to "approved" and running. Best regards, — xaosflux ^Talk 20:42, 22 October 2018 (UTC)[reply]

Old redirect in feed

Tracked in Phabricator
Task T92621

Charles Dickinson (writer) is a year old redirect that got vandalised and reverted in such a way that it was tagged as a New Redirect and showed up here. Just wondering if this is a bug/ can this be prevented... We obviously don't need extra work. MB 01:43, 23 October 2018 (UTC)[reply]

@MB: This has been identified as an issue for quite some time (2015!) and it is in the task list for the community watchlist above as a bug in need of being fixed.

T92621: Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed (articles converted to redirects are sent to the feed, they should be sent back out again automatically if that edit is reverted). — Insertcleverphrasehere ^{(or here)} 06:21, 23 October 2018 (UTC)[reply]

Quick question

Why can't I see when/how this article was created and by whom? How do I find that information? ^{Atsme✍🏻📧} 19:51, 23 October 2018 (UTC)[reply]

@Atsme: Looking at the page history it looks like the page was moved in April of 2016.

If you are looking for the creator of the page that was moved, you'll need to look at the history of The Novo by Microsoft, which indicates it was created as a redirect on January 13, 2009‎. The first substantive content was added on January 11, 2015 by Smilerslove.
If you're wondering who and when the current article at Club Nokia was created, the first non-redirect content after the page move was added by KaukoHaapavesi on October 22, 2018.

Does that answer your question? ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:37, 23 October 2018 (UTC)[reply]

It did answer my question, thank you. Unfortunately, through no fault of your own, it didn't clear-up my confusion. I'm just not grasping why 2 totally unrelated articles were connected at all much less redirected, or why the current header of Club Nokia states: For the venue formerly known as Club Nokia, see The Novo by Microsoft.

Club Nokia was a loyalty program, originally an internet site created by Nokia, not a concert hall or similar venue. Going back even further, why was this edit made in 2015 or this edit in 2016? Was it vandalism or am I totally missing something? ^{Atsme✍🏻📧} 01:15, 24 October 2018 (UTC)[reply]

What don't you get? There is a music venue that used to be called Club Nokia and is now called The Novo by Microsoft. Hence the disambiguation hatnote on Club Nokia. Polyamorph (talk) 03:57, 24 October 2018 (UTC)[reply]

Club Nokia was commingled with The Novo, complete with moves and redirects, so it was not just a dab. ^{Atsme✍🏻📧} 04:19, 24 October 2018 (UTC)[reply]

That's because Club Nokia was The Novo. The website is an entirely different entity and the page was created over a redirect. Nothing untoward here. Polyamorph (talk) 06:30, 24 October 2018 (UTC)[reply]

Perhaps you can explain by whom, when and how the current Club Nokia was created because I am unable to locate the article’s actual edit history. Who authored the material? All I’ve seen to date points back to the move and redirects to The Novo and the name changed Club Nokia which are completely different topics. See my discussion above with ONUnicorn. KaukoHaapavesi is the editor who most recently removed the redirects, and it appears that, according to their TP, they happen to be a Nokia enthusiast (and have already denied any COI), so it’s quite possible they know how/when the current article was created. I can usually find an article’s edit history with a bit a maneuvering through redirects & moves, but for some reason, I’ve been unable to find the edit history for this one - it magically appeared as the result of a redirect. The same applies to the TP history & activity. It is important to know so we can find out if the article was a prior AfD, an AfC submission that was approved and by whom, or was simply created by an autopatrolled user, etc. Perhaps admin Fish and karate can help clear-up the confusion, and is able to trace it back to the actual origin of the current edits that created this Nokia promo. It just appears to me that there should be more to it than an article suddenly appearing as a completed article from a reverted redirect that pointed to an entirely different topic, be it a dab notice or not. ^{Atsme✍🏻📧} 15:47, 24 October 2018 (UTC)[reply]

Hardly a fully formed article, the user created a stub over a redirect, in one edit. Pretty simple to understand. Polyamorph (talk) 16:00, 24 October 2018 (UTC)[reply]

A user with only extended confirmed user rights created an article in main space over a move/redirect of another topic with the same name and you’re ok with that? The user does not have autopatrolled rights, did not use AfC and by doing so, created this mess. Something needs to be fixed. Winged Blades of Godric, Insertcleverphrasehere, any suggestions? What happened is not the customary procedure for creating stubs/articles, and I am a bit concerned by Polyamorph’s nonchalant reception as a reviewer, especially considering the underlying circumstances and the content of the stub itself, not to mention notability issues. The only reason it ended up in the NPP queue is because it was a redirect. I also want to be sure we are not changing anything in the way redirects show-up in the queue, especially in light of this particular situation. ^{Atsme✍🏻📧} 16:47, 24 October 2018 (UTC)[reply]

@Atsme: That's exactly what happened. There was a redirect. KaukoHaapavesi pushed edit, took out the redirect, wrote the content that they wrote, and pushed save. That happens all the time. You seem to think it's unusual - it's not. That's why when a redirect becomes an article it shows up in the new pages feed again. There's nothing wrong with turning a redirect into an article, but the article should be reviewed by NPP. Any user can do what KaukoHaapavesi; even an IP. I'm not sure why you think KaukoHaapavesi created a mess; I don't see a mess. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:53, 24 October 2018 (UTC)[reply]

This does indeed happen all the time, and they are currently sorted into the feed by the date of the redirect creation, rather than the date of article creation, which is one of the issues in the List below that needs to be fixed. If this were fixed, a notice that the article was converted from redirect would also be useful. I'll add that to the request. — Insertcleverphrasehere ^{(or here)} 17:20, 24 October 2018 (UTC)[reply]

Quoting Atsme What happened is not the customary procedure for creating stubs/articles, and I am a bit concerned by Polyamorph’s nonchalant reception as a reviewer, especially considering the underlying circumstances and the content of the stub itself, not to mention notability issues. - yes it absolutely is customary procedure, and I've done nothing wrong. You on the other-hand shouldn't have un-reviewed the page, but not big deal. Please assume good faith on behalf of both the creator and fellow NPPs.Polyamorph (talk) 17:30, 24 October 2018 (UTC)[reply]

Thanks, ICPH. I’ve seen redirects removed and content added to the article that was redirected, but the topic was the same. I have not seen this happen when it involved 2 different topics of the same name. Common sense tells us to create/move the new article/stub with an identifier that distinguishes it from the other, such as Club Nokia (mobile) or (programme) or the like. If it’s not too much trouble, I would be very appreciative if those who are familiar with the repeated occurrence of creating stubs/articles of the same name/different topic over redirects to unrelated/totally different topics would provide a few diffs so I can at least see how these situations have been handled in the past. Oh, and Polyamorph, while we’re here trying to get new tools and procedures implemented/ironed out, how did this mistake occur, and do you have any suggestions how it can be avoided in the future? ^{Atsme✍🏻📧} 17:50, 24 October 2018 (UTC)[reply]

Atsme, since you asked for a dif involving 2 different topics of the same name - Advance America history. It was an article about the payday loan company. On April 22, 2015 I moved the article about the payday loan company to its full name, Advance America Cash Advance, leaving a redirect. On September 29, 2016 I turned the redirect into an article about the political lobbyists. ~ ONUnicorn^{(Talk|Contribs)}problem solving 19:13, 24 October 2018 (UTC)[reply]

You did it properly when you moved it ONUnicorn so it is not the same as simply creating a new stub over the top of a redirect/move with the same exact name but a completely different topic (mobile promotion vs a concert venue). What you did left a proper edit history trail so there was no confusion. That is not what happened with Club Nokia and why I thought it best to bring it up here to hopefully keep it from happening again. Of course we initiate moves and redirects all the time, but we typically make distinctions when naming an article (which helps explain why we initiate some moves) - and we do it properly because when we don’t, it creates confusion. Thank you for going to the trouble of finding that diff - it is much appreciated. ^{Atsme✍🏻📧} 20:50, 24 October 2018 (UTC)[reply]

I don't see how it is any different. There existed an article "Club Nokia" which was the name of a concert venue. This was moved when the name of the club changed to "The Novo by Microsoft", preserving the edit history at the new location and leaving a redirect. Then an editor created a stub at "Club Nokia" about a different entity. There is nothing wrong with this workflow and no editor is at fault. Polyamorph (talk) 21:08, 24 October 2018 (UTC)[reply]

~~I'll be very suprised if anyone will satisfy your request for diffs.~~ Blow me down, kudos to ONUnicorn :) I'm not sure why my talk page history is of any interest to you, but that was a simple mistake the NPP involved re-reviewed the page immediately after, nothing to do with you but thanks for your interest in me. Polyamorph (talk) 18:13, 24 October 2018 (UTC)[reply]

(edit conflict)@Atsme. PRehse accidentally clicked unreview I would guess, then quickly re-reviewed it. It would have showed up in his watchlist because he was the original reviewer in April.[9] The redirect in question would have gone back into the feed when it was merged recently and converted to redirect(this is normal). Then the merge was reverted, and then the revert was reverted. This probably didn't have any effect on the situation, but would have brought the redirect to PRehse's attention. Polyamorph marked it as reviewed (probably found it in the feed) and then PRehse must have accidentally clicked the button while he was there inspecting the situation (probably just muscle memory), then quickly reverted his own action when he realised that he had unreviewed, rather than reviewed it. There is an item in the wishlist to be able to optionally disable this automated message, and it is also affected by the one about messages not being hard coded. The issue is that the 'unreviewed' message reads as if intentional, and the reviewer who sent it really has no idea that they have sent it at all unless they check their contribs as it is entirely automated and you aren't prompted. I'll note on the Phab task that a prompt before sending the 'unreview' message is probably a better solution. — Insertcleverphrasehere ^{(or here)} 18:17, 24 October 2018 (UTC)[reply]

Makes sense, thanks ICPH. PRehse is a highly productive editor (NPP gnome of sorts), works quietly in the background getting things done. We cross paths from time to time - it’s a good feeling knowing he’s out there...or at least that’s my take on it. ^{Atsme✍🏻📧} 20:50, 24 October 2018 (UTC)[reply]

Should we stop marking articles tagged with CSD and PROD as 'reviewed' now that we can filter them in the NewPagesFeed?

A while back there was some discussion on whether pages tagged with CSD and PROD deletion tags should be marked as 'reviewed'. The general consensus was that deletion tagged articles got in the way of users flipping through the feed if they weren't marked as 'reviewed', and that it was fine to mark it as reviewed if you were willing to watch your PROD/CSD logs and/or watchlist carefully for inappropriate removals of the tag.

By marking them as reviewed, the downside is that it creates a single point of failure. Articles tagged for deletion often aren't fully reviewed with maintenance tags etc and If the previous reviewer doesn't notice that the deletion was declined, he/she might not return to the article to make sure that it gets a full review. Of more concern is if the author contests the PROD or inappropriately removes the CSD tag and the reviewer doesn't notice. In that case the article may be complete garbage and will fall out of the NewPagesFeed.

We now have a new filter at the NewPagesFeed that can filter out pages 'nominated for deletion' (CSD, PROD, and AfD, and soon to contain RfD as well), so we have a better solution for those that like to use the 'next' button; they can just uncheck 'nominated for deletion' and their system will just skip those articles in the queue.

Given that we have that filter, and people can filter them out before flipping through pages, I propose that we stop marking CSDed and PRODed articles as 'reviewed. As for AfD, and RfD, these are discussion based and the tag can't be inappropriately removed. If 'kept' at these venues, it is less important that these get checked over, because there is explicit community support for keeping them (this is less clear with 'no consensus' results, but I think we are safe after something goes through AfD as there have been plenty of eyes on it).

Please discuss below. If there is support for this change, I will update the flowchart to remove 'mark as reviewed' for all the deletion options (except AfD), and I will also request in Phabricator that the tool be updated to not mark articles as reviewed automatically when tagging for deletion with the PC toolbar. — Insertcleverphrasehere ^{(or here)} 07:26, 24 October 2018 (UTC)[reply]

Support I don't think we should be marking CSD or PROD articles as reviewed, unless they have been inappropriately tagged. Keep marking AfD as reviewed for reasons you give. Polyamorph (talk) 07:50, 24 October 2018 (UTC)[reply]
support agree w/ Polyamorph --Ozzie10aaaa (talk) 10:07, 24 October 2018 (UTC)[reply]
support - as a matter of procedure.Onel5969 ^{TT me} 11:19, 24 October 2018 (UTC)[reply]
Support Best, Barkeep49 (talk) 11:36, 24 October 2018 (UTC)[reply]
Support all - including AfD because the latter serves another purpose we should use to the project's advantage. When a trash can article shows up in the queue, we should all take the time necessary to participate in the AfD if there is one. We have a substantial number of articles slipping into maintstream that should not be there primarily because there weren't enough experienced reviewers participating in the AfD. There appears to be more red user names with relatively low edit counts participating at company-related AfDs, which leaves the door wide open for promotion to slip through. Once those articles are out of our queue, the chances they'll be visited again for notability/tagging are substantially reduced. ^{Atsme✍🏻📧} 14:00, 24 October 2018 (UTC)[reply]
- In an ideal world I could get behind this. In the world we live in with a gradually increasing backlog I would suggest reviewer time can be best spent elsewhere and interested editors can look through AfD if they wish to participate. I am in agreement with ICPH's overall logic that AfD is going to indicate community thinking and NPP shouldn't, and doesn't have some superveto over that. Best, Barkeep49 (talk) 14:51, 24 October 2018 (UTC)[reply]

I am still in favor of not marking AfD articles as reviewed. I don't think we should necessarily encourage reviewers to participate in every AfD they come across, but the articles should remain visible, and I don't think they represent a significant drain on our resources. Moreover, marking the article as reviewed releases it to search engines–while AfD articles are often relatively benign, there are examples (such as the ongoing discussion over Trinbagonian nationalism) where the article for discussion may have significant OR issues and should not be indexed until a consensus has been reached that the article is encyclopedia-worthy. Similarly, sometimes AfDs are closed without consensus–in these cases, another reviewer should absolutely be evaluating the article and determining whether to mark it as reviewed or renominate it for deletion. I don't see this as the NPP having some sort of veto over consensus, but rather as us not jumping to conclusions until the consensus is clearly established. In an ideal world, we would have the AfD closing process automatically mark the article as reviewed on keep/redirect. As it were, a reviewer should recognize that if an AfD just ended on an article, they should respect the AfD's consensus and mark the article accordingly (alternatively, we could see marking the article as reviewed following discussion close as a responsibility of the reviewer that nominated it for deletion in the first place). _signed,Rosguill ^talk 18:30, 25 October 2018 (UTC)[reply]

@Rosguill: Marking it as reviewed does not release it to google. All the deletion tags contain NOINDEX, meaning that articles containing them are not indexed by default. AfDs closed as 'no consensus' can't be "renominated for deletion"; they are 'keep' by default and there is nothing you can do about it. You can't PROD it, you can't CSD it, and you can't take it back to AfD (at least not for a good long time). You could take it to deletion review if you think the discussion was closed inappropriately but if there was legitimately 'no consensus' there is no way to "renominate for deletion". Because 'no consensus' is de facto 'keep' at AfD there is not anything for NPR to do at that point. NPR is triage, not cleanup. The most you can do is put a couple maintenence tags on it, which isn't particularly useful and isn't a reason for a full re-review (compared to CSD and PROD where a non-notable topic might slip through the cracks entirely). If reviewers want to participate in deletion discussions, they can and should go to AfD (we do need more people participating), but having them clog up the works in the queue just to hope for more clicks isn't an improvement, and it isn't NPR's job, especially with a constantly growing backlog. — Insertcleverphrasehere ^{(or here)} 09:55, 26 October 2018 (UTC)[reply]

Oppose - the proposal completely overlooks those who work through Special:NewPages & WP:Twinkle. Cabayi (talk) 14:05, 24 October 2018 (UTC)[reply]

@Cabayi: Those few users who haven't moved over would still see pages in Special:NewPages as 'unreviewed' even if they were marked for deletion, which is an annoyance. As a fix to this knock on issue, we could request that Special:NewPages not highlight pages that have deletion tags on them, even if unreviewed, and a notice could be added at the top of that page with the other instructions indicating that these pages should not be marked as patrolled/reviewed. Because there is a log for 'nominated for deletion', this should be fairly easy to implement I would think. As for Twinkle, both Twinkle and the Curation tools would be modified to not automatically patrol/review articles when placing CSD and PROD tags. — Insertcleverphrasehere ^{(or here)} 14:45, 24 October 2018 (UTC)[reply]

@Insertcleverphrasehere: "moved over"? Special:NewPagesFeed is useless for about 28 of the 30 namespaces. — xaosflux ^Talk 13:49, 25 October 2018 (UTC)[reply]

@Xaosflux: I'm obviously not proposing changes to the other namespaces and we could have this apply only to mainspace if you like. I understand that there are some advantages to Special:NewPages, and that it is used for other namespaces, but the vast majority of New Page Reviewers use Special:NewPageFeed for reviewing the article space. Special:NewPages can be modified to just treat pages with deletion templates on them as 'patrolled/reviewed' and this would result in practically no change to the situation at present (and would also help prevent removed-deletion-tagged-articles from falling through the cracks at Special:NewPages too). I'm glad you guys brought this up, but it is easily solvable. The only 'negative' is that non-patrollers can inappropriately mark pages as psuedo-patrolled at Special:NewPages, but this is a non-issue, as admins will eventually be drawn to the situation by the deletion tag anyway. — Insertcleverphrasehere ^{(or here)} 14:09, 25 October 2018 (UTC)[reply]

@Xaosflux and Insertcleverphrasehere: it's not a non-issue, the damage has been done: the new user has been well and truly bitten. This was the 'other half' of the intended plan to allow patrolling of new pages to be done only by accredited reviewers, but for some reason the community voted against that part pf the proposal. Kudpung กุดผึ้ง (talk) 19:44, 25 October 2018 (UTC)[reply]

While true, that really isn't relevant to the decision at hand. It is a non-issue with regards to losing track of non-notable topics (because an admin will eventially see it. Biting newbies is an important, but different, problem. — Insertcleverphrasehere ^{(or here)} 10:11, 26 October 2018 (UTC)[reply]

Insertcleverphrasehere, I'm still bugged by your description of editors not using the curation tools as the "few" both here and on my talk page. So I did a check, comparing the first page of the patrol log (250 entries) with the corresponding entries for the same time period on the curation log (206 entries). Stripping the lists to the bare user names and removing duplicates, then removing the "curators" from the "patrollers" list (since curation creates a few patrol actions each time) results in a list of 14 "curators" & 20 "patrollers".

However, the issue is not about browbeating one group into using the toolset of the other. The community is not best served by the monoculture of a single tool, ("One tool to rule them all...and in the darkness bind them") but by the use of multiple toolsets which prevent the unintentional creation of blindspots. At Special:NewPages, with 17 or 18 pages on view at one time, it's glaringly obvious if someone is kicking off on a mission to create pages for every player on their school football team, far easier than with only 3 or 4 pages on show at Special:NewPagesFeed. Because NP doesn't mess with the highlighting it's easy to see new pages that you've seen before and are obviously re-creations, possibly WP:G4, or sockpuppet work for WP:G5 & WP:SPI. They're different tools with different benefits. Embrace the diversity.

To address your question on my talk page, yes your altered suggestion goes some way to addressing my objections. But - your suggestions concerning Twinkle are flawed. At present users have the option to set their Twinkle preferences to automatically patrol when tagging an article for AFD, CSD, or just generally tagging it, but not when tagging with PROD (despite my efforts,1,2 which both sank into the archives without any impact). Your desired outcome is already the status-quo in Twinkle. Cabayi (talk) 13:27, 26 October 2018 (UTC)[reply]

(edit conflict) Support I found this problematic because if someone removed the tag, they were marked patrolled, but unreviewed. Now that we have a mechanism to filter them, let's stop doing this. Err, let's make the tool stop doing this. Natureium (talk) 14:05, 24 October 2018 (UTC)[reply]
Regarding marking as 'patrolled' - if the page has been CSD'd already I think it should be marked patrolled - as it has already been looked at and another patrolled shouldn't have to look at it. Keep in mind "patrolled" applies to every namespace, whereas Special:NewPagesFeed only looks at two. — xaosflux ^Talk 13:47, 25 October 2018 (UTC)[reply]

The NewPagesFeed treats patrolled articles as 'reviewed' though. Meaning that after CSDing or PRODing something, if someone removes the CSD/PROD, and you don't check on it, it will just fall out of the queue. — Insertcleverphrasehere ^{(or here)} 13:53, 25 October 2018 (UTC)[reply]

To elaborate on what ICPH is saying, I see NPP as a crucial check on making sure only the right stuff hits Google, and thus be easily found, under Wikipedia's name. If something is CSD'able it shouldn't be indexed and to a lesser extent this is true for a PROD. ICPH hits on the dangers of acting otherwise. Best, Barkeep49 (talk) 14:18, 25 October 2018 (UTC)[reply]

Support I've been troubled by the practice of marking deletion discussion articles as reviewed for a while now and haven't spoken up because it felt like the conversation/consensus had moved past that point. I agree strongly with the arguments made above about reviewing indexing the article for search engines, and for that reason also support this policy (is that the right word?) in the case of AfD articles. _signed,Rosguill ^talk 18:22, 25 October 2018 (UTC)[reply]
Oppose NPP is triage. There are only a few possible outcomes; mark as reviewed with no issues, tag, redirect, draftify or nominate for deletion. All those outcomes mark the end of the review process. To review a page, decide that it does not meet our criteria for inclusion, nominate it for deletion and THEN decide that the review should be quasi reverted or postponed until after the deletion process is completed makes no sense. Vexations (talk) 20:41, 25 October 2018 (UTC)[reply]

What happens if we decide it should be deleted as PROD but someone contests? The next step would be AfD. Likewise some other form of deletion might be appropriate if a CSD is declined by an admin. In this way an article doesn't "slip through the cracks" when delete was the proper outcome. Best, Barkeep49 (talk) 20:45, 25 October 2018 (UTC)[reply]

Something happens, but not a new review. You may want to follow up after initiating the deletion process, but the deletion process is not part of the triage. Nominating it for deletion is where one process (review) ends and another (deletion) begins. If you don't like that your nomination doesn't always have the outcome you prefer, you need to find a solution for that. Making the de-facto deletion of the article a condition for the completion of the review is the wrong solution. Vexations (talk) 21:14, 25 October 2018 (UTC)[reply]

@Vexations: you say "Something happens, but not a new review" but this isn't true. In the current system, if someone contests the PROD (usually the author), and the reviewer misses it, the article is now marked as 'reviewed'. It is pretty easy for this article to now be overlooked and just fall into mainspace, even if utterly un-notable. The whole point of NPR and the NewPagesFeed is to make sure that this doesn't happen. The proposed change wouldn't have any effect on situations where the original reviewer was vigilant and goes back and checks on it (they would just take it to AfD, or if the issues were fixed, mark it as reviewed), but if they don't check on it, the new system would bring this to the attention of other reviewers because it would still be marked as 'unreviewed' (when checking the history page they would see the PROD and then go from there). Please reconsider your position on this, we need to make sure we don't lose track of stuff, and the current system endangers this. — Insertcleverphrasehere ^{(or here)} 10:11, 26 October 2018 (UTC)[reply]

I get that you don't want to create or leave open an easy loophole. But deletion is not an outcome of a review. Patrollers do not decide what gets deleted ow not. We consider the policies applicable to new articles and decide what the most applicable next steps for an article are. One of those possible next steps is the deletion process. The deletion process is separate from the review process. It should remain separate because the community has not granted new page patrollers the ability to delete articles. That's the theory. Now to practical matters: I don't know if there are any cases where a PROD was used in an new page review, objected to, leaving the article reviewed and the article not brought to AfD. But if that happened, remember that PROD must only be used if no opposition to the deletion is expected. In other words, the use of PROD such cases would have been wrong. If you expect opposition, use AfD. As for CSD, the number of declined CSD nominations should be very low, as we're expected to have a pretty good grasp of policy. If you nominate something for speedy deletion, and the deletion is declined, how do you miss that? How is it that you can nominate something for deletion, apparently care about it a great deal, and not follow-up? If the problem is that you find it difficult to keep track of your nominations because the logs are all over the place, then consolidating those logs iswhat you need to address, if the problem is that you don't get notified about a declined CSD, then we need to fix the notification system. Perhaps we can have a look at some concrete examples. I'll try to find some. Vexations (talk) 11:23, 26 October 2018 (UTC)[reply]

@Vexations: I'm not talking about declined CSDs, I'm talking about where the author innapropriately removes the CSD tag. I think there might be an edit filter that looks for this, but I'm not sure how regularly it is watched, and we shouldn't be relying on it. As for PRODs, it often isn't easy to tell if somebody is going to object until afterwards, and yes, sometimes someone will decline the PROD with "Your prod is inappropriate because be meets WP:ANYBIO #X" or whatever, in which case (if true) then the article can just be marked off as reviewed and taking to AfD wouldn't be appropriate (example). Just as often, the Author panics and just removes the tag with their next edit (sometimes unintentionally if they already had the edit window open and just click 'use my changes' to the edit conflict popup). In these cases the PRODed article is marked as reviewed and remains in mainspace unless the reviewer is paying attention. I try to keep track pretty well, but even I miss things sometimes. See: A Way to Help that I recently found in my PROD log that I missed. This happens all the time I am sure, and the page curation deletion tag logs] are even more difficult to track than the Twinkle ones as they are all lumped together (However, the Twinkle ones are turned off by default). From my PROD log, Rentsen Enkhbat should also be followed up too. I BLPPRODed it, and the guy removed the BLPPROD and added a link, but the article still doesn't have enough coverage, and I can't really find enough coverage for GNG (although he might meet one of the WP:PROF criteria). I consider myself fairly diligent, checking my watchlist regularly, but if these things escape me and require that I remember to go back to check my PROD logs, what else is slipping into mainspace unnoticed? — Insertcleverphrasehere ^{(or here)} 11:47, 26 October 2018 (UTC)[reply]

If a reviewed article is a candidate for deletion, regardless of who did it or why, I think it needs to stay in the queue until it’s either deleted or goes to AfD and consensus either says keep or delete. If we don’t follow-through an article we’ve nominated for deletion, then it’s unfinished business, not the end of it. If marking it reviewed after nominating it for deletion removes that article from the queue, then we should not mark it reviewed. Question: if the article ends up at AfD and consensus says keep, is it automatically marked as reviewed when the AfD is closed or does it remain in the NPP queue? ^{Atsme✍🏻📧} 03:39, 26 October 2018 (UTC)[reply]

An article kept at AfD is not automatically marked as reviewed. Best, Barkeep49 (talk) 03:43, 26 October 2018 (UTC)[reply]

@Atsme: But at that point, there is no reason not to, so that's why I suggested that AfDed pages still be marked off as 'reviewed' (also, the tag can't be improperly removed, because there is a bot that fixes it so long as the discussion is still open). — Insertcleverphrasehere ^{(or here)} 10:11, 26 October 2018 (UTC)[reply]

GDPR & HTTP 451

Because of the introduction of GDPR an increasing number of websites are blocking European visitors with an HTTP 451 message, effectively making them unverifiable sources. WP:ProveIt & reFill, running on WP's servers in the US, are unaffected, as is Internet Archive (archive.org). Has anybody got any better workarounds to the block? Cabayi (talk) 13:16, 25 October 2018 (UTC)[reply]

Curation toolbar display rules

Hi reviewers -- this is a new section to resolve the discussion above about the curation toolbar not showing up when expected (a discussion particularly involving Insertcleverphrasehere, Atsme, Barkeep49, Elmidae, Usernamekiran, and Fram, and related to the task filed by Insertcleverphrasehere). Our team thinks we have resolved all the bugs that caused inconsistency in when the toolbar appears. But in the discussion around those bugs, we saw that different reviewers have different preferences around the rules for when the toolbar should show up. Our team talked about this, and we think we have a proposal for the display rules that will give the most flexibility to the most reviewers.

Right now, the toolbar shows up for articles in curation if a reviewer does one of these things:

Opens the article by clicking on it from the New Pages Feed.
Opens the article from anywhere, and the reviewer had visited New Pages Feed within the last 24 hours, and the toolbar's last state was "open" when the reviewer used it last.

We have an idea for a really straightforward rule. We can just maintain the state of toolbar according to however the user last set it. So the toolbar would just show up for articles in curation if a reviewer:

Had the toolbar open last time they were looking at an article in curation.

With this new rule, reviewers who never want to see the toolbar can just dismiss it once and for all. Reviewers who always want it open can just leave it open. And if a reviewer does dismiss it and want it back, they can just click "Curate this article" in the left navigation menu (we could also change it from saying "Curate this article" to something clearer, like "Open Page Curation"). There would no longer be any 24 hour rule or any action that forces the toolbar open. Here is our Phabricator task for this prospective change.

How does this sound? Let me know! -- MMiller (WMF) (talk) 01:32, 26 October 2018 (UTC)[reply]

Question: Would this have it up for ALL articles? Like if I'm looking at Transport a clearly notable topic that is also as old as they get would I see the bar? Or are we just talking about articles that are in Special:NewPagesFeed? Best, Barkeep49 (talk) 01:41, 26 October 2018 (UTC)[reply]

@Barkeep49: this would only happen for pages that can be found in the New Pages Feed. Sorry, I should have said that in my description; I just didn't want it to sound like it would only happen if you went to the page from the New Pages Feed. The settings would stay respected no matter where you opened the page from. -- MMiller (WMF) (talk) 04:52, 26 October 2018 (UTC)[reply]

Perfect. I strongly support this change. Best, Barkeep49 (talk) 05:40, 26 October 2018 (UTC)[reply]

Yes, please do this. Natureium (talk) 02:09, 26 October 2018 (UTC)[reply]
@MMiller (WMF): Hi. Thanks for the ping. I am not sure about the current rule #2. I mean, a few days ago, when i refreshed the page, or visited the talkpage, and came back to article; the curation toolbar used to be gone. Also, we should set a clear-cut limit for old articles. I think the toolbar should be shown on the pages till 30 days after they have been patrolled. —usernamekiran(talk) 03:02, 26 October 2018 (UTC)[reply]
Thx MMiller - I like having the toolbar auto open when reviewing in the queue, and like having a collapse/open icon on the top of the bar. When we check “reviewed” on the bar, does it show up somewhere on the article that it was reviewed and by whom? As for the other features/suggestions, I can adjust to whatever you introduce as long as it comes with instructions and doesn’t require us to write code. 😉 ^{Atsme✍🏻📧} 03:06, 26 October 2018 (UTC)[reply]
Thx, the new rule seems fine to me (there is now a gadget to permanently disable the toolbar, but this solution would be better for most people and worse for no one I think). Fram (talk) 07:03, 26 October 2018 (UTC)[reply]
@MMiller (WMF):I don't know if I like this idea at all. For new reviewers especially, it is easy to 'lose' the the toolbar. If dismissed once, they won't be able to find it again unless they know that the little 'curate this article' link is there, which is easy to miss (this situation existed recently and call me stupid, but I was one of those people who 'lost' the toolbar: If I can do it, anyone can). For those that don't want the curation toolbar to show up, we now have a gadget that permanently disables it, I would prefer that it be set up to automatically pop up no matter what on new articles. The gadget could be changed to add the functionality you describe though (disable automatic popup, only pull it up manually from the 'curate this article' link)

We also need to talk about enabling Page Curation use on any article. Please do that while you are doing this. Ideally the Page curation toolbar should pop up automatically on pages in the New Pages Feed, automatic popup can be disabled in gadgets, and can be pulled up via the 'curate this article' on any article (Also, if disabled, you should still be able to pull it up manually for one time use by clicking 'curate this article'). We need options we don't need a situation where new reviewers might ose the tools and then stop reviewing because they can't find them anymore. Please don't make it even easier to lose the toolbar. — Insertcleverphrasehere ^{(or here)} 07:55, 26 October 2018 (UTC)[reply]

Before I comment on this, I'd like to out myself as a doofus... what "Curate this article" link are y'all talking about? This seems to be present in no navigation menu I can access, be it left or anywhere else :/ . For me the only way to get the curation bar to pop up has always been to enter the article via the new pages feed (either by clicking on the article link or on "Review"). --Elmidae (talk · contribs) 08:15, 26 October 2018 (UTC)[reply]

@Elmidae: This is exactly the problem. The 'curate this article' link only appears if you have dismissed the toolbar (click the top minimise button then the x), AND you are on a new article. We get used to not seeing it be there, so how are we supposed to know that it is the way we get the toolbar back after we dismiss the toolbar? Recently when the toolbar could be 'dismissed' semi-permanently, I 'dismissed' my toolbar (on accident as I don't remember doing it) and I thought my system was bugged as there was no way to get it back. I had no idea that the 'curate this article' link existed as it had never been visible to me before. To me it seems wildly unintuitive. — Insertcleverphrasehere ^{(or here)} 08:25, 26 October 2018 (UTC)[reply]

Oh, I see. Never went there. Yep, that's pretty much gone for good once closed, if you don't know about the mechanics. However, apart from that niggle, I do like the simplified approach as suggested by MMiller. Maybe one could counteract the baffling disappearance by a popup or note that comes up when you click the 'x', reminding you that there is now a link to re-enable the bar in the navigation menu? --Elmidae (talk · contribs) 08:45, 26 October 2018 (UTC)[reply]

Most people are pretty desensitised to popups, its pretty easy to miss them. And if you miss it, its gone 'poof'.

A button in preferences to disable automatic popup is a better solution. This gives everyone what they want (people who want it available will have it pop up whenever they visit a new page and will be able to use the 'curate this article link on other pages, people who want it gone forever can disable automatic popup in preferences, and people who want it to only pop up manually can disable automatic popup in preferences and then click 'curate this article' whenever they need the tools. — Insertcleverphrasehere ^{(or here)} 09:06, 26 October 2018 (UTC)[reply]

@@ Line 828: / Line 828: @@
 :::::{{re|xaosflux|Insertcleverphrasehere}} it's not a non-issue, the damage has been done: the new user has been well and truly bitten. This was the 'other half' of the intended plan to allow patrolling of new pages to be done only by accredited reviewers, but for some reason the community voted against that part pf the proposal. [[User:Kudpung|Kudpung กุดผึ้ง]] ([[User talk:Kudpung|talk]]) 19:44, 25 October 2018 (UTC)
 ::::::While true, that really isn't relevant to the decision at hand. It is a non-issue with regards to losing track of non-notable topics (because an admin will eventially see it. Biting newbies is an important, but different, problem.  — '''''<small>[[User:Insertcleverphrasehere|Insertcleverphrasehere]] <sup>([[User talk:Insertcleverphrasehere|or here]])</sup></small>''''' 10:11, 26 October 2018 (UTC)
+:::{{u|Insertcleverphrasehere}}, I'm still bugged by your description of editors not using the curation tools as the '''"few"''' both here and on my talk page. So I did a check, comparing the first page of the [https://en.wikipedia.org/w/index.php?title=Special:Log&type=patrol&subtype=patrol patrol log] (250 entries) with the corresponding entries for the same time period on the [https://en.wikipedia.org/w/index.php?title=Special:Log&type=pagetriage-curation curation log] (206 entries). Stripping the lists to the bare user names and removing duplicates, then removing the "curators" from the "patrollers" list (since curation creates a few patrol actions each time) results in a list of 14 "curators" & 20 "patrollers".
+:::However, the issue is not about browbeating one group into using the toolset of the other. The community is not best served by the monoculture of a single tool, <small>([[:q:The Fellowship of the Ring#The Shadow of the Past|"One tool to rule them all...and in the darkness bind them"]])</small> but by the use of multiple toolsets which prevent the unintentional creation of blindspots. At [[Special:NewPages]], with 17 or 18 pages on view at one time, it's glaringly obvious if someone is kicking off on a mission to create pages for every player on their school football team, far easier than with only 3 or 4 pages on show at [[Special:NewPagesFeed]]. Because NP doesn't mess with the highlighting it's easy to see new pages that you've seen before and are obviously re-creations, possibly [[WP:G4]], or sockpuppet work for [[WP:G5]] & [[WP:SPI]]. They're different tools with different benefits. Embrace the diversity.
+:::To address your question on my talk page, yes your altered suggestion goes some way to addressing my objections. But - your suggestions concerning [[WP:Twinkle|Twinkle]] are flawed. At present users have the option to set their [[Wikipedia:Twinkle/Preferences|Twinkle preferences]] to automatically patrol when tagging an article for [[Wikipedia:Twinkle/Preferences#Warn user|AFD]], [[Wikipedia:Twinkle/Preferences#Speedy deletion (CSD)|CSD]], or just generally [[Wikipedia:Twinkle/Preferences#Tag|tagging]] it, but not when tagging with [[Wikipedia:Twinkle/Preferences#Proposed deletion (PROD)|PROD]] (despite my efforts,[[Wikipedia talk:Twinkle/Archive 39#Patrolling options|1]],[[Wikipedia talk:Twinkle/Archive 40#Mark as patrolled|2]] which both sank into the archives without any impact). Your desired outcome is already the status-quo in Twinkle. [[User:Cabayi|Cabayi]] ([[User talk:Cabayi|talk]]) 13:27, 26 October 2018 (UTC)
 * {{ec}} '''Support''' I found this problematic because if someone removed the tag, they were marked patrolled, but unreviewed. Now that we have a mechanism to filter them, let's stop doing this. Err, let's make the tool stop doing this. [[User:Natureium|Natureium]] ([[User talk:Natureium#top|talk]]) 14:05, 24 October 2018 (UTC)
 * Regarding marking as 'patrolled' - if the page has been CSD'd already I think it should be marked patrolled - as it has already been looked at and another patrolled shouldn't have to look at it. Keep in mind "patrolled" applies to every namespace, whereas [[Special:NewPagesFeed]] only looks at two. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:47, 25 October 2018 (UTC)