Fix code smells related to MediaWiki:PageTriageExternalTagsOptions.js
Open, Needs TriagePublic

Description

PageTriage has a list of enwiki maintenance tag templates and deletion templates both in the PageTriage codebase, and in a MediaWiki file onwiki. I have some concerns about this design.

  • Duplicate code. Having to remember to change the tags list in two spots makes updates laborious, and these two places are prone to getting out of sync.
  • The onwiki code does not get linted.
  • Neither of these files is pure JSON. Currently there is JavaScript peppered in.
  • One of these can overwrite pieces of the other without a warning.

I propose we do the following refactoring:

Patch 1

  • copy paste the onwiki code into the repo, at the bottom of the appropriate file (confirmed that the load order is the repo file, then the wikitext) (gerrit:945002)
  • wait for enwiki deploy
  • blank the onwiki pages, to discourage future use

This gets all the code into one place which is a technical debt win. Easier development environment testing, easier to reason about it.

Patch 2

  • refactor the files that received copy pastes, to eliminate code duplication

Patch 3

Patch 4

Patch 5

Patch 6

Unorganized

  • decide if we want to stop translating all this very enwiki-specific stuff in the tags and deletion flyouts. For example, "pagetriage-del-tags-dbg10-desc": "Pages that disparage, threaten, intimidate or harass their subject or some other entity, and serve no other purpose. (G10)", This would involve substituting all the existing messages into the defaultTags.js files (gerrit:993244, T323882: Delete i18n pagetriage-tags- messages)
  • get mw.msg to load in the Jest tests, so that snapshot tests are more accurate (right now they just pass along the msg name rather than loading the message) - can be done by modifying jest.setup.js, but may not want to. substituting the messages would also substitute the month names, which would make the snapshot break periodically
  • we currently set 5 variables across 2 files. probably makes more sense to have 5 files or 1 file, rather than 2 files. decide which approach to do, then execute
  • rename the config file to include something like "enwiki" or "englishWikipedia" in it. So if PageTriage is installed on other wikis, they can create their own file and give it a corresponding name.

Event Timeline

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

Change 938891 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/extensions/PageTriage@master] WIP: Merge PageTriageExternalTagsOptions into defaultTagsOptions

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

In https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/914720/comments/5cedd124_ffc7e07c, on August 2, 2023, @jsn.sherman wrote:

I recommend abandoning our current approach to loading optional tags and move tag options into configuration. The reason the current approach is hard to test is that it depends on global mutation, which is bad. I started investigating which tags should be default and which should be optional here:
https://gerrit.wikimedia.org/r/938891
But I need a little help sorting out which tags are currently not default because they shouldn't be, and which aren't default because of drift. One example of that is the all property. Someone added it in the optional tags file on wiki, but the module code depends on it, so clearly it should be in the default configuration.

Ok, taking a fresh look at this, maybe we should do the following to kick things off:

Patch 1

  • copy paste the onwiki code into the repo, at the bottom of the appropriate file (confirmed that the load order is the repo file, then the wikitext)
  • wait for enwiki deploy
  • blank the onwiki pages, to discourage future use

This gets all the code into one place which is a technical debt win. Easier development environment testing, easier to reason about it.

Patch 2

  • refactor the files that received copy pastes, to eliminate code duplication

Patch 3

  • change the code so that if there is a non-blank wiki page, it OVERRIDES the defaults rather than adding to the defaults

This keeps the feature intact in case we want to support wiki agnostic. And also solves the problem of the two code spots (repo and on-wiki) diverging in the future if both are in use.

Patch 4

  • rename everything both in repo and onwiki, to MaintenanceTags.js and DeletionTags.js

The old names are not concise or consistent. This fixes that.

Patch 5

  • convert to JSON

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

[mediawiki/extensions/PageTriage@master] [WIP] Migrate onwiki config variables into the repo

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

The downside this approach is that the overrides are still depending upon mutating state by loading it from on-wiki javascript. When I talk about moving to configuration, I mean a combination default values in the PageTriage repo via js/json and additional config in configuration files (which offer the same configuration as LocalSettings.php). Changing those values isn't as quick as editing a page on wiki, but it is faster than train deployments since config changes are done via the backport process. This kind of per-wiki customization is exactly what the configuration files are meant to hold, and I think it would be a good fit given that these tags have been updated no more than a few times per month followed by long spells of inactivity.

https://en.wikipedia.org/w/index.php?title=MediaWiki:PageTriageExternalTagsOptions.js&action=history
https://en.wikipedia.org/w/index.php?title=MediaWiki:PageTriageExternalDeletionTagsOptions.js&action=history

what about:
patch 1

  • as you suggest

patch 2

  • as you suggest

patch 3

  • change the code so that configuration may add new tag groups or replace existing tag groups (eg. all, common, metadata, etc). default tag groups could be redefined per-wiki by setting values or groups could be removed per-wiki by setting config keys for them to be empty/null/undefined/falsey/etc using the same load order concept that you've mentioned.

patch 4

  • as you suggest, though I'd suggest breaking the tag groups up into separate files to make it easier to grok. MaintenanceTags.js and DeletionTags.js could be modules that export the tag groups from either the files or from config

patch 5

  • convert individual tag group files to json

Maybe steps 3 and 4 that I've suggested could be swapped to make the customization step easier to implement.

The downside to using configuration is that the overrides would be in php while the defaults would be in js/json.

additional config in configuration files

