####Background:
We would like potentially create a new architectural structure for Event Registration, so that we can have a Project -> Program/Campaign -> Event, so that various forms of collaborations can use the tool and so that we can include events under a larger banner such as a campaign or WikiProject.
For example, a WikiProject could collect event registration (and in the future, tracking contribution data) on the WikiProject overall, as well as the separate initiatives within the WikiProject (such as collaboration of the month), and then the separate events within the initiative (such as collaboration of February 2025). In this way, the whole structure of the project as well as its underlying initiatives and events can be structured, tracked, and discoverable under the common infrastructure of the CampaignEvents extension and its tooling.
Note that probably want to allow WikiProjects the option to augment their pages with things like an event registration header, but they can also have the option to NOT augment their pages and to just associate an event or program with the larger WikiProject for tracking purposes.
Also, different WikiProjects, campaigns, and programs will want different things. For example, maybe one WikiProject wants to use Event Registration to track all of the participants in the project, while another WikiProject may only want to use Event Registration for specific events. The idea is to provide flexibility so that organizers can choose the configuration and setup that works for them.
The main goal of this work is that, in the future, various types of projects/programs can have a way of tracking participation, contributions, and other data points tracked by the extension. This means that, in the course of the investigation, we're not trying to reimagine every aspect of the creation of WikiProjects. This is particularly true because many WikiProjects already exist -- and we want to be able to allow them to augment and improve their WikiProjects, rather than forcing them to rebuild everything from scratch. However if, in the course of the exploration, some compelling opportunities are also found to improve other elements of the WikiProject structure in a way that is aligned with this work, it can also be shared in the design work.
####Stakeholders:
* People who tend to be especially active in WikiProjects (who we can think of as potential "organizers")
* People who join WikiProjects as members
* People who join campaigns or larger programs/initiatives
* People who join WikiProject events/initiatives
* WMF teams and analysts who want to better understand participation and contributions of collaborative activities, such as WikiProjects, projects, campaigns, and programs
####Resources:
* See T371744 for related design concepts
* See [[ https://docs.google.com/presentation/d/1gvtssLVat8jS5-7-KmLax7v97XxEIFboSa4yUYoYi4I/edit#slide=id.g15fc5a35211_0_415 | slide ]] for research on various types of campaign/event structured
* See [[ https://miro.com/app/board/uXjVIaRxbb8=/ | Miro board ]] for example configurations of WikiProjects, campaigns, etc
**Notes on how this could work: **
* You can have events that are tied to a campaign or project OR an event that is not tied to a campaign or project
* Can be useful for WikiProjects - maybe a bigger project than idea 2, so could be done after idea 2 after we have some wikiproject users
* The organizer can create a community (or group or whatever name we want)
* When enabling event registration, the user can indicate if this event belongs to a community by selecting it from the list of communities/program/campaigns they are allowed to manage.
* Then we can have a CampaignEvents Special:CampaignEventsCommunitiesList:
** This would list all the communities/program/campaigns, and the user could filter them by:
*** communities/program/campaigns topics
*** communities/program/campaigns areas
*** communities/program/campaigns region
* Each communities/program/campaigns could have a "how to join" section:
** It could include the names of the organizers for users to contact to request to join.
* Alternatively, it could have a button to join or request to join.
** If it is a request to join, organizers would be able to see who is requesting and approve or decline the request.
* We could also have a CampaignEvents Special:CampaignEventsCommunityPage: (I named it community but it is the same concept of project)
* This page could be directly accessed via the browser by adding the full URL.
** It would also have a link to it on the list of communities/project' special page mentioned above.
* Organizers and/or admins could create communities.
* Community/project:
** A community/project CAN HAVE topics.
** A community/project CAN HAVE WikiProjects.
** List of WikiProjects for this community/project.
* A community/program CAN HAVE many campaigns.
** Campaigns CAN HAVE MANY events (which may or may not have a date frame).
* Events have a start and end date.
* Alternatively:
** Use WikiProjects as "communities."
** List WikiProjects and allow people to join.
* Apply all the features mentioned above to WikiProjects instead of communities.
* Invite people to WikiProject campaigns/projects.
**Open questions:**
* Do we want to allow people other than the page creators to enable event registration on an event page? For example, there may be a WikiProject page that was created 15 years ago and the original creator is no longer active on the wikis. If they want to use Event Registration, they would be unable to do so in the current system. Maybe we could have a new user right that allows someone to create event registration on any page. Or it could be something that we grant to admins.