[PROPOSAL] - Cross-post our events on our website!

[dxnn]

Describe your proposal

We should post our own events on our website. This gives more content to our website and provides us with a permanent archive of TorontoJS events. If the events are stored as e.g. JSON files, it also provides us with a dataset that we can load into the browser and do cool things with (that's probably a different proposal). We can also load in all of our historic events (also a different proposal). This could potentially be built on top of the tooling constructed in #1, or it could be something separate.

Why is this proposal important?

Having our own event listings makes it easier to show the archive of all the amazing things we've done over the years. Note that this proposal is not about managing events, it is just about showing the event listing -- we'll still point to external community/event management platforms like Guild for managing RSVPs etc.

Who will benefit from this proposal?

People running events will have a stable place to point to the historical archive; those seeking sponsors, new members, etc will be able to point to a stronger website with more information on it; and our community members (and the world) will be able to easily browse our past events and see all the neat things we've done!

When will this happen?

Ongoing -- maybe we'll eventually build some tooling for cross-posting events easily, or rely on a JSON export facility from an existing platform.

What platform/location will the proposal need?

I'm picturing these as JSON files in our github website repo, exposed through our website. We'll want a nice naming scheme for them that lets a client slurp them in by iterating through them.

How much will it cost?

Some amount of time from event organizers to add the JSON file -- hopefully a very small amount!

Describe the technical details of the proposal

We need a JSON schema for an event, ideally one that can start simple and expand over time. We need a naming schema, maybe just consecutive numbers (e.g. event-000001.json -- I'll be very happy for this to break when we pass our millionth event).

Anything else?

No response

Tag the organizers

@torontojs/organizers

[madcampos]

We can use the same structure as #1 to handle event.

I'm a little bit biased because I've been using astro a lot recently and it is a nice CMS in my opinion.

I've implemented something similar but "simpler" on my website.
Here is an example of what it looks like: https://madcampos.dev/talks/tojs-web-components
And here is the code for it: https://github.com/madcampos/madcampos.github.io/blob/main/src/content/talks/tojs-web-components.md?plain=1

In this case the code is markdown with frontmatter as metadata, but astro supports json as well.

[dxnn]

Cool, that could be a great option! I like JSON for this because I want to be able to load the events into the browser and make weird graphs and things (like "graph of online vs offline events over time" or "how many events mention pizza?" or a slideshow of images from events, that kind of stuff).

[tazsingh]

FYI (no pressure to use this or anything) - we received a bunch of requests for a Guild API, so I released a very simple one. Might be handy for this?

Endpoints can be found here (that Swagger UI is a bit annoying): https://guild.host/api/next/docs
We'll move from /api/next to /api/v0 once it's ready to be locked-in

All those can be accessed via https://guild.host/api/next/torontojs for the /{slug} endpoint for example. You may found the /{slug}/events/upcoming & /{slug}/events/past endpoints useful. If you need anything else, feel free to message me or email us at [email protected]!

[madcampos]

We can use astro's collection feature on the blog for creating each event as a json file (with schema and validation support).

During build time it is also possible to send requests, so we can integrate that with guild's api and generate data/pages based on the requests. Like, we could have a baseline for event data coming from guild and augment it with extra things from data collections.