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

Hi! Any status of this epic? Can it enable in other wikis? :)

PageTriage was removed from the "limits to configuration changes" page (diff), so that is a significant roadblock removed.

A new roadblock though is WMF is concerned about the NOINDEX feature and how that will affect search engine optimization. So we may not be able to turn that on for other wikis (we will leave it on for enwiki since it is the status quo).

Someone with technical skills, planning skills, and who knows the right people to talk to about the various things that will come up could probably get this ticket across the finish line and get a basic version of PageTriage deployed to an additional wiki. I don't think I have the bandwidth to do this, but would be happy to give advice.

The rough process would be...

• get a fresh consensus (I see some open tickets for specific wikis that requested it, but they are probably years old)
• figure out how you want it configured and test it on a localhost wiki
• you'll probably have some requests for changes based on your localhost testing. you may need a config variable added, or some small code changes to hide certain features, or to hide or translate some things that are in English. those tickets will need to be filed, and patches written and merged. the code may need to be refactored to support deletionTags.json and maintenanceTags.json in other languages, and translations made.
• the NOINDEX feature will need to be turned off. if there isn't a config variable for this, one will need to be created
• double check with Sam Walton, the product manager for the WMF Moderator Tools team, for WMF approval
• work with DBAs to get the pagetriage SQL tables created on that wiki
• work with deployers/SREs to get the pagetriage extension turned on on that wiki
• work with deployers/SREs to get the various cron jobs set up in puppet for that wiki

In T50552#10790620, @Novem_Linguae wrote:

PageTriage was removed from the "limits to configuration changes" page (diff), so that is a significant roadblock removed.

A new roadblock though is WMF is concerned about the NOINDEX feature and how that will affect search engine optimization. So we may not be able to turn that on for other wikis (we will leave it on for enwiki since it is the status quo).

Someone with technical skills, planning skills, and who knows the right people to talk to about the various things that will come up could probably get this ticket across the finish line and get a basic version of PageTriage deployed to an additional wiki. I don't think I have the bandwidth to do this, but would be happy to give advice.

The rough process would be...

• get a fresh consensus (I see some open tickets for specific wikis that requested it, but they are probably years old)
• figure out how you want it configured and test it on a localhost wiki
• you'll probably have some requests for changes based on your localhost testing. you may need a config variable added, or some small code changes to hide certain features, or to hide or translate some things that are in English. those tickets will need to be filed, and patches written and merged. the code may need to be refactored to support deletionTags.json and maintenanceTags.json in other languages, and translations made.
• the NOINDEX feature will need to be turned off. if there isn't a config variable for this, one will need to be created
• double check with Sam Walton, the product manager for the WMF Moderator Tools team, for WMF approval
• work with DBAs to get the pagetriage SQL tables created on that wiki
• work with deployers/SREs to get the pagetriage extension turned on on that wiki
• work with deployers/SREs to get the various cron jobs set up in puppet for that wiki

Got it, thanks! I'll try to sketch out a general work plan.

Something to note:

In T355150#10310942, @Bugreporter wrote:

Another example is several wikis have AFD in subpage of the talk page of the page concerned (i.e. Talk:PAGENAME/AFD instead of Wikipedia:AFD/PAGENAME or Wikipedia:AFD/date). So we should allow local wikis to configure AFD workflow like this without having a specific workflow built in software or specifically adapting software for such kinds of workflow.

As I just mentioned in another ticket, if we do this, I think we should do one wiki at a time. Iniquity, since you seem to have some energy to work on this, what is your home wiki? Would that be a good first wiki? Have they shown some interest?

In T50552#10791420, @Novem_Linguae wrote:

As I just mentioned in another ticket, if we do this, I think we should do one wiki at a time. Iniquity, since you seem to have some energy to work on this, what is your home wiki? Would that be a good first wiki? Have they shown some interest?

Yes, I also think that we should work initially with one wiki. My home is Russian Wikipedia, I will be able to get a new consensus about deploy the extencion.

I would like to suggest that you not take "noindex" off the table when establshing consensus at ruwiki. If the WMF wants to remove that option for new projects, that's fine. But it would be helpful for them to explain officially why that is, rather than us limiting ourselves on a conversation Novem had (which might have nuance to it when presented with an actual community request).

Sorry in advance for all the email notifications (61 subscribers x re-parenting 10 tasks). I'm going to put this back as having the wikis that want this as parent tasks, as I think this is more standard on Phab. Wikis that want it -> epic (this task) -> actionable steps to achieve the epic.

Looks like we're going to get a fresh consensus to install on ruwiki, then work towards installing a minimal version of PageTriage there, then file some tickets for features they want once it's up and running. @Iniquity appears to have some energy and can help with this process.

I've got a more detailed ruwiki deploy todo list going in the ticket T393369: Enable PageTriage on ruwiki if anyone wants to follow along.