Page MenuHomePhabricator

Enable page curation tools to be loaded on any page (optionally)
Open, NormalPublic3 Story Points

Description

Value proposition:

Page Curation toolbar provides access to some valuable tools that can be used for any page. It should be possible to use these tools on all pages on the wiki.

Acceptance criteria:

  • Show a new link under the Tools menu on article pages: "Add article to NewPagesFeed" link in the sidebar on all article pages that are not already in the feed.
  • When a user clicks on that link, the article gets added to PageTriage feed and the Curation toolbar becomes visible
    • This may need a page refresh. That is acceptable.
    • The "Add article to NewPagesFeed" link in the sidebar goes away once the article gets added to the feed.
    • The article added to the feed is in unreviewed state by default.

Notes:

Details

Related Gerrit Patches:
mediawiki/extensions/PageTriage : masterMake sure old manually added pages stay in the queue
mediawiki/extensions/PageTriage : masterWhen requeueing a page, log that the page is unreviewed
mediawiki/extensions/PageTriage : masterAdding page to the queue functionality

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Who should see the "Curate this article" link in the sidebar? Every logged in user? Every extendedconfirmed user?

In the task description, it specifies

The Review tab button is disabled with a hover message: This article in not in the New Pages Feed and hence cannot be reviewed.

However, pages in any namespace can be reviewed for 30 days, via Special:NewPages. I suggest, instead, to only disable the message if the page has already been patrolled and is no longer available in the New Pages Feed

Who should see the "Curate this article" link in the sidebar? Every logged in user? Every extendedconfirmed user?

Only people who have permission to review articles via the Special:NewPagesFeed.

Niharika added a comment.EditedJun 5 2019, 9:44 PM
In the task description, it specifies

The Review tab button is disabled with a hover message: This article in not in the New Pages Feed and hence cannot be reviewed.

However, pages in any namespace can be reviewed for 30 days, via Special:NewPages. I suggest, instead, to only disable the message if the page has already been patrolled and is no longer available in the New Pages Feed

Are pages reviewed via Special:NewPages also marked as reviewed in Special:NewPagesFeed?

In the task description, it specifies

The Review tab button is disabled with a hover message: This article in not in the New Pages Feed and hence cannot be reviewed.

However, pages in any namespace can be reviewed for 30 days, via Special:NewPages. I suggest, instead, to only disable the message if the page has already been patrolled and is no longer available in the New Pages Feed

There needs to be some amount of time after a page is patrolled that it can be unpatrolled - I would suggest 3 to 7 days. Right now it's too easy to accidently patrol an old article and have no easy recourse to undo. At https://en.wikipedia.org/wiki/Battle_of_Ronas_Voe a person used the under review tag which patrolled the article and thus made it impossible for them to have done anything should they have decided not to complete their review, or otherwise not find it appropriate to patrol.

In the task description, it specifies

The Review tab button is disabled with a hover message: This article in not in the New Pages Feed and hence cannot be reviewed.

However, pages in any namespace can be reviewed for 30 days, via Special:NewPages. I suggest, instead, to only disable the message if the page has already been patrolled and is no longer available in the New Pages Feed

Are pages reviewed via Special:NewPages also marked as reviewed in Special:NewPagesFeed?

@MusikAnimal Yes and vice versa (as far as I know and just confirmed in some limited testing).

