This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 25 | ← | Archive 27 | Archive 28 | Archive 29 | Archive 30 | Archive 31 | → | Archive 35 |
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:
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:
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)
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)
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)
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)
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)
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)
?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)
?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, 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)
?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)?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)
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:
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)
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)
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)
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)
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)
( 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)
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)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 25 | ← | Archive 27 | Archive 28 | Archive 29 | Archive 30 | Archive 31 | → | Archive 35 |
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:
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:
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)
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)
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)
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)
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)
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)
?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)
?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, 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)
?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)?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)
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:
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)
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)
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)
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)
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)
( 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)
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)