Page MenuHomePhabricator

Enable page curation tools to be loaded on any page (optionally)
Open, NormalPublic

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 19 2018, 4:06 PM

@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
MusikAnimal claimed this task.
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.
Restricted Application edited projects, added Community-Tech; removed Community-Tech (Kanban). · View Herald TranscriptTue, May 28, 3:58 PM
Samwilson claimed this task.Wed, Jun 5, 1:59 AM
Samwilson moved this task from Ready to In Development on the Community-Tech (Kanban) board.
Samwilson removed a project: Community-Tech-Sprint.

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.EditedWed, Jun 5, 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.