Alternative proposal, following-up on what I wrote in T420250#11785879, paragraph starting with "it would be great": store worklists as wikipages.

This would automatically give us things such as version control / revision history (including timestamps, diffs, author names) , easy reverts (and more generally patrolling), possibility to watch the list, etc. We can also make it so that the worklist is counted as linking to each listed article, so that the worklist itself will show up in places such as Special:WhatLinksHere, which makes the worklist more findable (in general, but also in specific circumstances such as when a page is deleted).

Internally, the worklist page itself would use a JSON-based content model, same as other metadata stored in wikipages (such as community configuration). Direct edits would be possible, but we would also provide an indirect editing UI in Special:EventDetails that hides the internal JSON implementation. We can implement custom permission checks to restrict who can edit the page, and integrate them in the standard editing permission checks. Additionally, we can have a separate database table that stores the data in a structured format, for better queryability (for instance, in the paginated view), and to merge data from multiple wikis (more on this below). Still, the wikipages would be the canonical source of truth (same as Wikibase does for example). There are some old notes in this regard in T322657; I haven't re-read them but there might be something useful if we decide to move forward with this approach. Note, that task is about MCR but we wouldn't be using MCR here, just the main slot with a custom content model. Because all the data here is public, there should be no issues.

Also note that there are a few details to figure out, such as: can we do synchronous validation upon save? If not, how to deal with invalid articles? Also, articles in the worklist can get deleted anyway, deal with those somehow.

Then there's the problem I mentioned in T420250#11785879: wikipages are local, but the worklist is global. To this regard, we could make it so that each event stores its worklist across multiple pages, each on a different wiki. However, they are internally merged so as to create a single, global worklist. The way this works from a user's perspective (on Special:EventDetails) depends on the next problem discussed below, but it would be mostly transparent (but we would still link to the actual wikipage).

And finally, there's the question of what wikipage the worklist would be stored in. I can see two approaches: 1) use a fixed title, e.g. Event:Foo/Worklist, or 2) let users specify any page they want. Option 1 requires less configuration on the user side, as they can just start adding articles without having to worry about where they'll be saved. However, choosing the right fixed title can be tricky: keep in mind that events are global, and for instance, there's technically no guarantee that the Event: namespace exists on all target wikis of the event. And even if it does, the Event:Foo page will most probably only exist on one wiki, so we couldn't really have subpages of it in other wikis. Also, "worklist" would not be translatable in this context. Option 2 adds an extra step, in that users need to specify what title to save the worklist under. Once they do, the page will be created for them. They can also specify an existing page, provided it uses the right content model and is valid. So for this option, we need to change the design so that the user is first asked to specify a worklist page, when the event doesn't yet have one. Then we would also need a database table to associate events with their worklist pages on all wikis, but this would be simple (although we do need to think about scenarios such as the page being deleted).

April 23 discussion on proposal above:

• We would like some visual example or basic prototype of how it could work to do the wiki page approach
• We want to know if the following could be possible for the wiki page approach:
  • Have a global worklist, so that participants can see articles listed from multiple wikis and links to those pages
  • Not not, but in the future: The ability to have tasks, topics, and quality score changes over time from LiftWing automatically displayed in relation to articles added in the worklist. This may also included Edit Suggestions when made available by the Editing team.
• We are open to organizers being able to name their worklists, and maybe showing how this could be done could be included in the basic demo/prototype too
• Potential inspiration: https://www.mediawiki.org/wiki/Translation_suggestions:_Topic-based_%26_Community-defined_lists/Metrics

Another thought, @cmelo and @Daimona: We may want to build a worklist module in the future that could appear on the new Personal Homepage/Dashboard. The idea would be that people could create their own to-do lists, similar to the Micro-Task Generator, as a way to find interesting stuff to work on and to connect with other editors over similar interests. Perhaps they could also set goals based on these worklist articles. In that case, whatever solution we choose should also allow such flexibility for potentially creating a module on the Personal Dashboard.

In T423318#11852470, @ifried wrote:

Another thought, @cmelo and @Daimona: We may want to build a worklist module in the future that could appear on the new Personal Homepage/Dashboard. The idea would be that people could create their own to-do lists, similar to the Micro-Task Generator, as a way to find interesting stuff to work on and to connect with other editors over similar interests. Perhaps they could also set goals based on these worklist articles. In that case, whatever solution we choose should also allow such flexibility for potentially creating a module on the Personal Dashboard.

I think this would be independent of storage. If anything, the wikipage approach should work nicely with the possibility of specifying a user subpage as personal worklist. Especially because the user's worklist would need to be visible to others anyway.