This has some downsides too. The big ones, in my opinion, are

  1. Too much data. All these config options are about 2300 lines. We definitely shouldn't be putting that in a file like LocalSettings.php, InitializeSettings.php, or CommonSettings.php, the latter two of which are already too big to comfortably load in a browser. But let's say we do something like $wgPageTriageTags = json_decode('./pageTriageTags.json'); Is that a normal thing to do? I don't recall seeing that in InitializeSettings.php, etc. Would be a bit non-standard.
  1. Difficult and slow to make changes. MediaWiki +2 doesn't work on the operations repo. It's its own set of folks that do code review. Would slow down the ability to change these config settings. Which might need to get changed a lot if a non-English wiki installs PageTriage and starts adding tags and playing around with the extension.

change the code so that configuration may add new tag groups or replace existing tag groups (eg. all, common, metadata, etc)

I suggest we have it replace all or nothing. Letting it replace some things and not others adds complexity and leads to the kinds of problems we're having now, such as a dev environment loading only half the config and not indicating this to the developer.

patch 1
as you suggest
patch 2
as you suggest

I'm glad we agree on the early steps. We can at least knock that out :)

additional config in configuration files

This has some downsides too. The big ones, in my opinion, are

  1. Too much data. All these config options are about 2300 lines. We definitely shouldn't be putting that in a file like LocalSettings.php, InitializeSettings.php, or CommonSettings.php, the latter two of which are already too big to comfortably load in a browser. But let's say we do something like $wgPageTriageTags = json_decode('./pageTriageTags.json'); Is that a normal thing to do? I don't recall seeing that in InitializeSettings.php, etc. Would be a bit non-standard.

That seems like a dealbreaker level of poor fit.

I have another idea for getting rid of the mutation, which I think is a big problem: what if we just changed the way those values get customized from the pages. Instead of mutating global bits, I think we could have the exact same functionality with a js hook implemented on those same pages. We could then avoid global mutation and even add a basic validator to avoid breakage from simple mistakes.

  1. Difficult and slow to make changes. MediaWiki +2 doesn't work on the operations repo. It's its own set of folks that do code review. Would slow down the ability to change these config settings.

Acknowledged. I would love to find a way to get version control, ci and review on these since they are production changes. But it looks like the config backport process isn't the right way to get there.

Which might need to get changed a lot if a non-English wiki installs PageTriage and starts adding tags and playing around with the extension.

True, but I'm don't think we need to optimize for other projects adopting the extension without a single person installing it and testing customization locally before the initial roll-out. That's the bar for most other extensions.

I suggest we have it replace all or nothing. Letting it replace some things and not others adds complexity and leads to the kinds of problems we're having now, such as a dev environment loading only half the config and not indicating this to the developer.

I'm sold. I'd still suggest splitting up the groups into separate files for readability, and just make all the values it provides replaceable on an all or nothing basis.

patch 1
as you suggest
patch 2
as you suggest

I'm glad we agree on the early steps. We can at least knock that out :)

Agreed!

I was just looking back over my investigation patch:
https://gerrit.wikimedia.org/r/938891
and it moves and consolidates the tags options in one go. I hate to throw away that work, but I also want to have this thing move forward with clarity. Should we try to combine the two patches? If that sounds like chaos, I'll simply abandon it.

@jsn.sherman Ah. Your patch is marked as WIP so I lost track of it.

Your patch only updates 1 file out of 2, mine updates 2 out of 2 files. Because of that, maybe it'd make sense to merge mine first, and then rebase and merge yours? That would ensure that both files get updated, and then the one file you worked on will be in really good shape.

@jsn.sherman Ah. Your patch is marked as WIP so I lost track of it.

I wanted to have a discussion of that patch before possible merge, but marking it as in progress was not the right way to handle it. Next time, I'll keep it as active, but put DNM/Discuss/Feedback requested or something similar in the subject line.

Your patch only updates 1 file out of 2, mine updates 2 out of 2 files. Because of that, maybe it'd make sense to merge mine first, and then rebase and merge yours? That would ensure that both files get updated, and then the one file you worked on will be in really good shape.

Makes sense!

Change 945002 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Migrate onwiki config variables into the repo

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

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

[mediawiki/extensions/PageTriage@master] add snapshot tests for defaultTagsOptions

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

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

[mediawiki/extensions/PageTriage@master] refactor defaultTagsOptions.js

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

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

[mediawiki/extensions/PageTriage@master] refactor defaultDeletionTagsOptions.js

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

Change 987882 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] add snapshot tests for defaultTagsOptions

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

Change 987883 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] refactor defaultTagsOptions.js

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

Change 987887 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] refactor defaultDeletionTagsOptions.js

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

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

[mediawiki/extensions/PageTriage@master] Improve defaultDeletionTags documentation

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

Change 988082 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Improve defaultDeletionTags documentation

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

Change rMW10069027fba3 had a related patch set uploaded (by MPGuy2824; author: MPGuy2824):

[mediawiki/extensions/PageTriage@master] Toolbar: Rewrite the way common tags are generated in the tagging module

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

Change 938891 abandoned by Jsn.sherman:

[mediawiki/extensions/PageTriage@master] WIP: Merge PageTriageExternalTagsOptions into defaultTagsOptions

Reason:

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

Samwalton9-WMF subscribed.

@Novem_Linguae I've split out the specific tasks here into subtasks to aid in organisation and better facilitate code review. Please double check the task title/descriptions are accurate!

Change #1006902 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Toolbar: Rewrite the way common tags are generated in the tagging module

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

Change #1037786 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/PageTriage@master] tests: delete snapshot tests

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

Change #1037786 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] tests: delete snapshot tests

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

Change #1037933 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/PageTriage@master] rename module defaultTagsOptions to tagData

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

Change #1037935 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/PageTriage@master] rename deletion.json and tags.json

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

Change #1037933 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] rename module defaultTagsOptions to tagData

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

Change #1037935 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] rename deletion.json and tags.json

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