Page MenuHomePhabricator

Investigation: Determine options to create a basic prototype of an embeddable Collaboration List [3 days]
Closed, ResolvedPublic

Description

NOTE: We will separately investigate creating a Collaboration List module for the Newcomer Homepage in T386958
User story

Use Case 1 - WikiProjects: As a member of a WikiProject, I want a calendar of relevant events (i.e., events in the topical area of the WikiProject and on the wiki of the WikiProject) to be displayed on the main WikiProject page, so people can learn about events and join them to improve content in the focus area of the WikiProject.

Use Case 2 - On a wiki main page: As an editor of a wiki, I want to be able to discover relevant events and WikiProjects for the wiki on the main page (or other central wiki page that attracts a lot of views), so that people can learn about and join events/WikiProjects on the wiki.

Background:

The Collaboration List is currently viewable via Special:AllEvents on any wiki that has the CampaignEvents extension enabled. This means that is viewable on a maximum of one page per wiki. This page is not easily discoverable or stumbled upon in many wiki workflows. While we can encourage more people to check it out (and we have some done some work in this area - see T377861), we would also like the Collaboration List to be discoverable within common wiki workflows. This is for a few reasons:

  • The Collaboration List is generally useful to many different types of people, since it is focused on finding many different types of collaboration, such as: meetups, campaigns, edit-a-thons, office hours, and WikiProjects.
  • The Collaboration List can be filtered for different types of users and needs
  • We have repeatedly learned through research and discussion that it is hard for many people to find meaningful opportunities to collaborate on the tasks and topics that they care about, and one of the challenges is discoverability

If we were to allow communities to add a) a version of the Collaboration List on any wiki page, and b) if the Collaboration List could be slightly customized to fit their needs (for example, they can have it pre-filtered to show events under a certain topic), this could allow communities to have a new way to encourage collaboration and connection on the wikis.

Acceptance Criteria:
  • Investigate how we could allow anyone (perhaps it is not required that someone has the organizer right?) to embed a Collaboration List on a wiki page
    • The embedded Collaboration List should be a smaller size, so other things can also fit on the page
      • What are the options for determining dimensions?
    • What are the options available for people to tailor/customize the Collaboration List for their community needs?
    • The embedded Collaboration List should be scrollable, so all events/WikiProjects can be viewed
  • Regarding the filters at the top, we do not know what is the best option, so this investigation should also explore the complexity in allowing the section with filters. Some things in particular to explore include:
    • The embedded Collaboration List could be pre-filtered based on what may be of interest to a community
      • For example: A Collaboration List that filters for the topic of "Women (biography)"
    • The embedded Collaboration List should have the option of 2 tabs for events and communities
      • Can we allow people to choose whether they have 1 tab or 2 tabs?
    • The embedded Collaboration List should have a link to the main Collaboration List
      • Example: "Find more events and WikiProjects in the main Collaboration List"
  • Provide a basic explanation of the pros/cons of transclusion vs Lua module
    • Note: Though we are gravitating toward transclusion (since we want a simple implementation), we should still understand the options before making a final decision
  • High priority: We want to be sure to investigate how the Collaboration List could be featured on the Newcomer Homepage.
    • For example, could it be a module (perhaps opted in via Community Configuration?) for wikis that have the CampaignEvents extension enabled?

Event Timeline

ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried renamed this task from Investigation: Determine options to create a basic prototype of an embeddable Collaboration List to Investigation: Determine options to create a basic prototype of an embeddable Collaboration List [3 days].Feb 20 2025, 5:56 PM

Change #1123002 had a related patch set uploaded (by Mhorsey; author: Mhorsey):

[mediawiki/extensions/CampaignEvents@master] Make AllEvents transcludable

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

Memo: we need to make sure we aren't affected by T290706. See comments for details, but TLDR: we must make sure that the special page does not access the global state when included (and this includes OOUI).

Comments on the findings:

  • Agree that tranclusion is the best option (at least for the time being). Also, they're not mutually exclusive so we can look into the Lua version later on if necessary.
  • Re sizing: I think the size itself will be up to the including page, which might for example put the trancluded list inside a limited-width box. And forcing a fixed width is as widespread (from experience with the average on-wiki CSS) as it is wrong. So, I agree that it should be implemented with preset values, if that's something we want. But I still wouldn't call it "size". I'm assuming the implementation would either change the layout, or remove some information; the approach should help us find a better name. But then again, is that something we really need now? It adds complexity. Potentially a lot of complexity, if we're duplicating the interface. So, I'd like to see a concrete use case or request for it.
  • Points on filtering and tabs LGTM.
  • I actually like how the absence of pagination provides a compelling reason to link to the full version of the page.
  • I'm not sure if this will impact the newcomer homepage module at all, as transclusion is for a very specific use case (wikitext), and the logic behind it is somewhat hacky. It might, however, help us to make sure our code is not too tightly coupled with the UI.
  • As noted in T385729#10598703, the code responsible for special page transclusion is especially brittle and tends to fail in surprising ways if a special page accesses the global state. I used the experimental patch in T290706 + manual auditing to quickly see what we need to change, and there are quite a few things. Aside from what the patch already does: no OOUI (and this is going to be a problem), the Pager constructor needs a context object, our UserLinker needs to be migrated from Linker to the new UserLinkRenderer. This would probably be its own refactoring task, and not a small one given OOUI. Might be worth looking into Codex to replace TextWithIconWidget.

Tasks have been written for this epic, so I think this can be moved to product sign-off

We have made decisions on this work, which are: We will implement a solution that allows editors to transclude the Collaboration List on different pages. Customization, such as formatting and styles, will be done through wikitext for the MVP. We will provide documentation on how to do this along with support from the ambassadors & CRS. Now that decisions have been reached, I am marking this investigation as done.