When the toolbar is turned on, it makes an API request to get the metadata about the page, but the pagetriagelist endpoint doesn't return info about pages that aren't in the queue. So we have the option of either extending that endpoint (e.g. with an additional includeall flag), or having the toolbar make a second request to get the missing metadata (it's looking for creator, creation date, redirect status, etc. — all the ones that are independent of the review queue). This metadata is mainly used on the 'info' flyout tab, as well as for e.g. leaving comments for the page creator. It then uses other PageTriage API endpoings such as pagetriagetagging to submit the data, and these also only work for pages in the queue.

I'm just wondering how far we want to go with adapting PageTriage to work with non-PT pages.

I am a little weary changing this behavior inside the toolbar itself.

The code makes an inherent assumption that any page it's on is in the PageTriage database. Since that assumption is deep, we don't have any checks on it, and the implications of what happens if we change the behavior is not immediately obvious. Changing the behavior to account for pages in *or not in* the database has a pretty big potential for us to go in circles with unexpected bugs and weird behavior changes that I am not sure is worthwhile to tackle. It will definitely make this work a lot more risky and probably longer-term than what we currently have.

Since the toolbar makes the assumption that it only appears on pages that are in the queue, we could solve this by allowing any page to be inserted into the queue.

That is -- we can add a button to pages that enable reviewers to "Triage/Curate this page". Clicking it would insert the page into the PageTriage database and queue, and will then activate the toolbar. The "business logic" will be safe, then, because the assumption that the page is in the DB is correct, and the reviewer will be able to do what they need to do and review the page.

The only potential issue here is having the PageTriage database bloat and balloon uncontrollably; that is, if we allow for pages to be added into the database, we should encourage the marking of those pages as reviewed as soon as possible so they don't bloat the database. It sounds like the entire point of this feature is to enable this anyways, so that shouldn't be a problem.

@Niharika tagging you on this for product input.

@Samwilson I discussed this briefly with @Mooeypoo over chat yesterday. The core ask here is to let reviewers access the tagging and deletion nomination tools on any page. If we can disable the Info flyout (i.e. ignore asking for the metadata entirely), that would work just fine. As long as the Tag and Deletion flyouts work as expected.
If doing that is a problem too, I think the option to let users add the page to the queue before giving them access to the toolbar could work too. I have a similar concern as Moriel noted above - the queue will unnecessarily grow with articles that don't actually need a review. It can be confusing for other reviewers to see such articles in the feed and might lead to duplicate effort by reviewers.
Let me know what you think.
@Insertcleverphrasehere @Barkeep49 What are your thoughts on this (based on Sam and Moriel's comments above)?

@Samwilson @Mooeypoo There is an ongoing discussion about this on the wiki. It looks like there is agreement that having a link to add the page to the feed is an acceptable solution. Let's proceed with that. I will update the ticket description and bring this back for estimation.

Niharika updated the task description. (Show Details)
Niharika removed the point value for this task.
Niharika moved this task from Untriaged to To be estimated/discussed on the Community-Tech board.

Kudpung has documented that the curation toolbar being available on anypage once existed. He suggests that @kaldari might have more information about the topic. The diff where he discusses this is at: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3ANew_pages_patrol%2FReviewers&type=revision&diff=904108131&oldid=903982992

I hope this information is useful.

I think in general having a button to add pages to the Queue would be an improvement. Yes it could lead to people re-adding too many pages and creating duplicate work, but that is something that the NPP community can make rules for how/when it should be used and there will be a relatively small community of people with this ability. Small enough to not be a problem. The benefit outweigh's the risk.

Thanks @Barkeep49 and @Insertcleverphrasehere. Can you look over the task description and make sure it is as expected? Thank you.

I think the article should be added to the feed in whatever state it is currently in. I don't believe, when this used to be an option, that it would either add it to the queue or mark it unreviewed. Adding it to the feed isn't the end of the world if it doesn't trigger an unreview by default. That's my two cents. Pinging @Kudpung in case he wishes to comment here directly.

I don't think it makes sense to add a page that is currently patrolled to the queue, only for it to remain patrolled and eventually leave the queue without needing any action

Samwilson removed Samwilson as the assignee of this task.Jul 2 2019, 11:22 PM
Samwilson added a subscriber: Samwilson.
Niharika set the point value for this task to 3.Jul 2 2019, 11:40 PM
MaxSem claimed this task.Jul 15 2019, 5:12 PM
MaxSem moved this task from Ready to In Development on the Community-Tech (Kanban (Q1 2019-20)) board.
MaxSem added a subscriber: ifried.Jul 15 2019, 10:40 PM

@ifried, do we need logging for this?

@ifried, do we need logging for this?

Is there any existing logging for the toolbar loading? If yes, let's keep it. If not, I am inclined to skip it. We are not going to be looking at this data in the long term to make any changes to the software.

kaldari added a comment.EditedJul 16 2019, 2:50 AM

@Barkeep49 - FYI, the curation toolbar was never available on any page. It was available on pages that had been in the Page Curation queue within the past 30 days (even if they had already been reviewed). This link is still in the Tools menu for such pages (AFAIK). Look for "Open Page Curation" in the menu.

@Niharika, @Mooeypoo - Note that at one point there was a cron-jobbed maintenance script (updatePageTriageQueue.php) running on the production servers that automatically removed any pages from the pagetriage_page table (i.e. the "queue") if they had been marked as reviewed and were at least 30 days old. If that maintenance script is still running, it will need to be modified to take these exceptions into account, i.e. pages which have been added back to the queue manually. You'll also need to figure out what you want to do with them in the long run. Should they also expire from the queue again at some point?

@kaldari thanks for that background knowledge. This makes sense and would be fine, however is not consistently the case at the moment as it seems to time out after 30 days after creation and not even necessarily 30 days in the queue.

Barkeep49 added a comment.EditedJul 16 2019, 2:28 PM

So as to complicated the picture, here's an example of where it would be potentially helpful to have page curation:
https://en.wikipedia.org/wiki/Malik_Ofori

It was created on April 9 (currently 98 days ago) but it was only patrolled (by me) on July 15 (2 days ago) but because it's outside that window it can not be unreviewed or otherwise addressed in some way by a patroller.

@kaldari thanks for that background knowledge. This makes sense and would be fine, however is not consistently the case at the moment as it seems to time out after 30 days after creation and not even necessarily 30 days in the queue.

Looks like you're right. I stand corrected.

Change 529444 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/PageTriage@master] Adding page to the queue functionality

https://gerrit.wikimedia.org/r/529444

ifried added a subscriber: Prtksxna.EditedAug 16 2019, 11:42 PM

Pinging @MusikAnimal, @Prtksxna, @Barkeep49, @DannyS712, and @Insertcleverphrasehere to see if they have any feedback, based on the request from @MaxSem (see above). I have written out how we can potentially rephrase some of the language to make it more clear, but I would love some feedback from other people. I've also updated these suggestions, based on some feedback from @Mooeypoo (see comment below). Here are the sections that Max has requested that we review:

  1. ”logentry-pagetriage-curation-enqueue": "$1 {{GENDER:$2|added}} $3 to the page curation queue”
    • Potentially change to: “$1 {{GENDER:$2|added}} $3 to the New Pages Feed”
  2. "pagetriage-enqueue-title": "Add article to new pages feed",
    • Potentially change to: “Add article to the New Pages Feed”
  3. "pagetriage-enqueue-tooltip": "Put this page up for curation feed as if it was newly created",
    • Potentially change to: “Mark this page as a new article in the New Pages Feed”
  4. "pagetriage-enqueue-confirmation": "Add this page to new pages feed?"
    • Potentially change to: “Are you sure you want to add this page to the New Pages Feed?"
  5. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."
    • Potentially change to: "Page ID for the article that the action is performed on"
  6. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
    • Potentially change to: "Boolean value specifying whether the article is reviewed"
  7. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."
    • Potentially change to: "Boolean value instructing the system to add the article to PageTriage queue"
  1. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."
    • Potentially change to: “Select this article”
  2. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
    • Potentially change to: “Specify whether the article is reviewed”
  3. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."
    • Potentially change to: “Page will be added to the PageTriage queue”

Just as a general clarification, those messages (whose keys start with apihelp-) are actually not shown in the interface; they're messages for the API documentation (technical) shown next to parameters to explain their purpose.

It would show as something like

pageId      The article for which to perform action on
reviewed  If set, specifies whether the article is reviewed

etc.

I'd suggest these clarification changes, instead:

  1. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."

"Page ID for the article that the action is performed on."

  1. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."

"Boolean value specifying whether the article is reviewed."

  1. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."

"Boolean value instructing the system to add the article to PageTriage queue"

Also, @MaxSem I am not sure about how the API docs work, but is there a way to explain in the API docs that two values are an "either/or"? (either use reviewed or enqueue but not both, and at least one is required) like we discussed? I am not sure how to note that in the documentation.

Maybe something like "Either this value or enqueue must be supplied, but not both together" to both values?

Sorry for being a bit daft but can you explain what the context for 1-7 is? Are they all alternatives or, from my quick look at the code, things which would trigger under different conditions?

Sorry for being a bit daft but can you explain what the context for 1-7 is? Are they all alternatives or, from my quick look at the code, things which would trigger under different conditions?

See qqq.json for descriptions of each message, not sure if that helps here.

Right now the patch allows user pages as well as mainspace pages to be added to the queue. Is that we want? If so the word "page" should be used instead of "article".

Meanwhile "New Pages Feed" might be more correct than "page curation feed" or "page curation queue", going by Wikipedia:New pages patrol/Reviewers, Wikipedia:Page Curation/Help, etc., but frankly I think all variations are unambiguous.

Note the community is free to override system messages as desired by editing the on-wiki interface pages (requires admin assistance).

  1. "pagetriage-enqueue-confirmation": "Add this page to new pages feed?"
    • Potentially change to: “Add this page to the New Pages Feed?”

Would it be better to make it read more obviously like a question or confirmation? Something like, "Are you sure you want to add this page to the New Pages Feed?".

  1. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
    • Potentially change to: "Boolean value specifying whether the article is reviewed"
  2. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."
    • Potentially change to: "Boolean value instructing the system to add the article to PageTriage queue"

I don't think non-technical users should be expected to know what Boolean is. Can you share a bit more context of where people will see it? I checked out the qqq.json (thanks @MusikAnimal) but couldn't really figure it out.

Api help messages are seen in the help api module - pagetriage messages are at https://en.wikipedia.org/w/api.php?action=help&modules=pagetriageaction
I don't think we should label these as "boolean value", since the variable type should already be set to boolean. Eg, for editing via the api, the api help says that, to mark an edit as minor, the parameter minor - Mark this edit as a minor edit. is an HTML boolean, meaning that, if any value is given, the value is interpreted as true. That is a complicated way of saying that minor=foo sets it as a minor edit. For these messages, we should change them to:
"apihelp-pagetriageaction-param-reviewed" - mark this article as reviewed
"apihelp-pagetriageaction-param-enqueue" - add this page to the PageTriage queue
the fact that the variables are booleans means that there is a link to an explanation of boolean api parameters already given

I'm not sure that what is being done here corresponds exactly to the original request at Page Curation, Suggested improvements.

ifried added a comment.EditedAug 19 2019, 6:16 PM

• I've updated the proposed messages above to only state "New Pages Feed" (rather than "page curation feed" or "page curation queue"). Thanks for that clarification, @MusikAnimal.
• I've updated the confirmation message above to more explicitly ask the user a question, as per the suggestion of @Prtksxna.
• Regarding the more technical language, as brought up by @Prtksxna: From my understanding, #5-7 are not user-facing. Is this correct, @MaxSem? What would be an example of when someone sees those messages?
• Regarding the API Help message suggestions, as stated by @DannyS712: I'll leave these decisions up to @Mooeypoo and other technical folks (if I'm correct in the assumption that these are messages for technical people only). Thanks!

