In T50552#5031323, @Aklapper wrote:

@Insertcleverphrasehere: I don't think that single opinions from Wishlist discussions should be picked and put into the task summary. They are welcome to be added here as comments however.

Re: If there is a need for a survey on whether to implement this in zhwp or whatsoever project (I am thinking of maybe simple), I can try to gather consensus onwiki. No promises though. Before that I hope that at least the tool can be wiki agnostic before launching any discussions. Thanks so much.

The Community Tech team has discussed this request, and we unanimously feel that it’s beyond our scope. Here’s why (according to analysis from the engineering team): PageTriage, while a useful extension, is written in a way that’s completely based on English Wikipedia processes. In order to convert the extension to work on other wikis, the extension would need to be adjusted — not only for other processes, but also to have a configurable process definition that each wiki could define for itself, based on each community’s needs. Consequently, this request would require a slew of analyses and decisions, such as: what it means to tag an article for deletion (e.g. what pages messages goes to, what templates are used, if there are follow-ups the system should be aware of, etc), the way we tag articles, which articles show up in the queue, and more. Moreover, we couldn’t easily trim down the scope by disabling some features. The internal workings of the extension are deeply intertwined with English Wikipedia. We would still need to do a significant amount of development work to ensure that the behavior remained stable and useful to other wikis. For these reasons, this request is unfortunately too big, so we cannot take it.

In T50552#5426723, @ifried wrote:

The Community Tech team has discussed this request, and we unanimously feel that it’s beyond our scope. Here’s why (according to analysis from the engineering team): PageTriage, while a useful extension, is written in a way that’s completely based on English Wikipedia processes. In order to convert the extension to work on other wikis, the extension would need to be adjusted — not only for other processes, but also to have a configurable process definition that each wiki could define for itself, based on each community’s needs. Consequently, this request would require a slew of analyses and decisions, such as: what it means to tag an article for deletion (e.g. what pages messages goes to, what templates are used, if there are follow-ups the system should be aware of, etc), the way we tag articles, which articles show up in the queue, and more. Moreover, we couldn’t easily trim down the scope by disabling some features. The internal workings of the extension are deeply intertwined with English Wikipedia. We would still need to do a significant amount of development work to ensure that the behavior remained stable and useful to other wikis. For these reasons, this request is unfortunately too big, so we cannot take it.

I see the following parts as potentially useful cross-wiki:

• Special:NewPagesFeed (without AfC)
  • Select namespace
  • Select state (reviewed vs unreviewed)
  • Select type (only redirect vs non-redirect)
  • Select conditions (only the following)
    • Have no categories
    • Are orphaned
    • Were previously deleted
    • Were created by newcomers (non-autoconfirmed users)
    • Were created by learners (newly autoconfirmed users)
    • Were created by blocked users
    • Were created by bots
    • Were created by _username_
    • Show all
  • Select possible issues (only copyright)
• Toolbar
  • View page information
  • Mark as patrolled (without any messages)
  • Send wikilove
  • Advance to next in queue

I do not believe that any of these specific identified parts of the extension is tied to enwiki, only the coupling between them and the rest of the extension, as well as the other, more specific, parts (like tagging, ORES). Would it be okay to add a global variable, something like $wgPageTriageUseEnwiki, which, if false, disables the other features, and thus allows using this extension on other wikis and in other languages?

@Mooeypoo gave some additional details on the team's decline of this wish on Meta:

Hello all. I'm the Technical Lead for the Community Tech team, and I thought I'd pitch in with an explanation that may answer some of the concerns raised in this conversation, in hopes to at least clarify the process that the team went through in making the decision.

I speak for myself and the team when I say that we share your disappointment about not being able to make PageTriage wiki-agnostic. While we had initial misgivings, due to the historical difficulties of this request, we went into the code with the genuine hope that we could prove this exercise doable. This type of work is part of the mission that drives the movement, the Foundation, and the team in specific, so we all wanted to see if we could make it happen. Unfortunately, we discovered very quickly that this is not the case.

PageTriage was written over six years ago with the goal of working with all wikis. However, due to time and resource limitations, the extension ended up being completed with only support for English Wikipedia's processes around the curation/review of articles and edits. This means two important results. First, the technology is old and difficult to work with, and some of it is no longer supported outside of our technical stack. Second, the entire architecture was written specifically to address the unique workflow of English Wikipedia's processes (from Article for Deletion, to how to notify users about reviews and potential problems).

The code was architected in such a way that these processes are built-in, inherently, into the deep operation of the system. We cannot easily untangle these operations while keeping the extension working. Every step of the process invokes actions that are English-wiki-process specific, and getting those out or allowing to disable them in other wikis (what we call "refactoring") ends up meaning rewriting the majority of the software. Further complexity is added in when we consider that the current technical implementation uses technology that is old and unsupported, which means it is almost impossible to add and edit features, as the code is written right now.

