Page MenuHomePhabricator

Investigation: Worklist support for collaborative contributions & event discovery
Closed, ResolvedPublic

Description

NOTE: This should be done after T419603.

User stories:

For the improvement of collaborative contributions:

As an event participant, I want the event to have a predetermined worklist, so that I can see what I should work on and so that I don't need to unnecessarily mark each edit as part of an event if it is already in the worklist.

For potential personal goals or editor matchmaking:

As an editor who wants to set personal or group goals, I want to create a structured worklist with attached goals that is easily searchable and sharable, so that people can easily connect with me and/or work on the goals that I have set as a community initiative.

For event discovery:

As an editor, I want to be able to discover events that specifically focus on the articles I care about (or at least very similar articles), so that I can join events that focus on my specific interests and connect with like-minded contributors.

Background:

We have consistently heard that a) many editors struggle to learn about ways to collaborate and connect with each other (such as events, WikiProjects, etc), and b) many organizers and active members of events and/or WikiProjects suffer from burnout for various reasons, but one reason includes low exposure and difficulty reaching out to new audiences. For this reason, we're interested in surfacing new ways that editors can learn about events to join. One concept is surfacing events (and perhaps WikiProjects) based on the article you have just edited.

The basic idea behind this is that, if someone just made a significant contribution to an article, there is a good chance that they are interested in the improvement of the article and would like to know who else plans to work on it. They may be especially motivated if they know there are certain goals associated with the event. So, we can perhaps surface such events to the editor.

In a later version, we could also perhaps surface events to editors based on not only if an article is directly in the worklist, but also perhaps if similar articles to the one they edited are in the worklist (using the list-building tool, perhaps).

Acceptance Criteria:

  • Develop a basic prototype for the following scenarios:
    • Organizers can specify the articles that are in the scope of an event on Special:EnableEventRegistration or Special:EditRegistration, which would involve:
      • A new section at the bottom below Questions for Participants, which allows organizers to add:
        • Wiki of article (there can be a wiki selector, like we have in the collaboration list, perhaps)
        • Name of article
    • It should not be mandatory to have Collaborative Contributions enabled to add a worklist
      • However, the articles in the worklist could perhaps appear in a new view in the Contributions tab called Articles

Visual examples:

Note that these design examples are based on similar topical area, but we'll be taking the investigation one step forward and focusing on specific articles in a worklist. This is because we believe the current topics may be too broad to be useful in generating a message in such a potentially disruptive way.

Frame 3 (2).png (2ร—1 px, 386 KB)

Frame 8.png (2ร—1 px, 747 KB)

