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

@ifried, do we need logging for this?

In T207485#5335227, @MaxSem wrote:

@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.

@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.

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

Ready for review.

@ifried, could you take a look at the proposed wording of user-facing messages?

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"

In T207485#5419052, @ifried wrote:

5. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."
   • Potentially change to: “Select this article”
6. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
   • Potentially change to: “Specify whether the article is reviewed”
7. "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:

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

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

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

"Boolean value specifying whether the article is reviewed."

7. "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).

In T207485#5419052, @ifried wrote:

4. "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?".

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"

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.

• 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!

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

In T207485#5335656, @kaldari wrote:

@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...

In T207485#5335660, @Barkeep49 wrote:

@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)

This thingie still needs review: https://gerrit.wikimedia.org/r/538123

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

I have created a separate ticket to handle the requeue bug: T239290. So, we'll be testing for general behavior only on this ticket (excluding the requeue issue). I've moved it back into QA so that @dom_walden can confirm that it now looks good (and apologies if you already did, and I just didn't realize!). I just want to be extra sure before I assess it in Product Sign-Off. Thanks!

Much of the testing has been done as part of related bugs/tasks. There is not much else left for me to do.

I briefly retested on testwiki. I can requeue articles and user pages. The logs record that the page has been requeued, and (after T207485#5517909) that it is unreviewed.

It has been in production for a while now and appears to be being used (e.g. https://en.wikipedia.org/wiki/Special:Log?type=pagetriage-curation&user=&page=Ingo+Maurer).

In T207485#5714205, @ifried wrote:

This work is now in production, so I'm marking this work as Done.

I disagree that this should be marked as done - the initial request related to being able to use the page curation toolbar, etc. on any page. So far, this can only be done by requeueing the page, which marks it as unreviewed. It should be possible to use the functionality to, eg, add a maintenance tag, without reviewing the page (T234077: Api: Allow enqueueing without unreviewing, which I'll try to get to soon) or allow a subset of the toolbar features (like tagging) to be used without the page being in the queue

There used to be a link on the sidebar:
'Curate this page'
Somewhere along the line this feature got removed.
It should only have been visible to New Page Reviewers.
It's my guess that someone has confused it with the 'Add to New Pages Feed' feature request - which is now up and running as requested, and removed it.
However, Curate this page' is somewhat different - it's supposed to allow any New Page Reviewer to review a page without having to load it into the feed first.
Can we please have it back?

"Curate this page" was changed to "Open Page Curation". As far as I know, that link was never displayed on pages unless they were currently in the queue or had recently been in the queue.

In T207485#5718734, @kaldari wrote:

"Curate this page" was changed to "Open Page Curation". As far as I know, that link was never displayed on pages unless they were currently in the queue or had recently been in the queue.

And I believe the feature requested was that it always be displayed. While adding the pages back to the queue may accomplish this, its a round-about way of being able to just use the toolbar: requeue -> mark reviewed -> use tools

"Curate this page" was changed to "Open Page Curation". As far as I know, that link was never displayed on pages unless they were currently in the queue or had recently been in the queue.

This is correct. There was never a time when you could use the toolbar on a page that wasn't in the queue. I think the changing of the "Curate this page" text to "Open Page Curation" might be the source of confusion. That change happened as a result of this discussion.

And I believe the feature requested was that it always be displayed. While adding the pages back to the queue may accomplish this, its a round-about way of being able to just use the toolbar: requeue -> mark reviewed -> use tools

Precisely. This was discussed at:

• This task, e.g. T207485#4704044, T207485#5272174
• https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers/Archive_33#Enable_page_curation_tools_to_be_loaded_on_any_page
• https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers/Archive_33#Tech_development_followup

and elsewhere. The issue has to do with scope and technical implications. Page Curation was designed from the ground up to work for new pages, catered to the "New pages patrol" process, and similarly this is why the user group is called "New page reviewer". The whole system requires the page be in the queue. Furthermore, it is simply not feasible to store the necessary metadata for all ~6 million articles, +3.1 million user pages, +9 million redirects, and also some metadata about the ~111 thousand drafts. So being able to add a page to the queue is sort of a compromise that from the aforementioned discussions appeared to be endorsed by the community. Apologies if this wasn't clear!

@MusikAnimal Thanks. Explanation accepted. I must have misunderstood it at the time.