Thinking about this a bit more, I suppose one consideration here is whether a page can be in multiple categories / have multiple tags, or if it must be placed in one category. I can imagine it being desirable for a page to be in multiple categories, but I imagine this increases the technical complexity, and almost certainly increases the UI complexity.

In T390088#10680015, @Samwalton9-WMF wrote:

Thinking about this a bit more, I suppose one consideration here is whether a page can be in multiple categories / have multiple tags, or if it must be placed in one category. I can imagine it being desirable for a page to be in multiple categories, but I imagine this increases the technical complexity, and almost certainly increases the UI complexity.

I had a quick chat about this on Discord and we came to the quick conclusion that a page being in multiple categories is clearly beneficial, for example "Pages I created" and "Current events" could easily overlap.

I think this lends itself to a kind of tagging model, where users have one Watchlist, and the pages on it can optionally have tags that you filter on individually (this doesn't necessarily need to be an RCFilters filter, it could be tabs or any other design language). This might help with introducing this as a new feature - no ones watchlists need to change by default, but then they can start adding tags to pages they're watching.

Tangential: noting that Special:EditWatchlist has perf issues with large lists.

Change #1137814 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/core@master] [SPIKE] How could we implement Watchlist categorisation, tagging, or multiple Watchlists? [16H]

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

We would like to know if this is technically feasible to achieve within the 3 months the Moderator Tools team plans to work on Watchlist.
Maybe; factors that would determine this: can we get metrics, a design, and then implementation complete for both a form to CRUD (create, read, update, delete) tags alongside the interface to filter by those tags within 3 months? If metrics are included in this it may be a stretch goal to get it done within 3 months. How long does it take to create a new table and make it available for consumption? See the process here: https://wikitech.wikimedia.org/wiki/Creating_new_tables @Ladsgroup this is probably a question you can answer.

Are there any obvious roadblocks or technical issues that we might foresee?

• Our ability to create a new table, something like watchlist_tags which would consist of just a string tag and a FK watchlist id.
• The UX component for selecting created tags; is a prepopulated drop-down sufficient or do we want it to be more like a selectable autocomplete?
• Same kind of question with the form, do we have all the UX components we need to create this form to add tags?
• Performance concerns could crop up as we're introducing a new join to the watchlist query.
• Though we already have performance concerns due to not limiting the amount of pages a user can add or implementing some kind of pagination.
• We would need to design and create an interface for CRUD (create, read, update, delete) operations on the tags.

Are there limitations, or performance concerns?
Limiting the amount of tags created by users. This could easily be a limit we set in the config and then check against when a user attempts to create a new tag that would push them over the limit.
As far as performance is concerned, there's no way to test this additional join in production since the added table would be a newly created one. We would need to put it behind some kind of feature flag.
Are there any current performance concerns we'd be adding to?
Yes, users can currently add too many things to their watchlist causing timeouts. This could exacerbate that. @Ladsgroup I know you cautioned us against adding any new columns to RecentChanges, are there any concerns for adding additional joins to the watchlist query? Or adding a new table titled
watchlist_tags? See spike patch here.

In T390088#10762137, @Kgraessle wrote:

After talking through this in engineering weekly, it seems we're blocked because the join ultimately joins with recent changes. This would mean we cannot complete this within the 3 months the Moderator Tools team plans to work on Watchlist.

Refer to T307328: Scalability issues of recentchanges table for more details about the limitations.