Jump to content

Wikipedia talk:New pages patrol/Reviewers/Archive 30

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25←Archive 28Archive 29Archive 30Archive 31Archive 32→Archive 35

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

SUCCESS
Consensus is to move forward with the proposal.
The objection being that once a page is marked for deletion, as far as NPP is concerned, our work is done. The other editors commenting don't support this view for various reasons including wanting other eyes on articles marked for deletion and wanting to make sure that articles don't get missed when PROD or CSD is removed or declined.
zchrykng (talk) 17:42, 4 November 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

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

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

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

Note that the current situation is that Twinkle marks CSDs as 'patrolled' but not PRODs, and the page curation toolbar marks both CSDs and PRODs as 'reviewed' (I tested them). — Insertcleverphrasehere (or here) 08:17, 31 October 2018 (UTC)
  • Support I don't think we should be marking CSD or PROD articles as reviewed, unless they have been inappropriately tagged. Keep marking AfD as reviewed for reasons you give. Polyamorph (talk) 07:50, 24 October 2018 (UTC)
  • support agree w/ Polyamorph --Ozzie10aaaa (talk) 10:07, 24 October 2018 (UTC)
  • support - as a matter of procedure.Onel5969 TT me 11:19, 24 October 2018 (UTC)
  • Support Best, Barkeep49 (talk) 11:36, 24 October 2018 (UTC)
  • Support all - including AfD because the latter serves another purpose we should use to the project's advantage. When a trash can article shows up in the queue, we should all take the time necessary to participate in the AfD if there is one. We have a substantial number of articles slipping into maintstream that should not be there primarily because there weren't enough experienced reviewers participating in the AfD. There appears to be more red user names with relatively low edit counts participating at company-related AfDs, which leaves the door wide open for promotion to slip through. Once those articles are out of our queue, the chances they'll be visited again for notability/tagging are substantially reduced. Atsme✍🏻📧 14:00, 24 October 2018 (UTC)
    • In an ideal world I could get behind this. In the world we live in with a gradually increasing backlog I would suggest reviewer time can be best spent elsewhere and interested editors can look through AfD if they wish to participate. I am in agreement with ICPH's overall logic that AfD is going to indicate community thinking and NPP shouldn't, and doesn't have some superveto over that. Best, Barkeep49 (talk) 14:51, 24 October 2018 (UTC)