Unfortunately, we are not the first to discover this problem. The technical ticket is full of discussions about how this attempt could be done, along with several attempts made and abandoned by both staff and volunteer developers, due to these considerations.

We take great pride in producing the best solutions that help you, as the drivers of this extremely important process, to do this work with greater ease and support.

When we experience technical constraints, we try to propose a feasible alternative (like the current page views alternative). However, in the case of this request, we found ourselves continuously fighting against the stream. PageTriage is not an easy environment to add features to, and we have to balance the powerful results we want to give you with the technical feasibility of our efforts.

I hope this explanation sheds some light on this decision. Please feel free to examine the technical ticket, as it is the best place to discuss technical concerns and implications with the other technical experts in the movement and continue to strive and solve these issues.

I would strongly object to this being set as declined as it was included in a community wishlist which garnered support across wikis. There's interest in this. I understand why its priority is being set to lowest but again would disagree with it being declined altogether.

I really liked how the Growth-Team move Newscomers tools' wiki-specific configuration to on-wiki JSON, T285423, and then they create Special:EditGrowthConfig to help configure this JSON. It seems to me that this is exactly the path this extension should take.

• Make it possible to configure the desired templates
• Make it possible to configure the necessary filters
• Make it possible to configure the desired menu types

Separately, perhaps this extension needs to be somehow connected with FlaggedRevs, because it adds an extra level of patrolling.

I think @DannyS712 is on the right track above when he says

add a global variable, something like $wgPageTriageUseEnwiki, which, if false, disables the other features, and thus allows using this extension on other wikis and in other languages?

This is the kind of large ticket that should be implemented in baby steps. And I think the first step should be to create a $wg option that turns off all the enwiki-specific features, leaving the wiki-agnostic features. That would hopefully not be nearly as hard as trying to rewrite the deletion tagging and maintenance tagging features.

enwiki specific (need to have a $wg var that turns these off)

• Special:NewPagesFeed
  • Filters
    • "Nominated for deletion"
    • "(not RFD)" part of "Redirects (not RFD)
    • Predicted class: stub, start, c-class, b-class, good, featured
  • List
    • Trash can icon on articles marked for deletion
    • "Predicted class" field
• Page Curation toolbar
  • Maintenance tagging
  • Deletion tagging
• Other
  • investigate assumptions about autopatrolled / autopatrol flag. do all wikis use this the same way as enwiki, to let people create articles without review?
  • api.php?action=pagetriagetagging
  • language / i18n / translations exist but have never been tried. need to test a foreign language, a logographic language like Chinese, an RTL langage, etc.

wiki agnostic (stuff that can stay turned on)

• Most of Special:NewPagesFeed
• Some of the Page Curation toolbar
  • Minimize
  • Page info
  • Wikilove (if that extension is installed and available in your language)
  • Mark as reviewed/unreviewed (including "send a message" feature)
• Special:Log
• NOINDEX feature
• This extension does have language translations/internationalization. There's some way somewhere to toggle that on. So that's one big obstacle already solved. Volunteer translators have been hard at work for years translating. There are 30 language files above 20KB.
• Database schema
• the other 4 API calls

Creating modules to wrap enwiki maintenance tagging and deletion tagging, and then letting those be swappable per wiki, would come in a phase 2, if ever.

Anyway, at risk of stirring up this old hornet's nest phab ticket with 50 subscribers, is there interest in a stripped down version of PageTriage being made available? If so I can't make any guarantees, but I can at least take a look at it and add it to my long term goals. Thanks.

In T50552#8089856, @Novem_Linguae wrote:

I think @DannyS712 is on the right track above when he says

add a global variable, something like $wgPageTriageUseEnwiki, which, if false, disables the other features, and thus allows using this extension on other wikis and in other languages?

This is the kind of large ticket that should be implemented in baby steps. And I think the first step should be to create a $wg option that turns off all the enwiki-specific features, leaving the wiki-agnostic features. That would hopefully not be nearly as hard as trying to rewrite the deletion tagging and maintenance tagging features.

enwiki specific (need to have a $wg var that turns these off)

• Special:NewPagesFeed
  • Filters
    • "Nominated for deletion"
    • "(not RFD)" part of "Redirects (not RFD)
    • Predicted class: stub, start, c-class, b-class, good, featured
  • List
    • Trash can icon on articles marked for deletion
    • "Predicted class" field
• Page Curation toolbar
  • Maintenance tagging
  • Deletion tagging
• Other
  • investigate assumptions about autopatrolled / autopatrol flag. do all wikis use this the same way as enwiki, to let people create articles without review?
  • api.php?action=pagetriagetagging

wiki agnostic (stuff that can stay turned on)

