Appathon Event Tooling

[Arlodotexe]

Overview

Any additional tooling and documentation needed to facilitate the Appathon event itself on top of the SDK and discord bot.

This will all run on the same machine as the discord bot, and the event will primarily be on Discord for now with publisher-based blog posts on the web.

Posted in #event-planning:

Closed off, all docs from our old Wiki repo (which we created together in staff meetings) have been ported to the new meta repo.

As promised here, I have my high-level bearings on everything we need to complete for us to migrate away from the old backend.

However, SDK tooling for new event is still a bit fuzzy. A lot of vanilla SDK can be leveraged for the event without extensions, but I need a full birds-eye view of what we plan on doing for the event.

We should, as staff, revisit our work-in-progress community events docs and finish fleshing them out-- including how we'll tackle the Appathon tooling-wise. It's time.

Using what we have

I mentioned to staff that "A lot of vanilla SDK can be leveraged for the event without extensions".

By this, I mean that we can create Publishers which represent the event, it's parts, and its' recurrence over time.

An example tree of parent/child publishers that represents this:

• Windows App Community
  • Appathon
    • Appathon 2025
      • Appathon 2025 Q3
        • Make
        • Launch
      • Appathon 2025 Q4
        • Make
        • Launch
    • Appathon 2026
      • Appathon 2026 Q1
        • Make
        • Launch
      • Appathon 2026 Q2
        • Make
        • Launch

Since each publisher that uses our SDK gets their own blog, this creates a clean hierarchy that can handle:

• Posts about the event itself happening over time
• Posts about the details of each individual event
• Future changes to event details (make/launch)

Under the leaf publishers detailed above, other projects, publishers and users can register for the event.

What we need / open questions

See #17 for information about linking webpages from entity data on IPNS.

We'll need to close off our work on the blog generator and/or the SDK profiles before we tackle this.