Wikipedia talk:New pages patrol/Reviewers

TutorialDiscussionNew page feed

• Sorted
• Easy
• Reports

Reviewers

• Resources
• School
• Top

Curation tool
SuggestionsCoordination

• Talk
• Awards
• Newsletter

• Backlog drives

NPP backlog

Articles

10121 ↑47

Oldest article

15 months old

Redirects

32820

Oldest redirect

5 months old

Article reviews

1557

Redirect reviews

2307

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

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

Our official anagram

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)

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)

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

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)

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)

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)

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)

• @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)

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)

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)

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):

1. Unreviewed articles excluding redirects and xxDs – for most reviewers
2. Redirects only – for redirect-reviewers
3. 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)

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)

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

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

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)

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:

A mockup of an idea for improving the New Pages Feed.

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

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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

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

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)

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

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

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

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. 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: There isn't currently a great script for this, the best I have found is User:Ais523/stubtagtab2.js, ideally we would have a hotcat-like searchable field. This functionality has been suggested to be added to the PC tool, but even ignoring the 'lets not waste resources' argument, it was still suggested that stub sorting might be better left to the experts (some discussion might be good about this). I have put in a script request here.
• 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.

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)

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

Full recommended gadget/script list

Gadgets

• Twinkle
• Hotcat
• Moremenu

Core User Scripts

• User:Evad37/MoveToDraft
• User:Enterprisey/cv-revdel
• User:Writ Keeper/Scripts/deletionFinder.js
• User:Evad37/rater
• User:The Earwig/copyvios.js

Other Scripts

• User:Lourdes/PageCuration.js
• User:TheJosh/Scripts/NewPagePatrol.js
• User:Ais523/stubtagtab2.js (or future stub sorting script)
• User:Enterprisey/delsort.js
• User:Writ Keeper/Scripts/googleTitle.js

Discussion of 'NPR helper tool'

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

• 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)

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)

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

• 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)
• 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)

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)

• 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)

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

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)

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)

• 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)

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

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)

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)

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)

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)

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)

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)

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

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

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

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

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

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)

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)

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

(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)

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)

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)

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

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)

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)

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)

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

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)

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)

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

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

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

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

 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)

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

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

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

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

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

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)

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

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)

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)

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

• 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)

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)

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

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)

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

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)

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)

redirecting talkpage(s) here

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)

• Updates

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

• From the header of this talkpage:

1. "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.
2. Ppage feed" links to special:newpagesfeed.
3. 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.
4. 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.
5. "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.
6. "Reviewers" section Standard wikipedia user rights page. The talkpage of it, is this page. —usernamekiran(talk) 13:30, 14 October 2018 (UTC)

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.

1. Wikipedia talk:Page Curation
2. Wikipedia talk:Page Curation/Suggested improvements
3. Wikipedia talk:New pages patrol/Coordination

—usernamekiran(talk) 13:30, 14 October 2018 (UTC)
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)

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)

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

• 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)

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

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

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

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

• Support — Insertcleverphrasehere ^{(or here)} 14:29, 14 October 2018 (UTC)
• Support 1 & 3. Not sure about 2. Best, Barkeep49 (talk) 15:12, 14 October 2018 (UTC)
• support--Ozzie10aaaa (talk) 15:28, 14 October 2018 (UTC)
• 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)
• Support - organize, organize, organize - ❤️ - thanks for all you do, Kiran! ^{Atsme✍🏻📧} 13:33, 15 October 2018 (UTC)
• Support - Consolidation is beneficial. Vermont (talk) 15:01, 15 October 2018 (UTC)
• Support TonyBallioni (talk) 15:03, 15 October 2018 (UTC)
• Support - consolidation cuts down on wasted time. Onel

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

• 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)

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.

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)

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

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)

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)

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)

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

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)

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

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)

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)

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

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

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:

1. Go to this URL, instead of the usual New Pages Feed URL.
2. Open the "Set filters" menu and select "Copyvio" under "Potential issues".
3. This will filter to the pages that have been flagged by CopyPatrol (via the Turnitin service) as having revisions with potential violations.
4. You can click the "Copyvio" link in each entry to inspect the potential violating text in the CopyPatrol interface.
5. 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)

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)
• 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)
• Support ~ Araratic | talk 04:11, 16 October 2018 (UTC)
• 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)

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

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)

