Page MenuHomePhabricator

Make PageTriage wiki agnostic
Open, LowestPublicFeature

Description

Other non enwiki wikis want it


Version: master
Severity: enhancement

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 21 support votes, and was ranked #42 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Moderation_and_admin_tools#Special:NewPagesFeed_in_every_language

Todo list:
Add the following options to MediaWiki:PageTriageExternalDeletionTagsOptions.js:

  1. Option to disable "Proposed deletion" (PROD) functionality
  2. Option to disable "Articles for deletion" (AFD) functionality
  3. Option to disable "Criteria for speedy deletion" (CSD) functionality
  4. Option to disable warning the creator of said page of the deletion (usecase: Wikidata)

Note that if T169441 is fixed, it will likely complicate this further.

Details

Event Timeline

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

@JEumerus

  • A notification on the talk page of the user who made the article

Not always, nominating deletions of Wikidata items do not require such notify.


Also, for several months I'm wondering why Collaboration team is "maintaining" PageTriage related tasks, and are members of that really doing maintains? If there's benefit that this work must be continued, how about moving those tasks to another team?

They do work on some tasks there. I generally have better success getting things worked on by directly talking to a member of the Foundation staff before or shortly after I've placed the task in.

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

@Liuxinyu970226: The term "maintaining" covers a pretty wide spectrum, between "fix every sensible issue" to "only make sure the service in its current state keeps running".

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

We've been waiting SIX years for these 'hacks'. We volunteers are the people that provide the content and keep it clean. I suggest the Foundation IT staff meet their obligations and provide us with the equipment to do it. To assume that we are all computer freaks is insolence and does not help here - some of us are more qualified in our fields than you are in yours.

As a former software developer, I take great umbrage at the phrase "computer freak" to describe folks who develop software.

Volunteers come in all shapes and sizes. A lot of the folks who work on Wikimedia software are volunteers, and I think we should honor them. Part of honoring them is showing patience, and trying to convince them via reason and not insults to increase the priority of any given task.

And no, it's not insolence in any way to suggest to folks that they are welcome to contribute to software development work. If something is *that* important to you, maybe learn how to do it yourself.

Also, I will note human nature, and developers who feel insulted will likely feel less interested in assisting on this, not more.

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

We've been waiting SIX years for these 'hacks'. We volunteers are the people that provide the content and keep it clean. I suggest the Foundation IT staff meet their obligations and provide us with the equipment to do it. To assume that we are all computer freaks is insolence and does not help here - some of us are more qualified in our fields than you are in yours.

Oh please, do not try to explain that you're encouraging to deploy this on zhwiki or any of Chinese-Sites. Although there's discussions about it, this extension could also meet language conversation problems.

@Kudpung it seems like you are talking about something other than making PageTriage available for other wikis; you have more chance of getting developer attention if you comment in the task you want fixed. Also (as you no doubt know since you have participated last year) the Foundation runs a survey of technical wishes these days, and requests that rank highly tend to get resolved fairly quickly. The surveys are done towards the end of the year so I suspect the next one is coming up soonish; the productive thing to do would be to convince other Wikipedians that your software needs are important for the project and they should support it over whatever else they might want to ask for. Prioritization by voting is not perfect but a lot better than prioritization by who can shout the loudest.

As for this task, I still haven't seen any clear explanation of what needs to be changed to install PageTriage on another wiki, and developers can't really help without that. If no one has a good idea, maybe we could just enable it on one of the beta sites and test?

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here. I am here because Wishlist rankings are being used as an excuse to not address the needs of the en.Wiki.

Furthermore, as I have stated several times, Curation is an essential, critical core process - look at it if you will as being as important as having an editing window. It is a significantly higher priority than the Wishlist for convenience gimmicks and gadgets - which, and I will also mention again, the Wishlist team have clearly expressed that Curation features are not within their remit.

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

@Kudpung

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here. I am here because Wishlist rankings are being used as an excuse to not address the needs of the en.Wiki.

Still, as Nemo bis warned you above, please do not make all Wikipedias as fully following enwiki

Furthermore, as I have stated several times, Curation is an essential, critical core process - look at it if you will as being as important as having an editing window. It is a significantly higher priority than the Wishlist for convenience gimmicks and gadgets - which, and I will also mention again, the Wishlist team have clearly expressed that Curation features are not within their remit.

This is not wanted on zhwiki, so do not say it as "essential, critical", wikis can still alive without that

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

The most big problem is not some playing, is how to handle the entire different patroll environments between different wikis

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here.

That's why everyone else is, though. So please respect that, and if you want some changes in PageTriage that are not related to making it work on other wikis then find or file a different task.

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

