Wikipedia talk:New pages patrol/Reviewers/Archive 29

From WikiProjectMed
Jump to navigation Jump to search
Archive 25 ← Archive 27 Archive 28 Archive 29 Archive 30 Archive 31 → Archive 35

Curation toolbar display rules

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

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

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

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

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

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

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

  • Question: Would this have it up for ALL articles? Like if I'm looking at Transport a clearly notable topic that is also as old as they get would I see the bar? Or are we just talking about articles that are in Special:NewPagesFeed? Best, Barkeep49 (talk) 01:41, 26 October 2018 (UTC)
@Barkeep49: this would only happen for pages that can be found in the New Pages Feed. Sorry, I should have said that in my description; I just didn't want it to sound like it would only happen if you went to the page from the New Pages Feed. The settings would stay respected no matter where you opened the page from. -- MMiller (WMF) (talk) 04:52, 26 October 2018 (UTC)
Perfect. I strongly support this change. Best, Barkeep49 (talk) 05:40, 26 October 2018 (UTC)
  • Yes, please do this. Natureium (talk) 02:09, 26 October 2018 (UTC)
  • @MMiller (WMF): Hi. Thanks for the ping. I am not sure about the current rule #2. I mean, a few days ago, when i refreshed the page, or visited the talkpage, and came back to article; the curation toolbar used to be gone. Also, we should set a clear-cut limit for old articles. I think the toolbar should be shown on the pages till 30 days after they have been patrolled. —usernamekiran(talk) 03:02, 26 October 2018 (UTC)
@Usernamekiran: I looked into this a little bit. I think that reviewed articles remain in the feed for something like 90 days after they are reviewed (at least, it looks to me like the oldest ones are from July 2018). The toolbar should continue to be available on those. Do you see otherwise? -- MMiller (WMF) (talk) 20:35, 26 October 2018 (UTC)
Thanks Marshall. I think you are right. I cant say anything else as I am pretty confused because of the vanishing of toolbar —usernamekiran(talk) 21:08, 26 October 2018 (UTC)
  • Thx MMiller - I like having the toolbar auto open when reviewing in the queue, and like having a collapse/open icon on the top of the bar. When we check “reviewed” on the bar, does it show up somewhere on the article that it was reviewed and by whom? As for the other features/suggestions, I can adjust to whatever you introduce as long as it comes with instructions and doesn’t require us to write code. 😉 Atsme✍🏻📧 03:06, 26 October 2018 (UTC)
@Atsme: there are two ways (that I know of) to see who reviewed an article:
  • By clicking on the "i" icon in the curation toolbar when you're viewing the article. That will open a "Page Info" box.
  • By looking at the logs for a page, like here at this link (accessed by clicking "View logs for this page" from View History).
Does this answer your question? -- MMiller (WMF) (talk) 20:35, 26 October 2018 (UTC)
And then some!! Thank you MMiller. Atsme✍🏻📧 03:24, 27 October 2018 (UTC)
  • Thx, the new rule seems fine to me (there is now a gadget to permanently disable the toolbar, but this solution would be better for most people and worse for no one I think). Fram (talk) 07:03, 26 October 2018 (UTC)
  • @MMiller (WMF):I don't know if I like this idea at all. For new reviewers especially, it is easy to 'lose' the the toolbar. If dismissed once, they won't be able to find it again unless they know that the little 'curate this article' link is there, which is easy to miss (this situation existed recently and call me stupid, but I was one of those people who 'lost' the toolbar: If I can do it, anyone can). For those that don't want the curation toolbar to show up, we now have a gadget that permanently disables it, I would prefer that it be set up to automatically pop up no matter what on new articles. The gadget could be changed to add the functionality you describe though (disable automatic popup, only pull it up manually from the 'curate this article' link)
We also need to talk about enabling Page Curation use on any article. Please do that while you are doing this. Ideally the Page curation toolbar should pop up automatically on pages in the New Pages Feed, automatic popup can be disabled in gadgets, and can be pulled up via the 'curate this article' on any article (Also, if disabled, you should still be able to pull it up manually for one time use by clicking 'curate this article'). We need options we don't need a situation where new reviewers might ose the tools and then stop reviewing because they can't find them anymore. Please don't make it even easier to lose the toolbar. — Insertcleverphrasehere (or here) 07:55, 26 October 2018 (UTC)
    • Can't we just tell them what they need to click to open the curation toolbar? There are a lot of things they need to know for patrolling articles. It doesn't seem like a burden on anyone to have to know to click the link in the sidebar. Natureium (talk) 13:39, 26 October 2018 (UTC)
  • Before I comment on this, I'd like to out myself as a doofus... what "Curate this article" link are y'all talking about? This seems to be present in no navigation menu I can access, be it left or anywhere else :/ . For me the only way to get the curation bar to pop up has always been to enter the article via the new pages feed (either by clicking on the article link or on "Review"). --Elmidae (talk · contribs) 08:15, 26 October 2018 (UTC)
