allow rsvp'ing to talks and seeing rsvp'd talks (+ adding to calendar)

[flo-bit]

now that we're close to moving over to community events, allowing people to rsvp as going/interested would be cool as well as seeing all the talks they rsvp'd to (both as a list on the website and as an ical subscription so they have it in their calendar).

not sure how capacity stuff/people signing up for workshops etc currently works, but the easiest would probably be to just have that completely separate? (@bmann)

example with blento ical subscription:

[bmann]

Workshops should stay manual for that. We have signups for them in the Tito app.

And source of truth for workshops is the manual data on the site now. If you tell me where to edit source files for those (deep link and example) I actually have updates to make.

And yes I think RSVP (or rather - Interested? I think that’s the right verb) - and a UI that is more like favoriting / bookmarking is the action here.

[flo-bit]

currently (main branch) everything is in src/content/talks/schedule.yaml (easiest way to find stuff is to search for the id, alternatively you can search for type: workshop to find all workshops).

Just to be clear does that mean you want workshops to stay as yaml files too, instead of being moved to atproto records?

[bmann]

Sorry this keeps being confusing to people when I say it

• the workshop info is currently more fleshed out than what’s in the Grist CSV export so shouldn’t be overwritten
• if you turn workshops into records that’s fine - we just need to be able to edit them

The core point being that YAML data for workshops as is is the most up to date info. Does that make sense?

[flo-bit]

ok got that now, in general do you even want to keep updating the csv or do you want to switch over completely to editing events on atmosphereconf.org?

[essential-randomness]

I was trying to gather requirements on this and the main issue seemed to me that if a lot of events need to be changed at the same time because of an emergency it's hard to do in bulk. Was considering an emergency CSV export to download/edit/reupload, but still haven't fully figured out what would work best for folks

(Edit: this thread didn't update for me for some reason so i replied to an older question, but FYI this is where I'm at NEVERMIND it just keeps adding and removing the last message)

[flo-bit]

but wouldn't you still have to update the csv manually then?

for editing on the website we could also just display a table with all talks (w/ some filtering/search) (+ probably something like an "edit" button on individual talk pages, that go directly to that row of the table)

[flo-bit]

or quickly nerdsnipe someone into building a grist-on-atproto :D

[essential-randomness]

but wouldn't you still have to update the csv manually then?

yes, but that's easily imported in e.g. gdocs (and i assume grist) and then exported back

I've been trying to get information on what type of chnages were needed last year. We can build for the happy path and just have an escape hatch for the "worst case"...though I'm sure you can nerdsnipe someone into it.

[bmann]

@essential-randomness going to just overrule Ted here and say -- he has speculative use cases but I just don't think we can forecast mass changes. At that point it's fast to just click through 10 or 20 records and edit them rather than build something up front.

We didn't DO any last minute updates last year (i.e. as the conference was going). We do have three tracks, plus conf, which is a lot.

Sounds like we will build out a whole conference builder over time in the codebase, which honestly, I'm totally up for :)

[knowtheory]

No need to overrule, i'm on board with that path.

The two things i just want to make sure of is that we have a single source of truth, that the overall schedule is visible prior to pushing a new version live to production (whether that's editing yaml or changing records).

[essential-randomness]

Flow proposal for talks/workshop changes:

1. Records on atprotocol.dev PDS are source of truth
2. Create a npm run sync command that syncs them to the yaml files, with a big "DO NOT EDIT HERE OR YOU'LL BE FIRED" up top. This way we can do edits to the site without updating the talks and not have "in-between states".
3. Add a GitHub action with a manual workflow that runs npm run sync and opens a PR. The deploy preview acts as our chance to review.

We just need to push records to the right place once, then everything should take care of itself.

Also happy to make a github action that opens a PR automatically and accrues the changes from all records as they get edited, so there's one ready to go whenever.

[bmann]

Yes! Thanks for the phone run through @essential-randomness -- +1

@knowtheory needs to do a final CSV export "tonight", and then we can flip to records. Looking good.