I am still in favor of not marking AfD articles as reviewed. I don't think we should necessarily encourage reviewers to participate in every AfD they come across, but the articles should remain visible, and I don't think they represent a significant drain on our resources. Moreover, marking the article as reviewed releases it to search engines–while AfD articles are often relatively benign, there are examples (such as the ongoing discussion over Trinbagonian nationalism) where the article for discussion may have significant OR issues and should not be indexed until a consensus has been reached that the article is encyclopedia-worthy. Similarly, sometimes AfDs are closed without consensus–in these cases, another reviewer should absolutely be evaluating the article and determining whether to mark it as reviewed or renominate it for deletion. I don't see this as the NPP having some sort of veto over consensus, but rather as us not jumping to conclusions until the consensus is clearly established. In an ideal world, we would have the AfD closing process automatically mark the article as reviewed on keep/redirect. As it were, a reviewer should recognize that if an AfD just ended on an article, they should respect the AfD's consensus and mark the article accordingly (alternatively, we could see marking the article as reviewed following discussion close as a responsibility of the reviewer that nominated it for deletion in the first place). signed, Rosguill talk 18:30, 25 October 2018 (UTC)
@Rosguill: Marking it as reviewed does not release it to google. All the deletion tags contain NOINDEX, meaning that articles containing them are not indexed by default. AfDs closed as 'no consensus' can't be "renominated for deletion"; they are 'keep' by default and there is nothing you can do about it. You can't PROD it, you can't CSD it, and you can't take it back to AfD (at least not for a good long time). You could take it to deletion review if you think the discussion was closed inappropriately but if there was legitimately 'no consensus' there is no way to "renominate for deletion". Because 'no consensus' is de facto 'keep' at AfD there is not anything for NPR to do at that point. NPR is triage, not cleanup. The most you can do is put a couple maintenence tags on it, which isn't particularly useful and isn't a reason for a full re-review (compared to CSD and PROD where a non-notable topic might slip through the cracks entirely). If reviewers want to participate in deletion discussions, they can and should go to AfD (we do need more people participating), but having them clog up the works in the queue just to hope for more clicks isn't an improvement, and it isn't NPR's job, especially with a constantly growing backlog. — Insertcleverphrasehere (or here) 09:55, 26 October 2018 (UTC)
@Cabayi: Those few users who haven't moved over->Patrolling from there, reviewers would still see pages in Special:NewPages as 'unreviewed' even if they were marked for deletion, which is an annoyance. As a fix to this knock on issue, we could request that Special:NewPages not highlight pages that have deletion tags on them, even if unreviewed, and a notice could be added at the top of that page with the other instructions indicating that these pages should not be marked as patrolled/reviewed. Because there is a log for 'nominated for deletion', this should be fairly easy to implement I would think. As for Twinkle, both Twinkle and the Curation tools would be modified to not automatically patrol/review articles when placing CSD and PROD tags. — Insertcleverphrasehere (or here) 14:45, 24 October 2018 (UTC)
@Insertcleverphrasehere: "moved over"? Special:NewPagesFeed is useless for about 28 of the 30 namespaces. — xaosflux Talk 13:49, 25 October 2018 (UTC)
@Xaosflux: I'm obviously not proposing changes to the other namespaces and we could have this apply only to mainspace if you like. I understand that there are some advantages to Special:NewPages, and that it is used for other namespaces, but the vast majority of New Page Reviewers use Special:NewPageFeed for reviewing the article space. Special:NewPages can be modified to just treat pages with deletion templates on them as 'patrolled/reviewed' and this would result in practically no change to the situation at present (and would also help prevent removed-deletion-tagged-articles from falling through the cracks at Special:NewPages too). I'm glad you guys brought this up, but it is easily solvable. The only 'negative' is that non-patrollers can inappropriately mark pages as psuedo-patrolled at Special:NewPages, but this is a non-issue, as admins will eventually be drawn to the situation by the deletion tag anyway. — Insertcleverphrasehere (or here) 14:09, 25 October 2018 (UTC)
@Xaosflux and Insertcleverphrasehere: it's not a non-issue, the damage has been done: the new user has been well and truly bitten. This was the 'other half' of the intended plan to allow patrolling of new pages to be done only by accredited reviewers, but for some reason the community voted against that part pf the proposal. Kudpung กุดผึ้ง (talk) 19:44, 25 October 2018 (UTC)
While true, that really isn't relevant to the decision at hand. It is a non-issue with regards to losing track of non-notable topics (because an admin will eventially see it. Biting newbies is an important, but different, problem. — Insertcleverphrasehere (or here) 10:11, 26 October 2018 (UTC)
Insertcleverphrasehere, I'm still bugged by your description of editors not using the curation tools as the "few" both here and on my talk page. So I did a check, comparing the first page of the patrol log (250 entries) with the corresponding entries for the same time period on the curation log (206 entries). Stripping the lists to the bare user names and removing duplicates, then removing the "curators" from the "patrollers" list (since curation creates a few patrol actions each time) results in a list of 14 "curators" & 20 "patrollers".
However, the issue is not about browbeating one group into using the toolset of the other. The community is not best served by the monoculture of a single tool, ("One tool to rule them all...and in the darkness bind them") but by the use of multiple toolsets which prevent the unintentional creation of blindspots. At Special:NewPages, with 17 or 18 pages on view at one time, it's glaringly obvious if someone is kicking off on a mission to create pages for every player on their school football team, far easier than with only 3 or 4 pages on show at Special:NewPagesFeed. Because NP doesn't mess with the highlighting it's easy to see new pages that you've seen before and are obviously re-creations, possibly WP:G4, or sockpuppet work for WP:G5 & WP:SPI. They're different tools with different benefits. Embrace the diversity.
To address your question on my talk page, yes your altered suggestion goes some way to addressing my objections. But - your suggestions concerning Twinkle are flawed. At present users have the option to set their Twinkle preferences to automatically patrol when tagging an article for AFD, CSD, or just generally tagging it, but not when tagging with PROD (despite my efforts,1,2 which both sank into the archives without any impact). Your desired outcome is already the status-quo in Twinkle. Cabayi (talk) 13:27, 26 October 2018 (UTC)
@Cabayi: I know that a lot of people use Twinkle (I use it too for a lot of stuff, including all deletion tagging due to the issues with Userspace Logs in Page curation that haven't been fixed yet and AfD bugs), I was referring to Special:NewPages when I said 'few who hadn't moved over' above. I'll concede that point in your favour, your explanation of the use of "multiple toolsets which prevent the unintentional creation of blindspots" is compelling. I've struck and replaced that comment above. I'm glad to hear that Twinkle is already on board with PROD, but the danger of CSD removals not being noticed is an issue too. and these should be address regardless of the page feed or tools that a reviewer is using. — Insertcleverphrasehere (or here) 14:12, 26 October 2018 (UTC)
Insertcleverphrasehere, the addition of a "request that Special:NewPages not highlight pages that have deletion tags on them, even if unreviewed" preferably selectable, in the same way as the existing selectors -
Show patrolled edits | Hide bots | Show redirects
would satisfy my concerns & ensure that the two methods worked in a compatible way. On that proviso, I strike my objection. Cabayi (talk) 18:14, 26 October 2018 (UTC)
  • (edit conflict) Support I found this problematic because if someone removed the tag, they were marked patrolled, but unreviewed. Now that we have a mechanism to filter them, let's stop doing this. Err, let's make the tool stop doing this. Natureium (talk) 14:05, 24 October 2018 (UTC)
  • Regarding marking as 'patrolled' - if the page has been CSD'd already I think it should be marked patrolled - as it has already been looked at and another patrolled shouldn't have to look at it. Keep in mind "patrolled" applies to every namespace, whereas Special:NewPagesFeed only looks at two. — xaosflux Talk 13:47, 25 October 2018 (UTC)
The NewPagesFeed treats patrolled articles as 'reviewed' though. Meaning that after CSDing or PRODing something, if someone removes the CSD/PROD, and you don't check on it, it will just fall out of the queue. — Insertcleverphrasehere (or here) 13:53, 25 October 2018 (UTC)
To elaborate on what ICPH is saying, I see NPP as a crucial check on making sure only the right stuff hits Google, and thus be easily found, under Wikipedia's name. If something is CSD'able it shouldn't be indexed and to a lesser extent this is true for a PROD. ICPH hits on the dangers of acting otherwise. Best, Barkeep49 (talk) 14:18, 25 October 2018 (UTC)
  • Support I've been troubled by the practice of marking deletion discussion articles as reviewed for a while now and haven't spoken up because it felt like the conversation/consensus had moved past that point. I agree strongly with the arguments made above about reviewing indexing the article for search engines, and for that reason also support this policy (is that the right word?) in the case of AfD articles. signed, Rosguill talk 18:22, 25 October 2018 (UTC)
  • Oppose NPP is triage. There are only a few possible outcomes; mark as reviewed with no issues, tag, redirect, draftify or nominate for deletion. All those outcomes mark the end of the review process. To review a page, decide that it does not meet our criteria for inclusion, nominate it for deletion and THEN decide that the review should be quasi reverted or postponed until after the deletion process is completed makes no sense. Vexations (talk) 20:41, 25 October 2018 (UTC)
What happens if we decide it should be deleted as PROD but someone contests? The next step would be AfD. Likewise some other form of deletion might be appropriate if a CSD is declined by an admin. In this way an article doesn't "slip through the cracks" when delete was the proper outcome. Best, Barkeep49 (talk) 20:45, 25 October 2018 (UTC)
Something happens, but not a new review. You may want to follow up after initiating the deletion process, but the deletion process is not part of the triage. Nominating it for deletion is where one process (review) ends and another (deletion) begins. If you don't like that your nomination doesn't always have the outcome you prefer, you need to find a solution for that. Making the de-facto deletion of the article a condition for the completion of the review is the wrong solution. Vexations (talk) 21:14, 25 October 2018 (UTC)
@Vexations: you say "Something happens, but not a new review" but this isn't true. In the current system, if someone contests the PROD (usually the author), and the reviewer misses it, the article is now marked as 'reviewed'. It is pretty easy for this article to now be overlooked and just fall into mainspace, even if utterly un-notable. The whole point of NPR and the NewPagesFeed is to make sure that this doesn't happen. The proposed change wouldn't have any effect on situations where the original reviewer was vigilant and goes back and checks on it (they would just take it to AfD, or if the issues were fixed, mark it as reviewed), but if they don't check on it, the new system would bring this to the attention of other reviewers because it would still be marked as 'unreviewed' (when checking the history page they would see the PROD and then go from there). Please reconsider your position on this, we need to make sure we don't lose track of stuff, and the current system endangers this. — Insertcleverphrasehere (or here) 10:11, 26 October 2018 (UTC)
I get that you don't want to create or leave open an easy loophole. But deletion is not an outcome of a review. Patrollers do not decide what gets deleted ow not. We consider the policies applicable to new articles and decide what the most applicable next steps for an article are. One of those possible next steps is the deletion process. The deletion process is separate from the review process. It should remain separate because the community has not granted new page patrollers the ability to delete articles. That's the theory. Now to practical matters: I don't know if there are any cases where a PROD was used in an new page review, objected to, leaving the article reviewed and the article not brought to AfD. But if that happened, remember that PROD must only be used if no opposition to the deletion is expected. In other words, the use of PROD such cases would have been wrong. If you expect opposition, use AfD. As for CSD, the number of declined CSD nominations should be very low, as we're expected to have a pretty good grasp of policy. If you nominate something for speedy deletion, and the deletion is declined, how do you miss that? How is it that you can nominate something for deletion, apparently care about it a great deal, and not follow-up? If the problem is that you find it difficult to keep track of your nominations because the logs are all over the place, then consolidating those logs iswhat you need to address, if the problem is that you don't get notified about a declined CSD, then we need to fix the notification system. Perhaps we can have a look at some concrete examples. I'll try to find some. Vexations (talk) 11:23, 26 October 2018 (UTC)
@Vexations: I'm not talking about declined CSDs, I'm talking about where the author innapropriately removes the CSD tag. I think there might be an edit filter that looks for this, but I'm not sure how regularly it is watched, and we shouldn't be relying on it. As for PRODs, it often isn't easy to tell if somebody is going to object until afterwards, and yes, sometimes someone will decline the PROD with "Your prod is inappropriate because be meets WP:ANYBIO #X" or whatever, in which case (if true) then the article can just be marked off as reviewed and taking to AfD wouldn't be appropriate (example). Just as often, the Author panics and just removes the tag with their next edit (sometimes unintentionally if they already had the edit window open and just click 'use my changes' to the edit conflict popup). In these cases the PRODed article is marked as reviewed and remains in mainspace unless the reviewer is paying attention. I try to keep track pretty well, but even I miss things sometimes. See: A Way to Help that I recently found in my PROD log that I missed. This happens all the time I am sure, and the page curation deletion tag logs] are even more difficult to track than the Twinkle ones as they are all lumped together (However, the Twinkle ones are turned off by default). From my PROD log, Rentsen Enkhbat should also be followed up too. I BLPPRODed it, and the guy removed the BLPPROD and added a link, but the article still doesn't have enough coverage, and I can't really find enough coverage for GNG (although he might meet one of the WP:PROF criteria). I consider myself fairly diligent, checking my watchlist regularly, but if these things escape me and require that I remember to go back to check my PROD logs, what else is slipping into mainspace unnoticed? — Insertcleverphrasehere (or here) 11:47, 26 October 2018 (UTC)
The edit filter that catches removal of speedy deletion templates by new users is 29 . You can see the logs here. Vexations (talk) 14:26, 27 October 2018 (UTC)
If a reviewed article is a candidate for deletion, regardless of who did it or why, I think it needs to stay in the queue until it’s either deleted or goes to AfD and consensus either says keep or delete. If we don’t follow-through an article we’ve nominated for deletion, then it’s unfinished business, not the end of it. If marking it reviewed after nominating it for deletion removes that article from the queue, then we should not mark it reviewed. Question: if the article ends up at AfD and consensus says keep, is it automatically marked as reviewed when the AfD is closed or does it remain in the NPP queue? Atsme✍🏻📧 03:39, 26 October 2018 (UTC)
An article kept at AfD is not automatically marked as reviewed. Best, Barkeep49 (talk) 03:43, 26 October 2018 (UTC)
@Atsme: But at that point, there is no reason not to, so that's why I suggested that AfDed pages still be marked off as 'reviewed' (also, the tag can't be improperly removed, because there is a bot that fixes it so long as the discussion is still open). — Insertcleverphrasehere (or here) 10:11, 26 October 2018 (UTC)
ICPH - so basically, as mentioned above, when reviewers CSD, or prod, or AfD an article we should forget about it and move on as it having been reviewed - end of story (triage). But what about the reality that anyone can challenge a speedy or prod, and if we’ve already checked it as reviewed and move on, does that removal put the article back in the queue? If not, there’s no guarantee it will receive proper attention from that point forward. I think having AfC & NPP combined will help eliminate some of the issues...hopefully...but speedy/prods can be easily challenged and removed. When you say there’s a bot that “fixes” improper removal - are you referring to AfD? My experiences there have been challenging at times - I typically monitor the articles I tag for AfD - but despite making AGF first and foremost, I’ve had the occasional discussions with suspected COI editors and/or socks over the years, and was even faced with an NAC by an involved editor after only 2 days of discussion - rare but it happens. The aforementioned is part of the reason I’m suggesting that follow-up and AfD participation be part of our review process, regardless of which reviewer made the nom. If there’s a trash can in the queue, look at the article if you have time, and participate at the AfD if there is one. Atsme✍🏻📧 16:26, 26 October 2018 (UTC)
@Atsme: The bot fixes the AfD tags on articles, (and even if it didn't, the article would get followed up on due to the open discussion at AfD). The current status quo sees us do nothing when CSD tags are removed or PRODs are removed unless the reviewer is paying attention and comes back (the article is marked as 'reviewed' and falls out of the queue). The whole point of this proposal is to change this situation. If this proposal passes, we would no longer mark CSDs and PRODs off as 'reviewed', so if the tags were inappropriately removed, they would stay in the queue to get another reviewer to check up on them later. Articles sent to AfD can be marked off as 'reviewed' as in the current status quo, because there is no risk of losing track of them (due to the listed discussion at AfD). — Insertcleverphrasehere (or here) 08:09, 27 October 2018 (UTC)
  • 'Support I want anything I've tagged for deletion to be especially visible to other reviewers, and similar for ones that they've tagged. I want to also support the idea that we should be maintaining at least the current functionality in Special:New Pages--it is an excellent complement to NPP. As mentioned, it's easier to spot patterns of submissions, and it's easier to quickly scan for thing I want to specially focus on. DGG ( talk ) 15:15, 29 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.

Implementation

Tracked in Phabricator
Task T208683
Tracked in Phabricator
Task T208685

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 Easy Medium High (sometimes difficult to find who reviewed the article if they used Twinkle) - Fix proposed at Phab pending code review
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  Done Low Template was deleted at TfD as an alternative solution.
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** Low?
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? Medium Moderate
Page curation toolbar: *T207439: Dragable Corners on Page Curation toolbar windows (for resizing) Easy? Medium High (per DGG, see talk below)
Page curation toolbar: *T207442: Send Message to creator without needing to 'unreview'/'re-review' the article Easy? High High (repeatedly requested annoyance)
Page curation toolbar: *T207444: Page Curation tools, option to 'report editor to AIV' for blatantly blockably created pages (when CSD tagging articles) Medium MediumT Moderate (would be nice to bring it up to Twinkle standard)
Page curation toolbar: *T207450: Requesting Revdel built into Page Curation Tools.  Done High** Done, template with id ranges can be added via the 'copyright violations' section of the page curation toolbar.
Page curation toolbar: *T207451: Add {{sources exist}} to Page Curation Toolbar  Done LowT Can be accomplished on wiki -requested and being tested
Page curation toolbar: *T207482: Curation toolbar opt-out in preferences  Done Medium Last gadget in the list at preferences.
Special:NewPagesFeed filtering: *T169120: Allow filtering by no citations in page curation Easy? High** High (NPP browser has this functionality, but not many of the other filters, and it is important to be able to filter multiple things at the same time)
Special:NewPagesFeed filtering: *T167475: Allow filtering by date range in Special:NewPagesFeed Hard? High High (repeatedly requested, even the NPP browser doesn't do this)
Special:NewPagesFeed filtering: *T207238: Special:NewPageFeed filter by estimated public interest (e.g. filter by pageviews to enable prioritisation of high traffic articles) Hard? High High (We are article triage, and this would be VERY useful)
Special:NewPagesFeed filtering: *T189929: Add "previously deleted" as a possible issue (flagged in red) in the New Pages Feed/Page Curation Tool Medium High** High (to help identify COIs)
Special:NewPagesFeed filtering: *T157051: Implement a new icon for patrolled pages that have maintenance tags in the New Pages Feed Medium? Low Low (not essential as once 'reviewed' they aren't our problem)
NPP Messaging System: *T207452: Reviewer Notes system in Page Curation Tools: system for reviewers to flag talk page comments on new pages to other reviewers Hard? High High (per unanimous strong support in section below)
NPP Messaging System: *T207443: Tagging Feedback in Page Curation Tools should also be sent to talk page Medium? High High (per unanimous strong support in section below)
Uncategorised: *T207446: Automatically flag articles that have been overwritten as 'unreviewed' Hard High Moderate (Looks like it might be very difficult, but this would be good for the Wiki)
Uncategorised: *T207237: Page Curation Tools to add userspace CSD Log/PROD Log functionality Medium? 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)  Done High Can be accomplished on wiki -requested and being tested
Uncategorised: *T204465: Allow users to disable Page Curation's "I have unreviewed a page you curated" message Medium? Low Low
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) (Phab ticket closed for now)  Not done Low (currently no consensus that this is an improvement)
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)
New Suggestions: *T207757: Adding a "Potential COI" alert to the feed Easy High Should be easy as there is already an edit filter, high benefit.
New Suggestions: *T207759: Option in New Pages Feed to 'skip viewed articles'. Easy? Moderate Moderate
New Suggestions: *T207761: Keyword Search for New Pages Feed Moderate? High High
New Suggestions: *T207847: 'Potential Issues' flagged in Page Curation Toolbar Page Info flyout Hard? High Very High benefit. These issues are currently invisible when flicking through pages (unless going to the page directly from the feed)