• Most of Special:NewPagesFeed
• Some of the Page Curation toolbar
  • Minimize
  • Page info
  • Wikilove (if that extension is installed and available in your language)
  • Mark as reviewed/unreviewed (including "send a message" feature)
• Special:Log
• NOINDEX feature
• This extension does have language translations/internationalization. There's some way somewhere to toggle that on. So that's one big obstacle already solved. Volunteer translators have been hard at work for years translating. There are 30 language files above 20KB.
• Database schema
• the other 4 API calls

Creating modules to wrap enwiki maintenance tagging and deletion tagging, and then letting those be swappable per wiki, would come in a phase 2, if ever.

Anyway, at risk of stirring up this old hornet's nest phab ticket with 50 subscribers, is there interest in a stripped down version of PageTriage being made available? If so I can't make any guarantees, but I can at least take a look at it and add it to my long term goals. Thanks.

Trying to isolate the enwiki specific features with a config flag sounds reasonable, on the surface, although I would echo what Moriel wrote earlier in this thread:

The code was architected in such a way that these processes are built-in, inherently, into the deep operation of the system. We cannot easily untangle these operations while keeping the extension working. Every step of the process invokes actions that are English-wiki-process specific, and getting those out or allowing to disable them in other wikis (what we call "refactoring") ends up meaning rewriting the majority of the software. Further complexity is added in when we consider that the current technical implementation uses technology that is old and unsupported, which means it is almost impossible to add and edit features, as the code is written right now.

If the end goal is to deploy a PageTriage features more widely, starting from scratch might be a better approach. The extension uses design patterns that don't follow the Design Style Guide; it uses backbone.js which isn't used anywhere else; the feed itself is rendered only client-side, going against best practices for progressive enhancement; the feed doesn't display at all on mobile. There are more issues which have been documented on this thread. Refactoring it is going to be challenging.

Starting from scratch is a pretty big project, though. Documenting existing features/capabilities and gathering input from communities about what patrollers would like to see in a new iteration of this feature might be a good starting point. It would also be interesting to think about what role Special:NewPages should have in a future for this type of feature.

All those years ago 'Page Triage' was proposed by the WMF as a consolation prize for so rudely denying the massive consensus for ACTRIAL, I worked closely with them during its development - but from the aspect of a patroler and not as a software developer. Fast forward to 2022: we now have ACTRIAL/AQREQ, and we have a special user group of (hopefully) experienced New Page Reviewers, and we finally have a much enhanced curation system. But the problems of patrolling persist and despite having over 750 patrollers (of whom half have never made a patrol), today's backlog stands at around 12,000 articles.

The importance of the process of reviewing new pages accurately has since been better understood by both the community and the WMF due to the exposure of Orange Moody and the discovery how deep rooted COI and paid editing actually is among certain editors who willfully exploit our free work for financial reward and abuse our sockpuppet policies. We now also have hundreds more Wikimedia projects and hundreds more staff managing it all.

Back in the day, it was considered that Page Triage should be Wiki agnostic. But here we are now with hundreds of Wikipedias going to need something like it sooner or later, which means this is much bigger than a wishlist item. I locked horns for two years with Danny Horn who steadfastly insisted that such an important process as NPR should nevertheless stand in line with every one else and hold out its Xmas begging bowl.

We all know by now that the control over new content is faced with new and more subtle challenges, not least of all the disinterest in patrolling due to the totally changed profile of the new articles that are now submitted. This leaves the community with too few capable and competent people at NPP. We therefore have to rely increasingly on ORES, filters and other forms of artificial intelligence to get the work done. This will obviously require a bigger and dedicated team of devs for which I have been advocating for a long time.

Maybe its time to look at Page Triage as a sunk cost, keep the pretty and user friendly interfaces and their highly useful functions, but rewrite the entire code from the ground up - more than enough funds are available.

Change 815686 had a related patch set uploaded (by Novem Linguae; author: NovemLinguae):

[mediawiki/extensions/PageTriage@master] [WIP] Make PageTriage wiki-agnostic

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

Is it possible we're over-complicating this? Most of my list above just involves turning off some HTML. Simple and safe. Will need more thorough testing if deployed to a foreign language wiki, but to give a wiki-agnostic version with reduced features really doesn't seem that hard.

See patch above. Knocked out 6 out of 10 items on my list.

I don't think we'd be able to secure the resources for a rewrite from scratch. This extension has had major bug tickets open for years. I think we might have better luck moving the needle on these issues if we are pragmatic and work within the existing codebase.

Change 815686 had a related patch set uploaded (by Samtar; author: NovemLinguae):

[mediawiki/extensions/PageTriage@master] Make PageTriage wiki-agnostic

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

@Novem_Linguae I still see

But it has removed the references from

@SD0001, you did a great job of re-writing Twinkle to be wiki-agnostic. If you have a minute, can you share a bit about your rewrite strategy, and the architecture changes you had to make to isolate/modularize the wiki-specific code? We are interested in doing something similar for PageTriage and are looking for ideas.