ifried added a comment.EditedAug 20 2019, 10:19 PM

We've reached a decision: the final wording will be in my message above (where you can find #1-7, written out). Note that #1-4 are user-facing, and #5-7 are not for general users, as the messages would typically be found in the MediaWiki API documentation page or the API sandbox. Thanks, everyone!

Updated messages are up for review.

Just a note that the add-to-queue functionality is available in the userspace, yet we're using the word "article" in the messaging. I think "page" should be used instead, since user pages are by definition not articles (though they could be draft articles).

https://en.wikipedia.org/wiki/Wikipedia:What_is_an_article%3F

Change 529444 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Adding page to the queue functionality

https://gerrit.wikimedia.org/r/529444

dom_walden added a subscriber: dom_walden.EditedSep 12 2019, 1:46 PM

@Niharika, @Mooeypoo - Note that at one point there was a cron-jobbed maintenance script (updatePageTriageQueue.php) running on the production servers that automatically removed any pages from the pagetriage_page table...

@kaldari thanks for that background knowledge. This makes sense and would be fine, however is not consistently the case at the moment as it seems to time out after 30 days after creation and not even necessarily 30 days in the queue.

From the code (cron/updatePageTriageQueue.php line 70):

// Remove pages older than 30 days, if
// 1. the page is in the article namespace and has been reviewed, or
// 2. the page is not in main or draft namespaces or
// 3. the page is a redirect