** - 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 non-specific submission OK. I've changed my mind a bit. I agree with pretty much everyone a bit, and thing that Kudpung hit it on the head the most with "the individual fixes and features should simply be one request without tabulating the individual items." This would be a request for ongoing support, particularly for High priority items. More in the discussion section below. — Insertcleverphrasehere (or here) 16:08, 23 October 2018 (UTC)
  • 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. [[1]] 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.∯WBGconverse 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)
  • Support items marked "high priority". CASSIOPEIA(talk) 14:02, 22 October 2018 (UTC)
  • Support the high priority ones', but mark "Page Curation messages should be configurable " as especially high priority. Of the Medium ones, I'd want most the Resizable feature (which should I think be easy). I also agree with sending the bugs through now as bugs. DGG ( talk ) 05:47, 23 October 2018 (UTC)
  • Support high priority, and agree that the messages need to be configurable. If there's a way to prevent curation messages from auto posting to socks, blocked or banned creators would be helpful, too. Atsme✍🏻📧 17:50, 23 October 2018 (UTC)
@Atsme: I know that Winged Blades of Godric was working on a fix so that the G5 deletion talk page notice doesn't get sent out. This can be done on-wiki acording to him via the .js pages. See my talk page for more info. — Insertcleverphrasehere (or here) 11:56, 24 October 2018 (UTC)
Atsme, Insertcleverphrasehere:-- Live on test.wiki (which has it's disadvantage that I can't localise the mw.messages) along with a feature of marking drafts under review (to prevent reviewers duplicating each other's work), asking for hist-merges (which is necessary in case of botched copy-paste from drafts and do happen) and asking for revision-deletion, in case of selective-(non-G12able)-copyvio.Another miscellaneous tag as to marking that sources exist for the topic, has also been added.
I do plan to test out the draftification feature, under the deletions tab, forking Evad's script, in a few days' time.
And, whilst I've already asked for a selective implementation over here through an edit-request, it's taking a lot more time for them to get executed courtesy the un-bundling of the right from admins and absence of a separate interface-edit-requests queue et al.∯WBGconverse 12:33, 24 October 2018 (UTC)
See User:AnomieBOT/PERTable.
Also, it might be prudential to note that I am trying to align the t/p templates that are generated by the NPP-CSD-module with that of Twinkle.Language and all that stuff by taking the better from both of them.If there are any issues, please let me know:-)∯WBGconverse 12:38, 24 October 2018 (UTC)
Thanks for going the extra mile, WBG. It is much appreciated by this editor, for sure! Atsme✍🏻📧 14:09, 24 October 2018 (UTC)
@Winged Blades of Godric: What's the best way for those of who are interested to test this out? Best, Barkeep49 (talk) 14:57, 24 October 2018 (UTC)
Barkeep49, See my message at ICPH's t/p.∯WBGconverse 15:00, 24 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)
Thank you for your comments Kudpung. This won't be a normal submission to the Community Wishlist. So we should just say what we really want: Ongoing support for improving the NPR process as we respond to the constantly changing landscape of New Page Review. Especially with targeting tasks which have been highlighted as high importance to the project. We should highlight that we don't want to be going through the wishlist, but have been forced to. And we should also perhaps state that we would ideally like to have additional resources allocated to new page review, so that we do not adversely impact the development of other stuff on the Community Wishlist from getting done. I'm getting closer to an idea of what I think the submission should look like and I'll draft something soon and put it to you guys to have a look at. — Insertcleverphrasehere (or here) 16:17, 23 October 2018 (UTC)  
Off Topic
Not to mention the fact that the devs have now started blocking our people from p;osting on Phab. Tht's their way of finally sweeping all the tickets under the carpet that Insertcleverphrasehere has been creating. Thers's another WMF critical Signpost article lurking there... Kudpung กุดผึ้ง (talk) 11:14, 24 October 2018 (UTC)
Er... they have? That's a bit rich. --Elmidae (talk · contribs) 11:50, 24 October 2018 (UTC)
Well, that happened once, and he did swear; but not a good look on their part. Lets wait and see before we jump into full conspiracy theory journalism mode ;D — Insertcleverphrasehere (or here) 11:52, 24 October 2018 (UTC)
Please observe the Code of Conduct when contributing on Phabricator. What's described above falls squarely into "unacceptable behavior". If this group decides to endorse, condone or tolerate it, I'm out of here. I will have nothing to do with abuse directed at developers. This has to stop, now. --Vexations (talk) 12:20, 24 October 2018 (UTC)
Vexations, I agree with you that the Code of Conduct should always be followed, and also agree that WBG was being too vociferous; though I do understand where he is coming from. He did drop an F-bomb, however, I don't see anything in the Code of Conduct that explicitly bans 'strong language', so his ban on Phab (even if temporary) does seem to be a punch at daring to complain (especially given that both comments cited are to do with WMF overreach).[2] — Insertcleverphrasehere (or here) 12:37, 24 October 2018 (UTC)
And we should also perhaps state that we would ideally like to have additional resources allocated to new page review, so that we do not adversely impact the development of other stuff on the Community Wishlist from getting done. I suggest this bears highlighting as an important point (both "politically" and for practical future development). --Elmidae (talk · contribs) 19:38, 23 October 2018 (UTC)