• 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)
• support--Ozzie10aaaa (talk) 10:25, 16 October 2018 (UTC)

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)

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

Community Wishlist listing for Page Curation fixes/improvements; Yay or Nay?

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.

---

Hey guys and gals,
Time to talk about whether we are going to participate in the 2019 Community Wishlist survey as it is due at the end of the month if we are going to go for it. There have been a lot of views one way or the other about whether this is the right idea. The two main views are:

1. The view that the Community Wishlist is a popularity contest for 'nice to have' comfort items, not for essential parts of MediaWiki, and that NPP is an essential feature (i.e. the view expounded by Kudpung, myself, and others). The Tech Team built these tools but made it impossible for us to maintain them (they hardcoded them into MediaWiki), so they need to keep them up with fixing buggs and adding obvious missing features/improvements.
2. The WMF view the Community Wishlist as the correct venue for these requests (parroted by quite a few members of the WMF that if we want anything except dire bugs fixed, we need to go through the wishlist).

There are quite a few requests over at Wikipedia:Page_Curation/Suggested_improvements, which broadly fit in three categories:

• A) bugs that inarguably should have been fixed a long time ago (e.g. AfD tagging unable to handle multiple nominations),
• B) features that arguably are required to bring the page curation tools in line with other legacy tools (e.g. features that Twinkle has and that PC does not: so long as these features are missing, people will be reluctant to move over from Twinkle, or will not have these features available if they don't also use Twinkle). In other words; unless PC has the features we need, why bother with it?
• C) requests that are "nice to have" features that would help considerably with the NPP workflow (e.g. Sending Feedback both to the talk page as well as the page creator, being able to change the size of the toolbar so that you can read the messages you are typing, date range filter for New Pages Feed, 'no links' filter for NewPagesFeed, etc.)

Of these categories, my view is that those in 'A' should have been done a long time ago, 'B' should be given some decent priority by the Tech Team as part of their normal operations, and that 'C' probably more represents things where the WMF is correct in saying that the Community Wishlist might be the best venue. Given this, I'd say that both '1' and '2' are correct above in some respects ('1' for 'A' and arguably also for 'B'), and that the WMF probably considers 'B' to be firmly in the Wishlist category as well as 'C'.

Given all of this, if we want to get even half of the stuff on the Suggested Improvements page, we probably do need to participate in the Community Wishlist. In line with this I have begun to clean up the Suggested Improvements page, closing a few already resolved requests, as well as filing Phab tickets for the others. If we decide to run a listing, we can just list a bunch of Phab Tickets and say "do this stuff please", so I'll get it ready in the case that we want to run it.

But I want to ask the community here: Should we put a listing into the Community Wishlist? — Insertcleverphrasehere ^{(or here)} 11:29, 17 October 2018 (UTC)

Support

• It would be nice if we didn't have to beg, but I don't see it happening otherwise. — Insertcleverphrasehere ^{(or here)} 11:29, 17 October 2018 (UTC)
• It's very discouraging to think we have to beg, after all, they (the WMF) are there to serve us who provide the content and maintain it - which ultimately provides their salaries. Being salaried does not mean they are in any way superior. In fact history has clearly shown that they make huge blunders and waste enormous funds. If the community ends up rejecting the NPP system in favour of Twinkle, Wikipedia will have finally lost its credibility as a quality knowledge base - which it is already well on the way to doing. As far as the wish list is concerned, if Insertcleverphrasehere can rally his 640 New Page Reviewers together, then we can't lose on the wishlist, but be aware that the only voters on the wishlist for what NPP needs are the reviewers themselves. There won't be any support from the rest of a disinterested community -NPP is not sexy enough.Kudpung กุดผึ้ง (talk) 11:54, 17 October 2018 (UTC)
• Anything to improve the process would be welcome. Even if in the end it proves futile, the effort should be made. Onel5969 ^{TT me} 11:57, 17 October 2018 (UTC)
• Support We need to clearly present to the community what improvements are needed. The community as a whole can then decide if if our concerns should be moved to the top of the list. After presenting our requests, the community can decide if NPP should be exempted from participating in the wish list because patrolling is core function. Vexations (talk) 12:18, 17 October 2018 (UTC)
• Support ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:43, 17 October 2018 (UTC)
• support--Ozzie10aaaa (talk) 21:04, 17 October 2018 (UTC)
• support Had been my thinking in earlier discussions. Best, Barkeep49 (talk) 21:45, 17 October 2018 (UTC)

