User Events Management System

[mbaruh]

I present a design for a full system for managing user events. It will hopefully allow us to accommodate and invite more users to organize their own events, and to properly make use of the new User Events voice channel.

This issue should be implemented alongside the related issue in the site repository python-discord/site#396

Current State

With the recent changes in the voice channels, we repurposed the Games channel to a User Events channel which will only be open during a user event. Additionally, we introduced a new channel #user-event-coordinators.
Currently, user event coordinators can ask an admin to open the channel for them.

The New System

We introduce a scheduling system for user events. The system will work as follows:

Scheduling

A user who wants to stream some content / organize a small event on the server asks for an admin's permission and is granted the role User Event Coordinator, assuming we trust them - nothing different so far.
However, this role only grants the permission to access the #user-event-coordinators channel, and to schedule their event.

A PR implementing this system will provide a member with the User Event Coordinators role with the following commands

!userevent create <event name>

• This will allow a coordinator to own a new event, allowing it to be scheduled.
• The event name should be different from any other event created so far.

!userevent schedule <event name> <start datetime> [duration=3h]

• The coordinator will be able to schedule their event by specifying a date and time. The event name should be of an event which already exists (using the create command) and is owned by the user invoking the command.
• This will reserve them a time slot so that no two event coordinators accidentally plan an event for the same time slot. When checking whether a time slot is free, it needs to be free from half an hour before the appointed time, until half an hour after the event is scheduled to end.
• A coordinator will be able to only reserve one time slot at a time, for only one of their events.
• The duration of the event is three hours by default, but can be explicitly made to be up to five hours long. It can't be less than half an hour.

!userevent cancel

• The coordinator will be able to run the command if need be, and free their timeslot.
• The event's name is not required as a coordinator can only have up to one event scheduled.

!userevent delete <event name>
Deletes the event of that name, assuming it's owned by the user invoking the command, removing it from the DB.

!userevent sublist <event name>
Lists the users subscribed to the named event (explained further in the following section).

Subscription

After an event is created, other users will be able to subscribe to the event, allowing the coordinator to know ahead of time who wants to participate, and to ping them before the event begins (related command detailed in the next section).

A PR implementing this system will provide all members of the community with the following commands

!userevent sub <event name>
Subscribes the user to the specified event.

!userevent unsub <event name>
Unsubscribes the user from the specified event.

!userevent when <event name>
Shows the scheduled date and time of the event (assuming it's scheduled).

!userevent list
Lists all scheduled userevents and their times.

The Event

Half an hour before the scheduled time arrives, the bot will ping the coordinator in the #user-event-coordinators channel, and will automatically grant the role User Event: Ongoing. This is the role which will grant the user streaming permissions.

A PR implementing this system will provide a member with the User Event: Ongoing role with the following commands

!userevent open
Unlocks the User Events voice channel.

!userevent announce [message]
Pings the users subscribed to the event in the #user-event-announcements channel along with the specified message.

!userevent close
Locks the voice channel, for example if they don't want any additional people to join or if the event ended ahead of time.

After the scheduled duration, the channel will lock automatically (but not kick them out in case they need a little time to wrap up), and the User Event: Ongoing role will be revoked.

---

These commands should be run in either #user-event-coordinators, #user-event-chat or #bot-commands.

Additionally, the relevant roles should be added to the bot's config files.
User Event Coordinator: 591999763478609927
User Event: Ongoing: 757666374607831221

[RohanJnr]

A few suggestions:

• Have a new channel called user events which lists all the scheduled events.

• Whenever an event is scheduled, using the !userevent schedule <event name> <start datetime> [duration=3h] command, the bot sends a message in user events channel with details such as - event name, event host, start datetime and duration.

• We could use reactions for subscription on the event message which will be sent in the user events channel.

  • 1 reaction to toggle subscription.

• If the above is followed, then !userevent when <event name> and !userevent list are not required.

• Event Status

  • The message which will be sent in the user events channel whenever an event is scheduled, will also display the Status of the event. Example: canceled, on-going, finished, scheduled, about to start.

[RohanJnr]

I can work on this and the site issue together if this is a go (considering my suggestion which I mentioned above).

[mbaruh]

@RohanJnr This is a pretty good idea.
One issue that I have with it is that technically you'd have to scroll to the last time the event was scheduled to sub / unsub. But this isn't something to consider for right now

[RohanJnr]

plan.pdf
I made a diagram(view the pdf).
Here is what I am suggesting again:

• Store the ID of the message which will be sent in the #user_events channel(this channel will list all events by listing their name, description, organizer and status).

• Add reaction to that message to toggle subscription.

• When the event starts, the bot sends an announcement in #user_events_announcements channel by sending the event name, description and tags all the users who have reacted to the corresponding event message in #user_events channel.
  This will be done by fetching the message ID from the site.
  Then we can sync the subscribers with the site(if required).

The rest is the same as mentioned in the issue.

[mbaruh]

I'd rather the ping wasn't automatic. There's no guarantee that the organizer is actually available at the assigned time, for whatever reason, in which case pinging everyone isn't ideal. So the ping option should be invoked manually imo.

I might be wrong, but looking at the plan it seems you want to use the description when pinging. My impression when you suggested it is that you want to use the description for the scheduling, which seems appropriate if that's where you add the subscription option. At the time of the ping, the organizer might want to tweak their announcement to whatever it is they want to say, so the description might not be relevant.

Both issues are handled by using the announce subcommand.