I'd say the official channel is to file a task about the changes you need, set a high priority, explain why you think it's a high priority, and make sure the relevant team is added to it (that's probably Collaboration-Team-Triage in your case). If that doesn't work, contact the product owner of the team directly. (If that doesn't work either, then - short of applying for Dictator of the Wikimedia Movement - you are probably out of luck.)

Gergő Tisza, did you actually read what I posted? You are indeed using this task as the very reason for stalling all the other work that needs doing on Curation for en.Wiki that has already been posted for months on other Phab tasks. Your comments are really not helpful, but it's what we had already come to expect at Bugzila, and now at Phab.

Perhaps what is wanted is to allow page curation to supports variations on the workflow I proposed above. That would mean Page Triage, but with the messages/tags/notifications customizable (including no notification). And where a deletion discussion is posted would also be customizable. And how many iterations of these workflows are possible. I don't know if this all is technically feasible.

I don't know if this all is technically feasible.

Well somebody must know. Otherwise it's back to 'pass-the-parcel'. We need some help here. Perhaps the people who developed Curation should know - such as Kaldari, but he claims it is no longer his remit.

Perhaps what is wanted is to allow page curation to supports variations on the workflow I proposed above. That would mean Page Triage, but with the messages/tags/notifications customizable (including no notification). And where a deletion discussion is posted would also be customizable. And how many iterations of these workflows are possible. I don't know if this all is technically feasible.

It is feasible, in my opinion (as a developer who worked on the extension many years ago).

@Kudpung: The bug about adding ORES to Page Curation is T157130.

@Snaevar I'm afraid just modifying a js file won't be helpful in any case (if just do it can rewrite workflows then I will just submit a patch for this task). And even you did this, there could also have many other compatibility blocks such as in StructuredDiscussions, MediaWiki-Language-converter, RTL...

MMiller_WMF added a subscriber: MMiller_WMF.

The Growth team knows that this would be valuable for many wikis, and the work that the team is doing right now to improve the New Pages in T193782 is written to be applicable to wikis beyond English Wikipedia (so hopefully that is a step in the right direction). But unfortunately, the team won't be able to take on the larger project of generalizing PageTriage right now. We will keep an eye on this.

It seems to me that the obvious solution is to make less of the tollbar hardcoded and more of it customisable via on-wiki .js pages. The 'tags' section currently works this way, and if the deletion section was changed to work via on-wiki .js pages, then it too would be customisable for each wiki however they need it to work for their deletion processes. Future work on the toolbar and New Pages feed should also focus on being Wiki-Agnostic as well, or at least keeping as much as possible on-wiki in .js pages that can be customised for each wiki as they see fit.

I seem to recall that at the very beginning, 'Page Triage' was developed with the intention of it being 'agnostic' - that being the reason why it was built as a MediaWiki extension. @kaldari will know more. Whether or not other WMF projects use it, as they grow they will be needing something like it. In any case, with a bit of luck, all the requirements will be addressed following a successful poll at the Community Wish List. It could even be a reason to put a dedicated team on it.

This ticket has been identified as a priority item for Page curation and New Page Feed improvements currently being discussed on the community wishlist survey. Other wiki's particularly zh and de seem interested.

See: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Admins_and_patrollers/Page_Curation_and_New_Pages_Feed_improvements

@Insertcleverphrasehere

Other wiki's particularly zh and de seem interested.

[Citation needed]

@Insertcleverphrasehere

See comments and discussion page at: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Admins_and_patrollers/Page_Curation_and_New_Pages_Feed_improvements

I've searched on zhwiki and I couldn't find anything that "second" your this comment, am I missed some zhwiki histories here?

See Cohaf's comments on the discussion page (talk page).

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

@Aklapper Fair enough.
My understanding is that the deletion sections are hardcoded, while the tags section can be modified by changing on-wiki .js pages. (if this understanding is incorrect please let me know).

That comment summarised the changes discussed in the Wishlist and at NPR discussion pages during the wishlist voting. The proposed changes in the Summary as currently do not quite meet what is desired; just disabling isn't exactly what is needed, but rather making those sections editable on-wiki

Just having the option to 'disable functionality' of PROD, AfD, and CSD might not fully make the tools wiki agnostic but were, I think, suggested as a quick fix that would be "good enough". I just want to be sure that what is worked on here really serves the purpose of making the tools agnostic and fully useful for purpose on those other wikis that want it.

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

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.

Aklapper changed the task status from Stalled to Open.Nov 1 2020, 3:06 PM
Aklapper triaged this task as Lowest priority.

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled for years for unclear reasons.

According to the last three comments, nobody plans to work on this. Hence setting priority to "lowest" to reflect reality. If anyone volunteers to further investigate and work on this, then feel free to set yourself as assignee. If nobody should ever spend any time on this, then this task should have the "Declined" status, to reflect reality.

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.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM
Aklapper removed a subscriber: Fabrice_Florin.

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 MediaWiki-extensions-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.

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

image.png (168×716 px, 15 KB)

But it has removed the references from

image.png (483×428 px, 29 KB)