Page MenuHomePhabricator

Create proposal for table/schema to store campaign registration data [high priority]
Closed, ResolvedPublicSpike

Description

As a Campaigns team member, I want to know how and where registration data can be stored, so that the team can begin developing a proposal on data storage & the schema to share with stakeholders.

Background: As the first stage of work in the registration project, we must first develop a proposal to share with various stakeholders. This proposal will detail how and where we will store the data collected in the registration experience on both organizers and participants. The end goal of this ticket should be able to collect the information that is needed to write the proposal. The actual proposal can be written in a separate ticket or document.

Relevant resources:

Acceptance Criteria:

  • Investigate how and where we can store the following data to be collected in the registration experience:
    • Name of event
    • Event page URL
    • Start date
    • End date
    • Start time
    • End time
    • Timezone for event
    • If event is virtual, in-person, or hybrid
      • If Virtual:
        • Link to join virtually
        • Joining notes/additional information
      • If in-person
        • Location name
        • Location address
    • Organizer usernames
      • Organizer who created the registration experience
      • Other organizers listed by creator
    • Desired tracking tool
      • Name of tracking tool
      • Link to tracking event
      • Link to external chat group for event (such as a Telegram group)
    • Usernames of registered participants
    • Date participants registered
    • Time participants registered
  • If the event registration is open or closed
  • Date event was created (For future analysis/viz: )
  • Drafted vs published
  • Campaign_id (which can attach to multiple event_ids)
  • Consider any major risks, dependencies, or blockers for doing this work
  • Take into account that we the registration experience may be expanded in the future to include:
    • Allowing organizers to ask more questions of participants (such as their wiki editing level or what topics interest them)
    • Allow organizers to write custom questions that participants can respond to in a blank field
    • Allow organizers to specify what kind of event they are organizing (such as a photography contest, writing contest, training for newcomers, etc)
  • Take into account 3 data types: allowing organizers to ask more questions of participants that could be public, questions that may only be available to organizers and aggregate analysis, and custom questions
  • Share findings in a comment in this ticket

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptOct 19 2021, 3:50 PM
ifried renamed this task from Create proposal for table/schema to store campaign registration data [TBD] to Create proposal for table/schema to store campaign registration data [high priority].Oct 19 2021, 7:54 PM

@ldelench_wmf When he's ready, feel free to assign this ticket to Joao or he can assign it to himself directly. Thanks!

The team held a meeting to discuss the first version of the schema. We determined that the following should also be added, which I have added to the ticket:

  • timezone
  • date event was created (For future analysis/viz: )
  • drafted vs published
  • campaign_id (which can attach to multiple event_ids)

Hi,
Database architect in the data persistence team here. If this is going to be in WMF production (specially in mediawiki), please keep me in the loop on the design. The proposed design looks good but there are some nuances special to wikimedia we need to apply. For example, timestamps are binary(14) and stored like that (T42626) and it's better to keep it in UTC and store the timezone separately. Or that use of varchar is avoided in production because of the issues with different encoding and it's better to use varbinary(). I'm trying to document these institutional knowledge so we avoid issues like this but in the mean time, please let me know about this. If you want to have meetings or anything else to discuss the details, I'm more than happy to have them!

Some useful documentation:

Hi @Ladsgroup,
Thanks for the insights, it was very helpful!
I'll send a message to you to schedule a meeting to talk more about the database. Thank you!


I have updated the Schema link:
https://dbdesigner.page.link/wFzU1KxRkc9JNNtG8

This and the extension build are blocking T290248

ldelench_wmf changed the task status from Open to Stalled.Jan 31 2022, 3:35 PM

@JCarvalho: Now that we have decided to move forward with the architecture outlined by @cmelo, is this task still blocked?

Organizer usernames
Usernames of registered participants

@JCarvalho Have there been any further campaigns-product conversations re: using a global 'user_name' field?
T209771 is looking at that topic in conversations around refining the current retention metric and mtgs are currently blocked per the ticket.

We updated the schema following our architecture decisions.
Here's the link for the updated schema
Some string fields on the schema are varchar, but we'll use varbinary; this happens because varbinary doesn't exist in DBDesigner.

I've generated the SQL file following some MediaWiki database guidelines:


The SQL file doesn't have constraints because this needs to be done on the application level.

@Iflorez, we don't need to store usernames on the database, but we need to get it somehow. Do you know if we could get usernames by user_id?

Since the work encapsulated by this ticket is done, I will mark it as "Done". But keeping this ticket open as there seems to be ongoing discussion.

As development work has started and we now have a database with some data, I think we can close this ticket.