@Elmidae: This is exactly the problem. The 'curate this article' link only appears if you have dismissed the toolbar (click the top minimise button then the x), AND you are on a new article. We get used to not seeing it be there, so how are we supposed to know that it is the way we get the toolbar back after we dismiss the toolbar? Recently when the toolbar could be 'dismissed' semi-permanently, I 'dismissed' my toolbar (on accident as I don't remember doing it) and I thought my system was bugged as there was no way to get it back. I had no idea that the 'curate this article' link existed as it had never been visible to me before. To me it seems wildly unintuitive. — Insertcleverphrasehere (or here) 08:25, 26 October 2018 (UTC)
Oh, I see. Never went there. Yep, that's pretty much gone for good once closed, if you don't know about the mechanics. However, apart from that niggle, I do like the simplified approach as suggested by MMiller. Maybe one could counteract the baffling disappearance by a popup or note that comes up when you click the 'x', reminding you that there is now a link to re-enable the bar in the navigation menu? --Elmidae (talk · contribs) 08:45, 26 October 2018 (UTC)
Most people are pretty desensitised to popups, its pretty easy to miss them. And if you miss it, its gone 'poof'.
A button in preferences to disable automatic popup is a better solution. This gives everyone what they want (people who want it available will have it pop up whenever they visit a new page and will be able to use the 'curate this article link on other pages, people who want it gone forever can disable automatic popup in preferences, and people who want it to only pop up manually can disable automatic popup in preferences and then click 'curate this article' whenever they need the tools. — Insertcleverphrasehere (or here) 09:06, 26 October 2018 (UTC)
I really don't see why this is a problem. It's something you have to learn once. You can even add it to the long and intimidating flow chart if that makes it easier. Now Elmidae knows, and so will everyone else when we tell them. Natureium (talk) 13:40, 26 October 2018 (UTC)
Tracked in Phabricator
Task T207485
  • It seems like I am overruled. That is fine I suppose, but @MMiller (WMF): can we please make the 'curate this article' link appear on ALL mainspace articles? The toolbar shouldn't pop up unless clicked on for articles outside the New Page feed, but these tools need to be made available to patrollers whether they are patrolling new pages or random page patrolling, or just stumble across something that needs to be tagged or nominated for deletion. Otherwise we are forced to use twinkle for all of our other work, which needlessly fragments the tool use and deletion logs. Please reply and let me know that you get this message. — Insertcleverphrasehere (or here) 08:51, 27 October 2018 (UTC)
I support this very strongly. I always want the choice. DGG ( talk ) 15:09, 29 October 2018 (UTC)
The whole reason for creating the Page Curation system in the first place, was to draw people away from Twinkle and consolidate the work of patrolling new pages in one place. Curation and it feed were supposed to be light years in advance of Twinkle, and at that time, not knowing that the WMF would refuse to support and maintain it, the system was embraced by many (and me) as the best thing since sliced bread. Kudpung กุดผึ้ง (talk) 20:00, 28 October 2018 (UTC)

Thanks, everyone. We're going to go ahead with the solution we proposed, and with renaming the "Curate this article" link to "Open Page Curation", to hopefully make it a little clearer. Insertcleverphrasehere -- thanks for filing the task about making the toolbar optional on all pages. Unfortunately, it's not as simple as flipping a switch (as one of the engineers said on the task -- the hurdle is that the toolbar is deeply tied in with the database of pages listed in the New Pages Feed). Our team won't be able to spend enough time on this to do it right, so we won't be able to take on that change as part of our work. -- MMiller (WMF) (talk) 00:31, 30 October 2018 (UTC)

Error/issues?

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

The new pages feed works for me on Firefox 61.0.2, Safari 11.1.2, Chrome 68.0.3440.106 on Mac OSX 10.13.6, and Safari on iOS 11.4.1. It doesn't work on Tor Browser 7.5.6, where it shows "This extension requires a JavaScript enabled browser" and in mobile mode on my phone (https://en.m.wikipedia.org/wiki/Special:NewPagesFeed) where is just shows "Please wait..." Vexations (talk) 16:10, 25 August 2018 (UTC)
@Chrissymad: thanks for posting this. the team is looking into it now and seeing if we can reproduce the issue. Other reviewers, please let us know if you are seeing the issue. We will give an update tomorrow. — MMiller (WMF) (talk) 18:40, 25 August 2018 (UTC)
I'm able to scroll past when it sorted by newest but not oldest Galobtter (pingó mió) 18:47, 25 August 2018 (UTC)
Same for me. I have also been having an occasional error in the last day where I am unable to click the next button on certain pages. screenshot Best, Barkeep49 (talk) 18:55, 25 August 2018 (UTC)
It's working fine for me today. Natureium (talk) 18:50, 25 August 2018 (UTC)
Actually, there's a problem for me too that I didn't notice at earlier. If I sort by oldest first, two things happen: scrolling breaks and in the curation tool, the next button stops working before I reach the end of the unreviewed queue. --Vexations (talk) 19:34, 25 August 2018 (UTC)
I have the same problem. I can scroll by newest but not oldest. AmericanAir88(talk) 15:38, 26 August 2018 (UTC)
Something is definitely off. Even when sorting by newest, scrolling stops working at about two days worth of logs. I can get to 20:39, 24 August 2018 (BlackBoxTV) Vexations (talk) 18:39, 26 August 2018 (UTC)

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

MMiller (WMF) I took a screenshot of the dev tools errors when it happened. Will it help to post that to the phab ticket? CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 11:38, 27 August 2018 (UTC)
I noticed today that when patrolling from the front, the tool works as usual, but when patrolling from the oldest end, I was only shown one article. Natureium (talk) 15:11, 27 August 2018 (UTC)

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

@MMiller (WMF): Is indeed now working for me. Best, Barkeep49 (talk) 21:31, 27 August 2018 (UTC)
I was able to scroll though the entire queue both from Newest and Oldest without any problems. Thanks for the fix MMiller (WMF) and team. Vexations (talk) 21:49, 27 August 2018 (UTC)

New Issue?

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

@Barkeep49: thanks for bringing this up. We're looking into it now. In the meantime -- are any other reviewers seeing this? Let me know. -- MMiller (WMF) (talk) 23:46, 29 August 2018 (UTC)
I haven't noticed the issue that Barkeep49 describes, but I also haven't been doing reviews from the back of the queue. I did notice that when I bring up [[Special:NewPagesFeed, it is not current and I need to click Refresh list. Could that be related? --Vexations (talk) 00:31, 30 August 2018 (UTC)
@MMiller (WMF): More details. This only seems to happen when going from Special:NewPagesFeed. If I advance to the next article using the curation toolbar itself it has yet to disappear on me. It also seems, but I have only replicated twice so I wouldn't say with confidence that it's true and not just luck, but if I go to a page with the toolbar and then go back to a page that was not displaying the toolbar, the toolbar then appears for me. Best, Barkeep49 (talk) 17:11, 30 August 2018 (UTC)
@Barkeep49: thanks for the details. I have a few follow-up questions from the engineers on the team:
  • Could you provide links to two or three articles that this is happening on?
  • When the toolbar doesn't load for a page, do you see the link for "Curate this article" under the Tools menu in the left navigation menu?
  • And if you click on that "Curate this article" link, does the toolbar load then?
Thank you. -- MMiller (WMF) (talk) 00:00, 31 August 2018 (UTC)
@MMiller (WMF): It just happened for me on Española Way and Zurmat. Clicking the curate this page resolved both times. Best, Barkeep49 (talk) 16:24, 31 August 2018 (UTC)
MMiller (WMF), in response to what you asked, yes it’s the same or similar issue and it’s erratic. I just pulled up Great Public Schools from the queue - curation bar appeared, I left the article page to check article history, saw a former redirect, so I brought up that page from article history and when I returned to the current article, the curation bar was missing. It returned after I left the page, came here to type this message, clicked on the wikilink I added here, and the curation bar appeared on that article again. I had similar occurrences with a few other articles yesterday. The majority of disappearances occurred when I left the article, but 2 occurred right from the queue. Atsme✍🏻📧 03:28, 22 September 2018 (UTC)
Atsme and Barkeep49 -- just wanted to give you an update that the fix is written and code reviewed, and that it will deploy to English Wikipedia a week from today. I'll get back in touch at that time to check in on whether it has, in fact, fixed the issue for you. Thanks for your patience. -- MMiller (WMF) (talk) 16:39, 27 September 2018 (UTC)
Thank YOU for staying on top of this, MMiller - it is much appreciated. Atsme✍🏻📧 16:56, 27 September 2018 (UTC)
Atsme and Barkeep49 -- we think this issue is fixed now. Please let me know if you are still seeing it! -- MMiller (WMF) (talk) 19:55, 5 October 2018 (UTC)
So far, so good with that particular issue, MMiller (WMF). But...see the following from yesterday - began with an article in the queue because of a redirect - User talk:Lee Vilenski/Archives/2018/October#A page you started (2019 World Seniors Championship) has been reviewed!. The notice went to the editor who created the 1st redirect rather than the article creator. I'm thinking it might be better to give the reviewer the choice of whom to notify if they want to notify anyone at all considering some end-up going to blocked users/socks/t-banned editors, etc. Atsme✍🏻📧 22:38, 5 October 2018 (UTC)
@Atsme: thanks for posting. Do you remember if that is behavior that you've always seen, and you wish were different? Or if it seems to be a new thing that didn't used to happen? -- MMiller (WMF) (talk) 00:10, 10 October 2018 (UTC)
@MMiller (WMF): I haven't really patrolled today but was at E. K. Johnston and did not have the curation bar pop up twice and had to do so manually (it did the third time I visited). Best, Barkeep49 (talk) 03:21, 6 October 2018 (UTC)
@Barkeep49: I'm sorry you're still seeing the issue. That's definitely frustrating. We've created this task to track things as we look into it, because we're hearing some similar things from a few other editors. Does logging out and back in fix it at all? -- MMiller (WMF) (talk) 00:10, 10 October 2018 (UTC)
MMiller (WMF), it was the first time I’ve had the notice go to the editor who created the redirect but it could be an old issue. I recall some discussion in the recent past about notifications going to blocked users, etc. but can’t remember the details. I have a vague recollection of Kudpung either saying we had the option to send or not send notice, or that it was something on the wish list. Perhaps another reviewer with a sharper recollection than my own can provide some input. Atsme✍🏻📧 00:24, 10 October 2018 (UTC)
@MMiller (WMF) and Atsme: there has never been a choice. As in Twinkle, PROD, BLPPROD, CSD, and AfD tags send a message to the original creator (or the person who moved a draft to mainspace through Curation). What we have been asking for is that all tags placed on new pages at Curation send an alert to the creator, otherwise those pages simply remain perma-tagged forever - and do. But of course the developers have stated they are not interested to address the issues on our list. They have hinted that we, the volunteers, should either do their programming for them, or join that Xmas stocking wish list of convenience gimmicks. That might work though if Insertcleverphrasehere can drum up his 640 reviewers to vote for them. And that's one of the reasons why after shepherding NPP for a decade, I've retired from it. That's how the WMF treats it productive volunteers. Kudpung กุดผึ้ง (talk) 08:10, 13 October 2018 (UTC)
Atsme and Kudpung -- thanks for the details. Yes, unfortunately, our team won't be able to tackle that change to the way the workflow behaves, and the 2019 wishlist survey is definitely the right place to bring it up so that the Community Tech team can address it. -- MMiller (WMF) (talk) 22:17, 15 October 2018 (UTC)
@MMiller (WMF): Sorry to disagree yet again, but the wish list is definitely not the place - you know it, Danny knows it, Toby knows it. The CEO is travelling , unreachable for the volunteers, and is kept unaware of it. The NPP system is a vital, indispensable core function of the en.Wiki - it is not something to be 'wished' for. The backlog is growing again, and you/we will end up with no one guarding the gate at all, and all the spam, attack pages, and other junk slipping quietly and permanently into the encyclopedia corpus after being unprocessed for 90 days, and new articles being wrongly tagged for deletion by raw newbies who are still permitted to do it despite our efforts. FYI: @Atsme, Barkeep49, Insertcleverphrasehere, and Usernamekiran:. Kudpung กุดผึ้ง (talk) 02:28, 16 October 2018 (UTC)
@MMiller (WMF), Atsme, Kudpung, and Barkeep49: Hi. I put forward a temporary solution to the visibility of curation bar at special:diff/863686810. —usernamekiran(talk) 08:25, 13 October 2018 (UTC)
@Usernamekiran: thanks for posting that workaround. Our engineers are currently working on toolbar disappearance issues with this task, and I should have an update this week. -- MMiller (WMF) (talk) 22:17, 15 October 2018 (UTC)
  • I've experienced this as well. It is a very urgent issue that needs fixing immediately. This sort of issue leads to less patrolling, and the backlog is raising again. — Insertcleverphrasehere (or here) 03:18, 16 October 2018 (UTC)
Unreviewed page with no PC tools loading
  • @MMiller (WMF): OK, I can't get the Page Curation tools to launch at all, even when navigating directly from the New Page Feed, even for pages from the 'newest' end of the queue. See screenshot at right that shows what I get when navigating to an unreviewed new page directly from Special:NewPagesFeed. No wonder the NPP backlog has spiked by 400 pages in the last couple days, nobody can use the tools! Usernamekiran's temporary solution also does not work, as the ULR clearly shows the ?showcurationtoolbar=1 string is there, but with no tools. Logging out and back in has been suggested, but this also had no effect. This needs to be fixed ASAP. — Insertcleverphrasehere (or here) 12:24, 16 October 2018 (UTC)
@Insertcleverphrasehere: Thank you for the report, a few questions for you: 1) have you tried with ?safemode=1 in the URL? 2) Do you see the text "Curate this article" in the "Tools" menu on the left? 3) In Firefox or Chrome, if you right-click and select "Inspect Element" and click anywhere on the page, then click "Console" in the developer tools bar, then reload the page, do you see any errors printed to the console? KHarlan (WMF) (talk) 17:48, 16 October 2018 (UTC)
Also, Insertcleverphrasehere, we're hoping this isn't a widespread issue, since we know reviews are occurring. But even so, all NPP reviewers need to be able to review, so we're taking this seriously. -- MMiller (WMF) (talk) 19:14, 16 October 2018 (UTC)
@KHarlan (WMF): ?safemode=1, didn't do anything to help, but the "Curate this article" link in the tools did finally make it pop up and now it seems to be working when navigating from the NewPagesFeed, or when navigating to a page in the feed in a tab where I have previously navigated from the New Pages feed, but it still does not come up when navigating to a page in the feed in a new tab from anywhere other than the new page feed. — Insertcleverphrasehere (or here) 21:57, 16 October 2018 (UTC)
@Insertcleverphrasehere: OK, thank you for the update. We're working on a fix in T206580. Thank you for your patience, we'll update everyone here when it's fixed. KHarlan (WMF) (talk) 23:11, 16 October 2018 (UTC)

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

Javascript errors when page loaded from queue
Step-by-step play - went to NPP queue, clicked on review for Jeff Yang - toolbar was present - clicked on edit history to see why it was in queue - saw it was a redirect (vandal) - back to article page and the toolbar is now gone. I went back into the queue and clicked on review - page loaded but had JavaScript error messages - when they disappeared the toolbar displayed. I attached a screen capture of the errors - maybe it will help, maybe it won’t. Atsme✍🏻📧 22:58, 18 October 2018 (UTC)
After loading up Chrome and navigating to my watchlist, I clicked directly to Lani Daniels from my sidebar new page list (this script), no toolbar showed, 😞. Clicking directly from the New Page Feed the toolbar does show up, and opening it in a new tab from the history page of that article it also shows up. After opening that page from the New Page Feed, If I open any page from my sidebar it now does show up. This is pretty much how I remember it working previously, where I had to visit the New Page Feed at least once after opening Chrome up the first time. It would be nice if it didn't do this. I can't recreate the history page and back bug that Atsme experienced.
Could you please clarify what you would prefer when you say "It would be nice if it didn't do this"? KHarlan (WMF) (talk) 13:51, 19 October 2018 (UTC)
  • @MMiller (WMF): @KHarlan (WMF): Also, would it be possible to make ?showcurationtoolbar=1 and the 'curate this article' link work on any article, not just those in the feed? It is quite annoying that the Page Curation tools are only available to me for new pages that haven't expired, it means that I have to use Twinkle whenever a page has been reviewed and expires out of the feed. It silly that the Page Curation tools are only available on new pages and not, for example, on Broadwater Green. IMO the 'curate this article' link in the toolbar should always be available to New Page Reviewers. — Insertcleverphrasehere (or here) 06:23, 19 October 2018 (UTC)
Could you please file an issue in phabricator to track this feature request? KHarlan (WMF) (talk) 13:51, 19 October 2018 (UTC)
It is a good point; it would be handy to have an option to have the bar always available. However, it might actually be annoying to always have it float around even while you are doing non-curation things. Say, just reading articles (happens, every so often ;). So I suggest that would have to be optional. --Elmidae (talk · contribs) 08:33, 19 October 2018 (UTC)
@Elmidae: You can minimize the toolbar then click the "X" to hide it. If ?showcurationtoolbar=1 is not in the URL, then you won't see the toolbar appear unless you click "Curate this article" in the tools menu.

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

@Fram: You can minimise it by hitting the little X. — Insertcleverphrasehere (or here) 14:03, 19 October 2018 (UTC)
Wait... where did the little X go? There used to be a way to minimise it to a tiny bit of 'curation' text on the edge, but this has disappeared mysteriously. — Insertcleverphrasehere (or here) 14:05, 19 October 2018 (UTC)
Ah HA! sorry... I'm silly. The top button minimises it, then the X appears. If you then click the X it will disappear and won't reappear unless you click the 'curate this article' link in the toolbox. It does re-appear if you navigate to a page via the 'review' button at Special:NewPagesFeed. Perhaps a 'disable Page Curation' in Preferences would be the fix that we need for people that don't want the tool to load at all. — Insertcleverphrasehere (or here) 14:10, 19 October 2018 (UTC)
Yes, I can disable it on a per page basis, but not as a general preference. For me, it's just an annoying floating bar obscuring part of the text but which I'll otherwise not use in my new page patrolling (which I do quite often). Fram (talk) 14:24, 19 October 2018 (UTC)
@Fram: it is very odd for a gadget to not be able to be disabled in the preferences pane (perhaps unique), can you make a request on the Wikipedia:Page_Curation/Suggested_improvements page to add this as an option in Preferences? I'll make a Phab Task for it. — Insertcleverphrasehere (or here) 14:28, 19 October 2018 (UTC)
Thanks, request is made. Fram (talk) 14:35, 19 October 2018 (UTC)
Apologies if this is a dumb question, but how are the pages marked as reviewed and removed from the queue if we don’t use the toolbar? Is it automatic with our user rights? Atsme✍🏻📧 14:53, 19 October 2018 (UTC)
Atsme, You can also 'patrol' articles with Twinkle. The New Page feed treats this identically to pages 'reviewed' with the toolbar. Needless to say, only NPR rights holders can 'patrol' articles. — Insertcleverphrasehere (or here) 09:46, 30 October 2018 (UTC)

Copyvio detection now in New Pages Feed

The third and final feature of this project to enhance the New Pages Feed is now in the New Pages Feed for all reviewers! The testing of copyvio detection went well, and so the ability to filter the New Pages Feed to potential copyvios is present for NPP and AfC reviewers.

In this post, I want to give some info on how the new copyvio flag 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!

Here is how to use the feature:

  1. Open the "Set filters" menu at the New Pages Feed.
  2. Check the "Copyvio" box under the list of "Potential issues". This filters the feed to articles that have potential violations.
  3. Those articles have a link in their entry in the feed that says "Potential issues: Copyvio". Clicking that opens up an entry in CopyPatrol where it is possible to investigate the violating text side by side with the source where it may have come from.

For instance, as I write this, there are 19 unreviewed articles in the New Pages Feed flagged as potential copyright violations.

It is important to note, as many reviewers discussed during feature development, that these flags are meant only to draw reviewer attention to potential issues -- they are not meant to be taken as absolute truth. Since they are predictions from an algorithm, it is very common for CopyPatrol to flag an edit that is not a violation at all. In other words, this flag is for drawing reviewer attention to those articles that need their judgment. Similarly, when an article does not have the copyvio flag, it does not necessarily mean that it is not a copyvio.

Here is what is happening in the background:

To detect potential copyright violations, the feed uses the same system that backs CopyPatrol. CopyPatrol is backed by the external service Turnitin, which is primarily used by academic institutions to detect plagiarism. Turnitin scans books, articles, and websites for text matches. CopyPatrol runs all diffs over 500 bytes through Turnitin and flags diffs where there is over a 50% match with some other document.

Pages in the New Pages Feed get flagged as potential copyright violations if any of their diffs (including the initial creation of the article) are flagged by CopyPatrol. The flag will remain with the page in the New Pages Feed as long as the page is in the feed -- even if the violation is resolved in CopyPatrol. For a full explanation of the rules we're using and for the way Turnitin works, see the in-depth discussion from our planning process.

Please let me know if you see any bugs or problems. Since this is the final component of the Growth team's work with the New Pages Feed, we'll keep an eye on performance for the next week, and then post a final update before concluding the project. Thank you all for your input and time spent on these improvements! -- MMiller (WMF) (talk) 00:13, 31 October 2018 (UTC)

@MMiller (WMF): If we need help or explanations as we document (as suggested above) do we need to do this in the next week? Best, Barkeep49 (talk) 00:39, 31 October 2018 (UTC)
@Barkeep49: no, it is okay to do that whenever you are ready. I will continue to be around and contactable (just working on other priorities with the Growth team). Let me know! -- MMiller (WMF) (talk) 12:54 am, Today (UTC+0)

RfC of possible interest

An RfC of interest to New Page Reviewers: Wikipedia_talk:Notability_(people)#RfC:_Amendment_for_BIO_to_address_systemic_bias_in_the_base_of_sources. Regards proposed changes to notability of marginalised persons. — Insertcleverphrasehere (or here) 11:26, 31 October 2018 (UTC)

Semi-automating AfD

Comments please, on Wikipedia:Village pump (idea lab)/Archive 26#Semi-automate DELSORT based on Project tags. Thanks, Cabayi (talk) 14:08, 31 October 2018 (UTC)

Redirects and Reverts

I have been on this team for a few months and I'm still working out a few of the "intangible" nuances of our review process. I tend to work on the "older" end of the list of articles to be reviewed, where you can often find articles that were actually created many years ago but have gone through confusing cycles of redirects, un-redirects, re-creations, merges, and un-merges. If such an article appears on our list as needing to be reviewed, but it is currently in the midst of such a war, is it acceptable to review it as passing our "new article" requirements to get it off our list? Or is it more appropriate to wait for the situation to stabilize? Here is today's specimen, dating way back to 2006: WCVN-TV. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 15:46, 1 November 2018 (UTC)

Doomsdayer520, As I understand from the history, a redirect was undone thus listing the article in the New Pages Feed, which is what I believe is supposed to happen. It should, as far as I understand, therefore be treated as a new article - which in an ideal world should be probably patrolled within a day or two. Kudpung กุดผึ้ง (talk) 16:01, 1 November 2018 (UTC)
@Doomsdayer520: I have made a workflow in reviewing pages oldest that appear in the queue which has received acceptance when reviewed by other project members in the past. Best, Barkeep49 (talk) 16:15, 1 November 2018 (UTC)
@Barkeep49: - Thanks, I was not aware of that essay previously. ---DOOMSDAYER520 (Talk|Contribs) 16:38, 1 November 2018 (UTC)

Inexperienced patrolling

This appears to be a classic error by a not new, but very inexperienced user, and one of the reasons why I had campaigned (unsuccesfully) for the deletion tagging of new pages to be restricted to New Page Reviewers - that was originally why the user right was created. Perhaps someone could mentor them and encourage them to get qualified. Even Epicgenius a somewhat more experienced user (but not a reviewer) made further edits to the article but failed to notice. Kudpung กุดผึ้ง (talk) 14:20, 1 November 2018 (UTC)

Kudpung The error in the AFD nomination not linking correctly is due to what is essentially an edit conflict because the page was moved as they were nominating it. So blame Twinkle or the software. Praxidicae (talk) 14:36, 1 November 2018 (UTC)
Also what does this have to do with NPP exactly? Praxidicae (talk) 14:38, 1 November 2018 (UTC)
Praxidicae, Are you a New Page Reviewer ? Kudpung กุดผึ้ง (talk) 15:40, 1 November 2018 (UTC)
Kudpung Is this relevant in the slightest to the question I asked or anything in this thread? If so, I'm curious to hear why. Thanks! Praxidicae (talk) 15:42, 1 November 2018 (UTC)
Kudpung, I'd really like to see an answer to the above. To me, it looks as though you're implying discussion on new pages should be limited to New Page Reviewers, which I am in strong opposition of. Vermont (talk) 19:05, 1 November 2018 (UTC)
I also don't see what this has to do with NPP. Maybe talking to twinkle developers about this issue would be better, since it doesn't have anything to do with the age of the article. Natureium (talk) 15:45, 1 November 2018 (UTC)
Kudpung, you support restricting the tagging of new pages for deletion, both CSD’s and AfD’s, to New Page Reviewers? Vermont (talk) 14:40, 1 November 2018 (UTC)
Vermont I would favour any guidelines, policies, or methodology that helps to prevent the new user creators of articles with potential from being bitten and discouraged from further participation in Wikipedia. To this end I am also in favour of improving the Page Curation software in order to make the process a more attractive task to suitably experienced users. Note that in both instances I use the word 'favour' and not 'support'. Kudpung กุดผึ้ง (talk) 15:43, 1 November 2018 (UTC)
Kb03, who attempted the AfD and apparently made a mistake, is not a member of this team. Likely a software error at Twinkle, which I have seen happen myself, but not a reason to cite inexperience or to even discuss it on this board. ---DOOMSDAYER520 (Talk|Contribs) 15:39, 1 November 2018 (UTC)
Soryy, Doomsdayer520, my error, I thought this was the 'board' for discussing new page patrolling/reviewing. At least it was when I created it. Kudpung กุดผึ้ง (talk) 15:46, 1 November 2018 (UTC)
This project doesn't own new articles; it can't (and shouldn't) restrict other editors from nominating new pages for deletion any more than it can restrict them from nominating old pages for deletion. An edit conflict bug in Twinkle is really not relevant to this project either. power~enwiki (π, ν) 15:50, 1 November 2018 (UTC)
And that, Power~enwiki, takes completely out of context what I said above. Kudpung กุดผึ้ง (talk) 16:03, 1 November 2018 (UTC)
Kudpung, yes. It is a 'board' for discussing new page patrolling and reviewing, not discussing users nominating articles for deletion (which, if you had checked before bringing it here, you would see is an edit conflict error in Twinkle) or for users’ actions on new articles. As power~enwiki said, the NPR user group does not own new articles. Vermont (talk) 18:49, 1 November 2018 (UTC)
Vermont, if you check the archives of this page, you will establish that this talk page is for discussing all matters concerning the processing of new orders, broadly construed. Please point me to any comments where I have suggested that the NPR use group owns new articles. Thanks.Kudpung กุดผึ้ง (talk) 01:37, 2 November 2018 (UTC)

(edit conflict)::Kb03, nothing to apologise for. The 'team' is here to help. Perhaps the issue has now been resolved and your AfD can go ahead. Kudpung กุดผึ้ง (talk) 16:12, 1 November 2018 (UTC)

I don't mean to be dense here, and I'm probably missing or misreading something obvious, but I'm not quite clear on what we're even discussing on this thread. Are we trying to say there's a problem with Twinkle that needs to be fixed? Did we mistakenly think that it was Kb03's fault that the AfD was messed up? Are we discussing whether Kb03's nomination was not appropriate and wasn't in accordance with certain policies, guidelines, or essays? Or are we discussing whether we should disallow any non-NPRs from marking pages for deletion? Hopefully someone could enlighten me and I'd be happy to take part in the discussion.--SkyGazer 512 Oh no, what did I do this time? 19:23, 1 November 2018 (UTC)
SkyGazer 512, I was thinking of responding to you, but, I got confused as well, there are just to many options here, if you ask me; damn it!VSB;DB! Regards, SshibumXZ (talk · contribs). 21:25, 1 November 2018 (UTC); edited 21:27, 1 November 2018 (UTC).
Ha, thanks for the humor SshibumXZ; that made me laugh.--SkyGazer 512 Oh no, what did I do this time? 21:38, 1 November 2018 (UTC)
SkyGazer512, no problem; that was the intent. Regards, SshibumXZ (talk · contribs). 22:17, 1 November 2018 (UTC)
Oops, I meant to ping SkyGazer 512; sorry! Regards, SshibumXZ (talk · contribs). 22:18, 1 November 2018 (UTC)

Curation tool automatic message

The template that is sent to a page creator by the curation tool when a page is CSD'd includes "If you feel that the article shouldn't be deleted, you can contest this deletion, but please don't remove the speedy deletion tag from the top." Can we remove the "please"? It makes it sound optional, which it is not. Natureium (talk) 17:23, 3 November 2018 (UTC)

Natureium Even you can do so just by editing this page — fr + 14:26, 4 November 2018 (UTC)
​ Done on all CSD templates (except the 'author' one). — Insertcleverphrasehere (or here) 16:30, 4 November 2018 (UTC)
Retrieved from "https://mdwiki.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers/Archive_29"