Frame 427318475.png (2ร—1 px, 367 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptMar 16 2026, 5:40 PM

Change #1265413 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add ce_event_articles table for event worklist

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

Change #1265414 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add table ce_event_articles

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

Change #1265415 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] ce_event_articles

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

Change #1265413 abandoned by Cmelo:

[mediawiki/extensions/CampaignEvents@master] Add ce_event_articles table for event worklist

Reason:

Wrong commit order dua multiples commit messaes

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

Change #1265414 abandoned by Cmelo:

[mediawiki/extensions/CampaignEvents@master] Add table ce_event_articles

Reason:

Wrong commit messages doing more then one commit messages added, redoing it

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

Change #1265415 abandoned by Cmelo:

[mediawiki/extensions/CampaignEvents@master] ce_event_articles

Reason:

Wrong commit messages doing more then one commit messages added, redoing it

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

Change #1265432 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] POC for T420250 Add ce_event_articles table

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

Change #1265489 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Event articles worklist persistence (entry, objectives, store)

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

Change #1265528 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Articles worklist validator and CSV parser services

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

Change #1265529 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Event discovery for worklist articles (post-edit modal)

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

Change #1265530 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] T420250-5: Add Articles tab (read-only worklist table) to SpecialEventDetails

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

Change #1265544 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] T420250-6: Add organizer article management (add form + remove) to Articles tab

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

Change #1265545 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] T420250: Add CSV import for event article worklist

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

Change #1265546 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] T420250: Add CSV example download for event article worklist

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

Change #1265549 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add missing use statements for objectives parsing in SpecialEventDetails

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

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://720f6b468c.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://720f6b468c.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://738542efb3.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://416b8df991.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://416b8df991.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://e0ac582ec5.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://e0ac582ec5.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://738542efb3.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://f824ff4559.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://5e432e9492.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://f824ff4559.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://ddf7a91c47.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://ddf7a91c47.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://5e432e9492.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://9e605f4c74.catalyst.wmcloud.org/w/

In this investigation I created PoC that can be tested here, I focused on validating the basic flow for defining and using an eventโ€™s article worklist.
Instead of implementing the worklist setup only through Special:EnableEventRegistration / Special:EditRegistration (as in the AC), I decided to place the article scope editing directly in the Special:EventDetails under Event details. This way, it becomes easier for organizers to add/update the articles, and it also sets up a clearer place for future participant-facing features on the event itselfโ€”for example, enabling participants to suggest articles (as demonstrated in this PoC).

The feature in this PoC are:
Organizer can add/update the list of articles that define the event scope from the event page (under Event details โ†’ Articles).
Participants can see the eventโ€™s current article list in the same Articles section.
Participants can suggest new articles to the event worklist (a flow implemented in this PoC to explore participant collaboration on the eventโ€™s article scope).

How it works (article URL validation)

Overall flow

  • The user submits a full article URL using http or https only.
  • The validator parses the URL and tries to associate it with a wiki via SiteLookup: it walks registered MediaWikiSite entries and compares the URL prefix to each siteโ€™s link path (same general approach as invitation worklists). If the URL starts with that wikiโ€™s article base URL, the page title is taken from the remainder of the URL.
  • If the resolved wiki is the same wiki as the one handling the request, the title is validated locally: it must be in the main namespace (NS_MAIN), and the page must exist in the local database (via PageStore).
  • If the resolved wiki is another registered wiki, the validator calls that wikiโ€™s api.php (action=query with titles=โ€ฆ, redirects=1) to confirm the page exists and to obtain pageid / canonical title; the resolved title must still be main namespace.

Same-host fallback (local / Patch demo / slim installs)

  • Patch demo and other minimal setups often have a sparse SiteLookup, so many โ€œreal worldโ€ cross-wiki URLs may not match any configured link path.
  • If the URLโ€™s host matches the current request host (e.g. the wiki you are actually using), the PoC uses a fallback: treat the URL as belonging to the current wiki, extract the title from /wiki/Title or index.php?title=Title, then apply the same local checks (main namespace + page exists).
  • If the URL host does not match any SiteLookup entry and does not match the current host, validation fails with an error that explains the mismatch (and may list known wiki IDs / an example URL for the current wiki).

Local development

  • Easiest path: configure SiteLookup so your dev wiki has a correct link path, and paste URLs that match that base.
  • If SiteLookup does not list the current wiki but you paste URLs for your dev hostname, the same-host fallback above still allows validating local articles, as long as the URL shape is /wiki/... or index.php?title=....

Patch demo

  • Expect fewer wikis in SiteLookup than in production; cross-wiki URLs only work if those wikis are registered and the server can reach their API.
  • Same-wiki URLs remain usable when the pasted URLโ€™s host matches the demo instance, thanks to the fallback.

Production (when deployed)

  • On a full farm (e.g. Wikimedia), SiteLookup is populated with the wikis users are expected to link to, so URLs like https://en.wikipedia.org/wiki/... match the right site and are validated through that wikiโ€™s API.
  • Articles on the local wiki running CampaignEvents are validated against the local page table, with the same rules: main namespace and existing page.

Why main namespace only

  • The worklist is scoped to โ€œarticlesโ€ in the usual wiki sense (main / article namespace), not arbitrary pages (User, File, Talk, etc.). Supporting other namespaces would be a deliberate product change and would require relaxing the validator and updating messaging accordingly.

In this investigation I created PoC that can be tested here, I focused on validating the basic flow for defining and using an eventโ€™s article worklist.

Thank you!

Instead of implementing the worklist setup only through Special:EnableEventRegistration / Special:EditRegistration (as in the AC), I decided to place the article scope editing directly in the event page under Event details.

Special:EventDetails, not the event page, but I agree that this is a good idea!

Participants can suggest new articles to the event worklist (a flow implemented in this PoC to explore participant collaboration on the eventโ€™s article scope).

One thing I will say immediately: it would be great if the worklist could be stored on a WikiPage (as JSON, for example), subject to the normal viewability and editability of all wikipages. This would also be similar to existing worklists. We would then offer a user-friendly editing interface on top of that, which could also be in Special:EventDetails. We might need a secondary structured storage on top of that (for queriability etc), but that should be OK. I think WikibaseMediaInfo is an example of this already (but I may be wrong, it's been a while since I last considered something similar). The main problem however is that this would make the worklist local to a given wiki, while we obviously want it to be global, and I'm not sure how easy that'd be, unfortunately... Minimum because events might need articles from multiple wikis in the same worklist, so it's not even just a matter of allowing foreign reads/writes.

  • The user submits a full article URL using http or https only.

Hm, that's not very common... The usual MW way of entering titles is via the title itself. Foreign pages could be supported by allowing interwiki prefixes, although that runs into the same problems we previously discussed in T307108 and related tasks. For the common case of local articles, no prefix is needed and we can have autocompletion etc.

  • The validator parses the URL and tries to associate it with a wiki via SiteLookup: it walks registered MediaWikiSite entries and compares the URL prefix to each siteโ€™s link path (same general approach as invitation worklists). If the URL starts with that wikiโ€™s article base URL, the page title is taken from the remainder of the URL.

Invitation list worklists do not use SiteLookup. The maintenance script entry point uses a custom format with wikiID:title, and the UI only allows local titles. And that's precisely because it's difficult to get foreign titles. Maybe we should seriously look into those, since we keep hitting the same issue over and over again. T113034 is related and about the general issues. I don't know if using SiteLookup here is okay or if it will have issues, but FWIW, I think we could switch to accepting interwiki with the same workaround (MediaWikiSite stores both the article path and the interwiki prefix, so we could compare the latter directly, and avoid custom parsing via TitleParser).

  • If the resolved wiki is another registered wiki, the validator calls that wikiโ€™s api.php (action=query with titles=โ€ฆ, redirects=1) to confirm the page exists and to obtain pageid / canonical title;

Some performance-related things to watch out for here, when importing multiple pages at once (e.g. initial creation), but might be possible to address via the jobqueue.

Same-host fallback (local / Patch demo / slim installs)

I think these and the next three sections would become non-issues if we accept titles instead (without interwiki prefix for the local wiki). Then no special-casing would be needed. You would still need to configure interwiki support locally (and don't know about patch demo), but only if you want to enter foreign pages.

Why main namespace only

  • The worklist is scoped to โ€œarticlesโ€ in the usual wiki sense (main / article namespace), not arbitrary pages (User, File, Talk, etc.).

I believe "Usual wiki sense" is not so "usual". It might kinda work for Wikipedia projects, although even then, an event might focus on non-articles: templates, files, categories, drafts... And then, on other projects, there's important content in other namespaces as well; a typical example being Wikisource's Page, Author, etc namespaces. Or Wikidata's Property, etc.

We might need to limit this to the mainspace nonetheless if there are technical issues (which is why I think we did that for invitation list worklists), but not for non-technical issues IMO.

Thanks for the feedback @Daimona, really appreciate !!!