Suggests that old articles that have been put back into the queue may be removed if they are in the User namespace or are redirects (or are like articles mentioned in T207485#5337188). Can @MaxSem or @MusikAnimal comment whether the cron still runs, and if what I've said is accurate?

I'm still not sure that what is being done here corresponds exactly to the original request at Page Curation, Suggested improvements. I don't see any mention in No.80 of putting pages back into the feed.

What I understood to be required (which I endorse), is for a 'Curate this page" link to appear under 'Tools' in the sidebar of any user who has New Page Reviewer or Admin right.s

Change 538123 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/PageTriage@master] Make sure old manually added pages stay in the queue

https://gerrit.wikimedia.org/r/538123

The above change addresses Dom's comments. Ready for review.

Change 538409 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/PageTriage@master] When requeueing a page, log that the page is unreviewed

https://gerrit.wikimedia.org/r/538409

Change 538409 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] When requeueing a page, log that the page is unreviewed

https://gerrit.wikimedia.org/r/538409

Following up from enwiki discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard&oldid=918230402

The #p-pagetriage-enqueue list item really isn't useful on {{MediaWiki:Mainpage}} - do we need to hack this off project side or can it be fixed centrally?

Moving to in development - a few bugs already found but not merged yet (see sub tasks)

MaxSem removed MaxSem as the assignee of this task.Oct 10 2019, 2:46 AM
MaxSem added a subscriber: MaxSem.

Change 538123 abandoned by MaxSem:
Make sure old manually added pages stay in the queue

Reason:
Okay, I was completely lost when I was writing this.

https://gerrit.wikimedia.org/r/538123