Community Wishlist Submission Draft

Pinging all contributors: Barkeep49, Ozzie10aaaa, Vexations, Winged Blades of Godric, Kudpung, CASSIOPEIA, Atsme, Ajpolino, Usernamekiran, Elmidae, Araratic, K.e.coffman, Galobtter, Rosguill, SshibumXZ, DGG. — Insertcleverphrasehere (or here) 10:10, 29 October 2018 (UTC)

@Insertcleverphrasehere: Is this about the NPP tool only, or the AFC process one as well? For example, it would be nice if the AFCH script maintained one's "AfC log" similar to PROD and CSD logs. It would help with "where are they now" type of queries, or to check for any red links, as a feedback and learning-by-doing mechanism. --K.e.coffman (talk) 00:47, 31 October 2018 (UTC)
K.e.coffman, Note that [this tool] is essentially an 'AfC log'. While many of the Phab tasks that we chose will be specific to NPP, some will add useful features to the AfC NewPagesFeed too (such as the tasks related to flagging potential issues). — Insertcleverphrasehere (or here) 07:51, 31 October 2018 (UTC)
@Insertcleverphrasehere: do you know if there's a way to filter out "declines" and only show "accepts"? In re: this tool. --K.e.coffman (talk) 17:47, 4 November 2018 (UTC)
I don't think so but pinging enterprisey who wrote that. Best, Barkeep49 (talk) 17:50, 4 November 2018 (UTC)
K.e.coffman, I just added filtering. Enterprisey (talk!) 22:39, 4 November 2018 (UTC)
@Enterprisey: thank you; this works great. K.e.coffman (talk) 03:36, 5 November 2018 (UTC)

Reviewer Notes System

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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.

T-shirt for Insertcleverphrasehere

While we're here discussing the Reviewer of the year award, please see this nomination to get Insertcleverphrasehere a t-shirt from the WMF. Power~enwiki also has an active nomination there. Cheers, Polyamorph (talk) 11:52, 5 November 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:New_pages_patrol/Reviewers/Archive_30&oldid=869766536"