Campaigns/Foundation Product Team/Central vs local database

The Campaigns team is currently exploring whether it is better to implement a central or local event database. Below, we will explore options by listing the pros/cons of each approach. For more technical context, see T318381. Note that we don't have to go all central or all local; it might make perfect sense to have some central tables and some local ones. The key requirement, however, is that the central tables should NOT store user IDs, and possibly page titles as well.

Pros of central database

• Centralized MyEvents page for organizers and (in the future) participants: This way, people can find all of their event or campaign activity in one place, rather than having to go to potentially many different wikis. They could apply filters to drill down to an individual wiki or project.
• In V2 for event registration, we want to allow the option for organizers to ask more information on participants (such as their gender, location, etc). This information is not wiki-specific but a global or general thing related to users in most cases. If we don't want to require that participants fill out this information separately for each wiki in which they attend an event, would this be helped with a central database?
• Support for creating a central events calendar feature (in the future): While we probably don't have a need to show *all* events at once in a calendar, there are many use cases for people wanting to see events for multiple wikis and/or projects in one calendar (ideally, based on filters they apply).
• Support for creating a central impact/contributions reporting platform (in the future): This is more rough and ambitious, but we may want a way to show the overall impact of campaign contributions as a movement. For example, there were X number of edits on Y topics in a given period. This may or may not be desirable, but it is something to consider for the future.

Cons of central database

• More data that needs to be saved: wiki where the event page is located, full title of the event page (with localized namespace).
• Organizers can only enable and edit registration on the same wiki where the event page is (can't use interwikis).
• Features that require a local user account to exist (like emailing participants or leaving messages on their talk pages) are harder to implement.
  • Linking to user pages is also harder because the account may not exist locally, in which case there would be a red link.
• Filtering the list of participants by name is inefficient because there's no way to map a central ID to a local ID without leaving the DB.
• More config options for sysadmins, as well as potential bugs if the DB is configured to be central but CentralAuth is not installed.
• Handling of deleted/suppressed users is a bit more complicated due to CentralAuth (and the fact that in theory, it allows you to delete a global account, like a real hard deletion that MW core does not support).

Updates

2022-11-10

• DECISION: Go ahead with option 1: leave it as it is (meaning we use a global DB), which means we will need to:
  • Always redirect the users to the wiki where the event registration was created, for any action the organizer can perform:
    • Special:EventDetails
      • Send message to participants
      • Remove participants
      • Search participants
      • Special:EditEventRegistration
  • Since on Special::MyEvents we need to list all the events of the user, we still need to save the Global user ID
  • In parallel, we will get more information from DBAs to prove our decision & logic around it is sound
• Followup task created: T322852