@Novem_Linguae Twinkle's rewrite strategy was:

• Rewrite from scratch in an object-oriented paradigm. Classes are hard to use in ES5, so twinkle uses TypeScript instead. (PageTriage should use ES6. IE 11 compat doesn't seem particularly desirable.)
• Provide a twinkle-core library which can used by each wiki to create their own custom Twinkle edition. If the workflows used on the wiki are really really standard, almost no custom code would be needed. The more the workflows are non-standard, the more custom wiki-specific code needs to be implemented.
  • For instance, the article tagging module is provided in core as TagCore. The enwp customisation would create a class Tag extends TagCore which inherits base functionality and adds customisation by overriding relevant methods in the base class.

Can this be replicated in PageTriage?

• Doubtful, since having each wiki provide functions/classes for customisation flies in the face of extension-writing best practises, which suggest to minimise configurability and eliminate configurations expressed as code.
• One approach would be to make (only) the PHP part wiki-agnostic, moving out all wiki-specific logic to the client-side. Then, as with twinkle, abstract out the agnostic parts of JS code in classes, and create subclasses for each wiki. The extension codebase would contain all these subclasses, but you can use ResourceLoader to bundle only tagging-enwiki.js on enwiki, tagging-frwiki.js on frwiki and so on. Of course, there would also be a tagging-generic.js for the "default" tagging experience for wikis which don't have their own subclass.

Just some suggestions, which probably need quite more refinement. Hope this helps.

Maybe a good starting point is finding a few wikis that are interested to use the tool, and document with them about where their usage would diverge from the existing UX. Then you'd have some concrete use cases you could think about how to implement.

On-wiki MediaWiki namespace JSON files could be a nice way to allow for communities to customize options. See also GrowthExperiment's Community configuration feature for some ideas there.

In T50552#8341053, @kostajh wrote:

Maybe a good starting point is finding a few wikis that are interested to use the tool, and document with them about where their usage would diverge from the existing UX. Then you'd have some concrete use cases you could think about how to implement.

Great idea. In fact one idea would be to add support for one wiki at a time. That way the refactor is incremental, and also we aren't coding hypothetical features that we may end up not using. Is anyone subscribed to this thread still interested in using PageTriage on their non-English wiki?

On-wiki MediaWiki namespace JSON files could be a nice way to allow for communities to customize options. See also GrowthExperiment's Community configuration feature for some ideas there.

Also a good idea. Some work has already been done on this. For example, the deletion tags and the maintenance tags are stored in MediaWiki namespace pages:

https://en.wikipedia.org/wiki/MediaWiki:PageTriageExternalDeletionTagsOptions.js

https://en.wikipedia.org/wiki/MediaWiki:PageTriageExternalTagsOptions.js

Change 815686 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Make PageTriage wiki-agnostic

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

In T50552#8347737, @Novem_Linguae wrote:

Is anyone subscribed to this thread still interested in using PageTriage on their non-English wiki?

FWIW the relevant tasks are

• T44322: Install PageTriage on id.wp
• T74899: Install Page Curation on ur.wp
• T68260: Install PageTriage on fr.wp
• T46916: Install PageTriage on et.wp
• T99251: Enable Page Curation on Arwiki
• T109820: Install PageTriage on fa.wp
• T200265: Install PageTriage on ml.wp

although I could imagine more communities being interested if they knew the tool might be available in the future. Also @Ainali and @Samat were at the recent meeting about PageTriage, which I assume implies some kind of interest?

In T50552#8388138, @Tgr wrote:

In T50552#8347737, @Novem_Linguae wrote:

Is anyone subscribed to this thread still interested in using PageTriage on their non-English wiki?

FWIW the relevant tasks are

• T44322: Install PageTriage on id.wp
• T74899: Install Page Curation on ur.wp
• T68260: Install PageTriage on fr.wp
• T46916: Install PageTriage on et.wp
• T99251: Enable Page Curation on Arwiki
• T109820: Install PageTriage on fa.wp
• T200265: Install PageTriage on ml.wp

although I could imagine more communities being interested if they knew the tool might be available in the future. Also @Ainali and @Samat were at the recent meeting about PageTriage, which I assume implies some kind of interest?

Hi, frwiki's task is indeed still open. I have posted a message on patrollers' talkpage, I think the community still wants to test the extension.

"Option to disable "Proposed deletion" (PROD) functionality", can use the code:

delete $.pageTriageDeletionTagsOptions.Main.proposeddeletion;

Personally I will instead suggest building a new wiki agnostic extension to replace PageTriage. See T355150#10308304

P. S. I have look at recent change/AFD/CSD in several wikis, and find many wiki do not have a gadget like Twinkle at all.