There is one big, important theme that everything here revolves around: we do not have any way to represent WikiProjects in software. A WikiProject is currently just an abstract concept. Its current on-wiki representation is a normal page, with no reliable and site-independent way of telling if a given page represents a WikiProject. And even then, there is no (machine-readable) metadata attached to them; most notably, there is no machine-readable information on their topic. For T368329: [EPIC] Collaboration List MVP, we did a very naive implementation that uses WDQS (which, as a reminder, does not make great operational guarantees) to get a list of WikiProjects. This was enough given the use case, but as we discussed back then, further work in this area would most likely require implementing proper abstractions for WikiProjects. I raised basically the same point in T390894: Investigation: How can we add improvements to the Communities tab? roughly 1 year ago, and those still apply to this investigation.

More specifically:

• Priority 1: Given that a user makes a significant edit to an article that is in the scope of a WikiProject, can we recommend the WikiProject in the post-publication dialog?

For this we need to get a list of WikiProjects for a single article. As noted in the task description, there is no reliable way to do this across all sites, and PageAssessments is only available on a handful of wikis. So, there is presently no way to get this information. An indirect approach could be to: get a list of topics for the article (via LiftWing); then get a list of all WikiProjects and their topics (more on this below); then choose the WikiProject with the best match (simple algorithm). I am not sure how good the results would be here: I suppose there is a possibility of us not picking the right WikiProject. That might be fine though.

But most importantly, there is the problem of listing all WikiProjects and their topics. This is the kind of thing for which we'd need to rework the representation of WikiProjects. At the moment, the only way to get this list is via WDQS, which has its own problems as already discussed multiple times (WM production-specific, service not very reliable, expensive queries, ...). However, that only gives us the WikiProjects, not their topics. One option is to get the topics as defined in Wikidata via the property P921 (main subject). However, even assuming that we can trust the data, in the best case scenario it still gives us topics as Wikidata items, so not the same topics used by the LiftWing API. I'm not sure to what degree they are compatible, but I suspect this would be really difficult to maintain. Another option could be to get the topics separately once we have a list of WikiProjects. However, as already noted in the task description, even if we were to do this for a single WikiProject, there is no simple way to achieve it. We can't get a list of articles for a given WikiProject, so we don't know where to look. And even if we did have a list of articles to get topic for, we'd run into the performance issues described in T419745#11778816.

If we did have a way to do all of the above, putting that information in a post-publication dialog would be really simple, but of course that's "draw the rest of the owl" territory.

• Priority 2: Given that a user has watched at least 2 articles within the scope of a WikiProject, can we recommend the WikiProject in the watchlist?

Technically speaking, this is like applying the topic extraction discussed above to not just one article, but many of them. So, it runs into all the problems already discussed above. It might also run into additional performance problems, because the implementation would need to work not just for a list of articles and still be fast. T419745#11778816 is once again relevant.

And of course, the UI part of it is the same as T419745. I think it would require adding a hook to the watchlist implementation, but once again, it's not the difficult part of the owl.

• Priority 3: Given that an event is topically related to a WikiProject, can we recommend an event at the bottom of the event page?

There's too many "event" in this sentence, but given the scope of the task, I assume the actual request would be:

• Priority 3: Given that an event is topically related to a WikiProject, can we recommend the WikiProject at the bottom of the event page?

This one seems technically less complex than the others, because for a given event we know what its topics are. However, we would still need a list of all WikiProjects and their topics, so that part is still in common with the other two priorities. It is not currently doable, and would require a structured representation of WikiProjects that does not presently exist.

Agreed with everything @Daimona is saying here. Hearing this reflected back as well as seeing the progress that you all are making is leading me to shift some of my thinking away from "we should extend PageAssessments" (cc @ifried): one of the downsides for WikiProjects (at least for newer editors who aren't really familiar with them) is that there is no sign-up. Which means it's kinda weird to be dropped in when there's no immediate "action" to be taken and it's more of a "here's a place to ask questions and explore topic-specific documentation". And while there are some ways of tracking active vs. in-active WikiProjects, we don't have a great proxy for which ones are in a good place to "accept" newcomers either. On the other hand, I've been really impressed with the Events infrastructure that you all have built out and if @cmelo's work on worklists moves forward, you've brought Events to a place where they have all the aspects that make WikiProjects attractive in the sense of connecting editors with a broader community of editors interested in their topic:

• Worklist tracking
• Sign-up capabilities
• Discoverability -- this really hit home in the worklist demo where an editor who isn't signed up for an Event is given a "do you want to join this Event?" when they edit an article on its worklist. I think this is a lot more direct than trying to build a bridge between Events and WikiProjects via topics. If the worklists feel too narrow to be effective here, you can always work on recommending new articles to add to a worklist (which is something we've developed a lot of prototypes for).
• Off-ramp from individual editing to collaboration with like-minded editors -- this is what the Collaboration List currently is so I guess the key thing is how to make it easy for WikiProjects to have a corresponding "Event" that has the worklist/sign-up capabilities and therefore much higher discoverability.

Another way of saying this is asking the question of what the relationship is (or should be) between PageAssessments, WikiProject pages, and Events/Collaboration List. Essentially I see them all as necessary and different, so the goal is really how to make it very easy to interconnect them:

• PageAssessments: core functionality is tracking quality assessments. I think this has to stay on-wiki because so much is built on top of it (e.g., all of the Featured Articles processes). Notably it's also used as a worklist tracker too right now for many WikiProjects but I think that functionality is actually better served by Events (not that folks should be forced to choose between the two).
• WikiProject pages (e.g., WP:TRAINS): core functionality is as a hub of information (policies, resources, etc.) and place for discussion. They also host taskforces and a lot of stats but I could see at least some of this functionality nicely supported by Events.
• Events: I listed the core functionalities above (worklist / sign-ups / discoverability). This is probably less interesting for well-established WikiProjects that have aspects of this in place but I suspect Events are significantly easier setup for folks interested in creating new "WikiProjects" and importantly finding new collaborators. Especially valuable for wikis that don't have PageAssessments installed.

To me, the next steps then are not about better modeling WikiProjects but making it easy for them to port their worklist functionality onto the Events / Collaboration List. In that way, some of the existing WikiProject functionality can be mirrored or moved onto your extension and you'll be able to make WikiProject recommendations without hacking around the edges of other systems:

• You probably want to consider how to bulk upload article lists for an Event if you don't have that already. In theory it would be easy then for someone to download their list from PageAssessments (or a PagePile or a list of links on a page or Wikidata as I've also seen) and move onto an Event.
• You will want to consider how to connect RelatedChanges with an Event worklist so WikiProjects who use that functionality can continue to access it.
• You might consider giving organizers the ability to add importance assessments for articles on their worklist, which is currently done via PageAssessments but makes sense as something that is more worklist-specific. There's some variation in how wikis run this, but English at least generally uses a four-category system of: Top, High, Medium, Low (and unrated, which in practice often is Low).
• You might want to eventually talk to the Content Translation folks about how to move the page collection functionality onto Event worklists.

Right, I forgot to mention two related tasks: T385342: [EPIC] Expand Event Registration to Support Project + Program Structure, T368331: Investigation: How do we define WikiProjects within the CampaignEvents extension?. I'm not sure where exactly we'd want to go in the direction of "reworking" WikiProjects, as the details of that were out of scope here, but there's definitely lots to explore in the area!