• Support. --K.e.coffman (talk) 01:00, 19 October 2018 (UTC)

Oppose

Discussion

Please discuss additional ideas and improvements at the suggestions page, not here, this discussion section should be used for discussing the actual proposal. — Insertcleverphrasehere ^{(or here)} 11:29, 17 October 2018 (UTC)

• I don't think this is needed. In fact it's not clear what support or oppose votes above are for. Community Wishlist is a global voting process and is generally proposed individually. I am not aware of any special treatment for Wikiproject or a group of editors to present what they need. Any editor can present idea that relates to Page curation in their individual capacity and if it emerges among the winning 10 it will surely be acted upon. Whether we pile on support here or not its effect on how Community Wishlist survey works is zero. The only meaningful way here maybe is to first agree on one or two top priority features/bugs of the toolbar, someone then propose them and get editors to go and actually support the proposal when the voting starts. –Ammarpad (talk) 19:00, 17 October 2018 (UTC)

Sorry Ammarpad, perhaps I wasn't clear: In the past there has been quite a lot of opinion from patrollers that we shouldn't have to go through the wishlist. I want to make sure that we have consensus that Going to the Community Wishlist is the right way to go. The list of features is over at the Suggestions page (although I haven't finished the Phab tickets yet), and there may need to be some additional discussion on a couple of the items to make sure we have consensus for them, but that will come later (I'll bring those items up in the next week). — Insertcleverphrasehere ^{(or here)} 21:28, 17 October 2018 (UTC)

I read it as: Should we, the reviewers, collectively put forward a single proposal? If you think the wishlist works well, you may want to submit an individual proposal. If you do not think the wishlist works but you still want to be heard and perhaps have a shot a fixing the page curation toolset then you might want to prepare a proposal as a group and submit it as a group. --Vexations (talk) 21:01, 17 October 2018 (UTC)

This is pretty much what I was going for. — Insertcleverphrasehere ^{(or here)} 21:28, 17 October 2018 (UTC)

• NPP/NPR is a core function - as expressed by many - but it is not generally of interest to the broader community, unless article creators have been directly affected by its process. The unilaterall decision by Danny Horn, and imposed upon his subordinates, to force this as a Wish list issue is inappropriate, but we must go along with it as one of the avenues available until the WMF can measure by up to the responsibilities vested in their 'management' of the Wikimedia owned projects by the community. A campaign to rally the 640 reviewers should start very soon. Kudpung กุดผึ้ง (talk) 06:43, 18 October 2018 (UTC)

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.

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)

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)

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	HighT	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	LowT	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	MediumT	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?	High
Page curation toolbar:	*T207439:	Dragable Corners on Page Curation toolbar windows (for resizing)	Unknown	Medium
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	MediumT	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	Easy	LowT	Can be accomplished on wiki -requested already.
Page curation toolbar:	*T207482:	Curation toolbar opt-out in preferences	Medium	Medium	Moderate (all gadgets should have an a button in 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	Discuss (I'll open a section below about a messaging system)
NPP Messaging System:	*T207443:	Tagging Feedback in Page Curation Tools should also be sent to talk page	Medium?	High	Discuss (I'll open a section below about a messaging system)
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?	HighT	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	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)
• 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)
• support all--Ozzie10aaaa (talk) 16:27, 19 October 2018 (UTC)
• 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)
• 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)
• 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)
• 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)

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)

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)

---

• 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)

• 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)

  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)

  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)

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

  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)

• 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)
• 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)

Reviewer Notes System

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)

• Strong support-∯WBG^converse 13:11, 21 October 2018 (UTC)
• 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)
• support--Ozzie10aaaa (talk) 13:26, 21 October 2018 (UTC)
• Support - excellent idea. Onel5969 ^{TT me} 17:11, 21 October 2018 (UTC)
• Support, K.e.coffman (talk) 23:32, 21 October 2018 (UTC)
• 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)
• 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)
• Support – this is a great idea. _signed, Rosguill ^talk 02:47, 22 October 2018 (UTC)

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:

1. Add a template at the top of the article.
2. 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.
3. 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)