search

python-discord / site

pythondiscord.com - A Django and Bulma web application.
https://pythondiscord.com
MIT License
638 stars 127 forks source link

Event scheduling system #1269

Open hedyhli opened 4 months ago

hedyhli commented 4 months ago

With a new design for our events page (#1210), we’ll have to update our events page more often to keep it up-to-date. We need a way to minimize the efforts and friction for this redundant work by automating it in some way.

Note: The problem this proposal tries to solve comes from the design of the new events page, for which PR is not yet merged, but in the event of that feature not ending up getting to production, I believe some ideas presented here can still be useful regardless of what our new events page might look like.

I recommend having a brief scroll through the redesigned events page and the events' README.md file before reading this issue to familiarize yourself with its components which will be mentioned throughout this issue.

The problem

Our new events page will display three components that require fairly frequent updates:

  1. The “Scheduled” events list — showing a list of upcoming events lined up for the rest of the year with brief descriptions of what each is about.
  2. The “Previous” events list — the same as above, except it's for events that recently happened.
  3. The “Current” event box

It’s cumbersome to have to PR to the site repo every time an event is scheduled, or after it has happened. Ideally, we just need the event host to specify the list of events to display and the dates they will happen, once, by whatever means, and the site should automatically display this event as either upcoming, current, or having already happened after its scheduled date has passed, depending on the date of the web request.

The solutions

Here are two possible solutions I thought of.

  1. First option A bot command can be used to set up the dates for a new event, say PyWeek — March 17-24th, the bot then sends an API request to the site and the site can reflect these dates for the new event on the events page. When the events page is requested at a time after March 24th, PyWeek 37 then shows up under "Previous events". This removes the chore of having to update the static page whenever an event starts/finishes.

  2. Second option Use a markdown/YAML file in the site repo (similar to the branding calendar) to specify all the events and all their dates for the year in one go. The idea is, we update the file only when events are rescheduled or new events are introduced, then have the site pull data from this file and display the event in eitehr scheduled, current, or previous depending on current date. This is easier to implement than the first option as only work on the site needs to be done, but PRs are still required, just much less frequent than how it is in the status quo.

User experience would be best in the first option — all we need is to run a few bot commands — less burden for reviewers and any amendments can be made faster. However, the system would require much more work to implement.

I floated the first idea in #dev-contrib and @janine9vn indicated her interest; so in this issue, I’ll be focusing on the first option — what is required, suggested implementation, and the resulting workflows.

How it could work

Each event in this context is a standalone instance of perhaps an annually occurring event, for example, PyWeek 37 would be one event, rather than PyWeek in general. One-off events would also apply.

The website needs to know, when the main page is requested, the list of events to be showcased. Whether to put an event in “Scheduled” or “Previous” is determined by the view handler on the site, based on date of the web request.

For each event, the website needs the:

For annual events:

Possible Implementation

Here’s a brief breakdown of the general pipeline of an event before it ends up on the events page:

  1. Bot: Bot command to setup all the information
  2. Site: The data is sent to a site API
  3. Site: The site saves the data in some way, such as using a DB table
  4. Site: The page is requested
  5. Site: Events to be displayed are fetched from the DB
  6. Site: The view handler processes the data into three separate lists - Scheduled/current/previous
  7. Site: The three lists are passed into the front page template, which displays them in a similar manner as it’s displayed now

Bot — Commands

For brevity, let’s say we use Sir Robin and the base command is &event . Sub commands of &event:

Annual events

For recurring events such as Advent of Code and PyWeek, we would want to reuse descriptions and the default branding so we don’t have to specify them each time the event is scheduled. These sort of information would be updated less often, so they could just be defined in the site repo as something like YAML. This data (committed to git) can then be read when the events app is loaded, just like for resources/content apps. An identifier (like a slug) will be defined for each of these events so that when scheduling a yearly occurrence of it through the bot commands, we can refer to this identifier in the “type” field.

For example:

Site — Front-end

How many events or for how long do events stay in the “Previous events”? This can be controlled in the template or view.py to show the event lists.

Site — API

We could have something like a /bot/event endpoint implemented within the events app with the following methods:

Site — schema

Fields

Operations

Déjà vu?

As it happens, we once had a proposal very similar to this one, but for a different purpose:

Unfortunately, it was eventually abandoned because discord introduced the native events feature that replaced what that proposal tries to implement.

However, Iceman made a really nice diagram which could be very useful for reference in this issue: https://github.com/python-discord/bot/files/5360694/plan.pdf

And they also did some amazing work in these two PRs which was supposed to implement Zig’s issue:

All of this could be useful as reference when we consider the feasibility of this current issue and during implementation.

Workflows

Now, after writing all that, I started to question whether putting in the work to implement such a thing could save time and hassle in the long run at all. Here’s a comparison of the status quo with what the workflow might look like if this is implemented.

Related

Small event management system - bot#1603

Branding calendar system

Other references

Credits for the original idea goes to @doublevcodes from https://github.com/python-discord/bot/issues/1603#issuecomment-845494380

This probably won't be a priority but it would be cool to have any events scheduled show up on this website (as I currently understand it the whole events section is being redone).

Proposal in #dev-contrib: https://discord.com/channels/267624335836053506/635950537262759947/1219026167571677324

Feedback appreciated!

To be frank, I’m not very familiar of our existing systems to manage events within our server, if any exist at all. I've written this issue from the perspective of someone who hardcoded as HTML those three lists we need to keep up-to-date — and how it might work when connecting with the bot. I would be curious to hear about how well this proposed system could be integrated to our existing workflows in hosting events, as well as any other feedback regarding design decisions mentioned and the user interface proposed.

Do you think the work to be put into this is worth it to make the process easier? Is submitting PRs every time that much of a hassle right now (considering the new redesigned events page)? Could something like this also help with any other parts of the events management workflows in the server, or in the future?

jchristgit commented 3 months ago

I do think that the less manual labor we have with updating the events page, the better. I think the repeated occurrences of the page becoming outdated only for some "batch update" much later to bring it back into the current year showcase the benefits of the API-based solution very well. There is one more problem that I can think of. If we go the database-backed approach, then contributors who set up the site will not have the same events on the events page than the live site has. More, it will become more complicated for them to update any entries of the events page locally. So overall I think we would lift off some convenience from contributors in exchange for being able to keep the page up-to-date more easily - I think it's a worthy tradeoff but we do need to consider it.

hedyhli commented 3 months ago

More, it will become more complicated for them to update any entries of the events page locally.

Hmm, update the entries in what sense? This proposal intends to allow updates to the entry via bot commands, so contributors do not need to do anything in the repo. If those commands are mod/events-lead/admins-only, they can simply mention any changes required over on discord and someone with the perms who sees it can action it immediately.

There is one more problem that I can think of. If we go the database-backed approach, then contributors who set up the site will not have the same events on the events page than the live site has.

That's a good point! I hadn't considered that. But after we have this system in place is it really necessary for contributors to have the same list of events? For any PRs that involves the events page design or changes to the template, yeah having no data would be a little inconvenient. For now, one way I can think of (without running bot simultaneously) is including a file similar to init.sql that prefills some dummy events, so some content can show up on the events page for them to preview any changes to the CSS/HTML they are making.

jchristgit commented 3 months ago

For now, one way I can think of (without running bot simultaneously) is including a file similar to init.sql that prefills some dummy events, so some content can show up on the events page for them to preview any changes to the CSS/HTML they are making.

Yup, I think this would be the way to go if we end up choosing this approach.

wookie184 commented 3 months ago

Personally I think I would be in favour of the second option, defining event files using markdown/YAML.

A few benefits I think this has over the first option: