Jump to content

User:IBrazal (WMF)/sandbox/Registration

From Meta, a Wikimedia project coordination wiki
This page contains changes which are not marked for translation.


Community Content Campaigns
Event Registration

Project vision

[edit]

With this new feature, campaign organizers will save time, since they will no longer need to develop alternative registration solutions. Also, they will be able to collect better data on campaign participants and their needs while respecting participant privacy. Meanwhile, campaign participants will be able to join campaigns with minimal effort, and their first point of contact in the campaign will be fun and inspiring.

We have big plans for the future of registration. First, we hope to integrate the registration feature with existing tracking tools, like Programs & Events Dashboard and Event Metrics. This means that, after participants have registered, their usernames will be automatically pushed to the tracking tool specified by the organizer.

Second, we hope that an on-wiki registration solution fosters a greater sense of community. Right now, many campaign participants don’t know who else has registered, especially if they register through third-party platforms. With a new registration solution, participants can see who joined the campaign and who shares common interests or motivations with them.

Third, we envision the registration system being integrated with an events calendar. Once we have built registration, we can incorporate registration support into various calendars and event discovery tools.

Finally, we want this project to be a deeply collaborative effort. In preparation for this project, we consulted with about 50 campaign organizers. We want to sincerely thank these organizers, who provided us with a richer understanding of the organizer experience and its greatest challenges. Now, we invite all campaign organizers to share their feedback on the project talk page!

Why we want to improve registration

[edit]

We believe that registration is a strong project choice for the team for the reasons listed below.

  1. There is currently no standardized, on-wiki system. The Wikimedia movement needs a robust registration system designed for its needs.
  2. The current registration alternatives used by organizers have many issues, including being:
    • Time-consuming and tedious for organizers to configure and manage.
    • Data-light. They provide minimal information on participant needs and make it hard for organizers to understand who participated in what events.
    • Technically challenging and confusing for newcomers to register.
    • Difficult for participants to edit information after registration.
    • Not preventing multiple registrations of the same person from occurring.
    • Not multilingual or built for diverse language communities.
    • Not fostering a sense of community and inclusion among participants.
    • In conflict with Wikimedia values (i.e. many tools require disclosure of private information on a third-party platform).
    • Not integrated with any wiki pages or platforms, adding additional complexity for newcomers.
    • Not integrated with existing tracking systems, like the Programs & Events Dashboard.
  3. Organizers, affiliates, and other movement stakeholders want better data on participants and their needs. Developing a registration system is the first step in making this possible.
  4. Registration is the building block for future work. Once we improve registration, we can begin to integrate other features into the campaigns workflow, such as improved tracking tools or improved communication tools.
  5. The project is manageable and within scope for the team.

Nearly every organizer we have spoken to has designed their own registration solution. Some of these solutions are learned from other organizers and some come from previous organizing experience. Others are designed around specific technical requirements. Our goal is not to design the first registration system, but to provide an improved solution that helps create a consistent workflow for organizers in different contexts.

Open questions

[edit]

Thank you for reading our analysis. Now we want to hear from you! We kindly request that you respond to the questions below (or share any other feedback!) on the project talk page:

  1. What do you think of our plan to create a campaign registration system? Do you think it would be useful to you, as a campaign organizer and/or participant?
  2. What do you think of our analysis of the current registration processes? Are we missing anything important to you?
  3. If you are a campaign organizer, what registration system do you use? What does and doesn't work well with that system? If you could change one thing about it, what would it be?
  4. If we create a registration system, how would you like it to work? Please provide as many details from what you would like or, if you have them, examples from other registration tools you have used before!
  5. We are a new team (check out the new landing page). What are your hopes, questions, or concerns for our team?
  6. Anything else you would like to add?

Your feedback is very important to us and it will directly impact the choices we make as a team. Thank you, and we look forward to reading your comments!

Prototype

[edit]

This is the prototype is for V0 (the first version of the tool that we will be releasing). Please note that these are only prototypes; they are not working software on live wikis. These prototypes give a general sense of how the finished product may look, feel, and function once we do release the registration solution, although there will probably be some changes.

