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:

Event Timeline

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

@Insertcleverphrasehere: Adding PageCuration project tag so this task can be found when looking at PageCuration tasks at https://phabricator.wikimedia.org/tag/mediawiki-extensions-pagecuration/ . No need to add team tags like Growth-Team; that is up to each team (or automatic filters).

@Insertcleverphrasehere this would be tricky the way the software is currently structured.

When articles are in the PageTriage queue, there is a process that compiles pieces of metadata about the article, and that metadata is pulled into the curation toolbar when you view an individual page. If we wanted the toolbar to load for pages not in the queue, I think we would do something like:

  • Load the toolbar with minimal to no data
  • Provide a button for reviewers to add the article to the PageTriage queue and compile metadata. This process can take a few seconds.
  • Pull that data back in to the toolbar

Once a reviewer did that (even if they took no further review action), the article would be in the PageTriage queue which might be confusing to other reviewers?

@kostajh That would probably work totally fine. There is already a button to add the article to the queue (the review/unreview button). I don't think that would often be necessary, but it might come in handy to enable flagging of articles for other reviewers (especially in combination with the reviewer notes system (T207452) that is proposed as part of the upcoming community wishlist proposal).

The better thing would be allowing reviewers access to the tagging and deletion nomination tools that they are used to, even when not reviewing new pages and I think your proposal would provide that.

JTannerWMF moved this task from Inbox to External on the Growth-Team board.Mar 19 2019, 6:14 PM
JTannerWMF added a subscriber: JTannerWMF.

It appears the CommTech team is working on this.

@Insertcleverphrasehere You mention that it's important to have tagging and deletion tools be available on all pages. Are there any other tabs in the toolbar that you would think be useful on all pages? Keeping in mind that the metadata is not available as it's not in the queue.
I'm thinking that we can achieve the desired wish by selectively only loading toolbar tabs that are useful on all pages. For pages in the queue, users will see the entire toolbar.

@Niharika Might as well load up the 'appreciation' section as well as tagging and deletion.
Would the page info section still be able to load even without the extra metadata? It is useful to have the info tab as well, as it gives the author info and page history without having to navigate away from the page and also ties into other NPP tools such as the copyvio check script (https://en.wikipedia.org/wiki/User:FR30799386/copyvio-check), which loads its output at the bottom of that tab.

The only bit that doesn't need to load is the review button and message to creator button, but perhaps that could just be greyed out as currently happens with pages that you yourself created?

@Insertcleverphrasehere Yes, the page info section will still be available without the extra metadata about potential issues (and anything else that is computed exclusively for articles in the feed). Sounds good to me to keep the Wikilove flyout too. We can disable the review tab, like you suggested.

Niharika triaged this task as Normal priority.Apr 24 2019, 9:40 PM
Niharika updated the task description. (Show Details)
Niharika added a project: Community-Tech.
Niharika moved this task from Untriaged to To be estimated/discussed on the Community-Tech board.
Niharika set the point value for this task to 5.Apr 25 2019, 5:45 PM
Niharika moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
MusikAnimal moved this task from Ready to In Development on the Community-Tech-Sprint board.
MusikAnimal removed MusikAnimal as the assignee of this task.May 9 2019, 9:55 PM
MusikAnimal moved this task from In Development to Ready on the Community-Tech-Sprint board.
MusikAnimal added a subscriber: MusikAnimal.

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.EditedFri, Aug 16, 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.EditedMon, Aug 19, 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.EditedTue, Aug 20, 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!