Follow our work

[edit]

We are going to be sending occasional (at most monthly) update newsletters via MassMessage.

Previous updates:

Status Updates

[edit]

May 23, 2022

[edit]

Hello, everyone! First, thank you to everyone who has participated in our talk page feedback, office hours, or chat group conversations. Your feedback and insights have been absolutely crucial to our project, and we deeply appreciate it. We also have some exciting updates (and new questions!), which we’ll share below:

Engineering update

[edit]

The team engineers are continuing to work on building the event registration system. They have built the majority of the back-end infrastructure, and they are now focused on building the front-end (i.e., the user interface). We predict that an early testable version of the registration solution will be available on the beta cluster in July 2022. To learn more about the engineering work, you can check out the definition of our schema on Gerrit.

Prototype updates

[edit]

We have an updated prototype, which was created by our team designer, for you to check out (see links below). This prototype is for V0 (the first version of the tool that we will be releasing). Please note that these are only prototypes; they are not working software on live wikis. These prototypes give a general sense of how the finished product may look, feel, and function once we do release the registration solution, although there will probably be some changes.

  • V0: Create Event Registration Prototype: This is the organizer side of the experience, where the organizer enables registration for an existing event page. Registration can be enabled on any event page, as long as it is in the event namespace. You can also watch a video walk-through of the process to create an event page in the event namespace and to enable registration for an event page on Commons.
  • V0: Register for Event Registration Prototype: This is the participant side of the experience, where the participant registers for the event. Note that only the username and timestamp of when the participant registered is collected for V0. You can also watch a video walk-through of the participant registration experience on Commons.

Our release plan

[edit]

Our release plan: We now have a basic release plan. We plan to release the registration solution in three parts, which we will explain below:

  • V0: This is the version of the tool, which we are focused on building now. It will be released to the beta cluster, probably in July 2022. We’re calling it V0 because it is a test phase that will not be released to any live wikis (just a test wiki). The purpose of this release will be to collect user feedback in preparation for the V1 release. In this version, organizers will be able to add registration to event pages and see a list of registered participants. This will be a desktop version only. You can view the prototype example in the links provided above (see “Prototype updates”):
  • V1: This version will be an improvement of V0, with the inclusion of more features, such as: the ability for organizers to contact participants, integration with the Programs & Events Dashboard, and geolocation support. We will also incorporate feedback we receive from users in the V0 testing phase. This version will be compatible with both desktop and mobile web versions of the wikis, and we plan to release it to at least 1 live wiki (probably Meta-Wiki). This version is a big upgrade with a lot to discuss, so we’ll dedicate a separate status update to collect feedback on the V1 requirements and prototypes. You can expect this status update on V1 to be posted soon.
  • V2: This version will be an improvement of V1, based on user feedback and the addition of more features. We haven’t fully fleshed out the requirements, and we don’t have a prototype yet. You can expect more updates on this final version in a future update.

Requesting your feedback

[edit]

We want your feedback on event page behavior: In the open questions section, we have shared some questions on how events and event pages should be handled. We would love your feedback (see below):

  1. For event registration, what is the recommended behavior for blocked users? Should blocked users be able to join campaign events? Why or why not? And does it matter, depending on the type of block (such as hard block, soft block, etc)?
  2. For event pages in the event namespace, should we allow the pages to be moved?
    1. If yes: What happens if an event page gets moved to another namespace and it has registered participants?
    2. If yes: What should be the behavior/warnings to the user if they want to move the page?
    3. If yes: What should happen if an event page is moved to a namespace where event pages are not allowed?
  3. For event pages in the event namespace, should we allow the pages to be deleted?
    1. If yes: Who should be able to delete event pages?
    2. If yes: What should happen if an event page gets deleted and it has registered participants?
    3. If yes: If people have registered, what should happen to the data if the page is deleted?
  4. Is there anything else you would like to add (about the V0 prototypes, release plan, or anything else)?
Thank you in advance for your feedback, and we look forward to reading your responses!
Browse for Latest Wireframes
Creating Registration via Event Page Search Enable registration for event page after creation Registration of participants in a campaign