A sign-up sheet for the METHODS Group's meetings with Thomas Surowiec during his visit (October 13 to 15, 2026). The page is served by GitHub Pages from the root of main; members pick a one-on-one slot, lunch, or the Tuesday evening outing and press Claim.
How it works: pressing Claim opens a pre-filled GitHub issue form (.github/ISSUE_TEMPLATE/). When the issue is opened, the Record sign-up workflow runs scripts/process.js, which validates the request against data/schedule.json (slot exists and is open, capacity not exceeded, valid room, no duplicate), appends the claim to data/signups.json, commits to main, then comments on the issue and closes it. Pages republishes on the push, so the name appears on the page within about a minute. To fix a mistake, edit data/signups.json by hand (each claim is one object in claims) and push to main; to change the schedule, edit data/schedule.json the same way. A meeting slot with open: false and a reader-facing note (and optionally a closed_message for the issue comment) is shown as held, with the note in place of a Claim button; delete the note and set open: true to reopen it. A slot with closes_at (ISO 8601 with offset) stops taking new sign-ups once that time has passed: the page shows it as Closed with its bookings still listed and no Claim/Join button, the workflow rejects new claims and joins (cancellations still go through), and the optional closed_note (page) and closed_message (issue comment) replace the default wording; this is how a day's sign-ups are closed after the fact (Wednesday, Oct 14 closed at 10:20 am ET). A day's optional note is shown above its grid. A slot of kind reserved is assigned by hand (its people are ordinary records in data/signups.json) and is shown like a filled slot with no buttons; the workflow rejects claim, join, and cancel on it. Run node scripts/test.js to check the processing logic.
meetings/index.html (https://methods-group.github.io/public/meetings/) lists the METHODS Group's weekly research meetings: the current semester's time, room, and Zoom link at the top, then an Upcoming/Past toggle over one card per talk (date, presenter, title, keywords, abstract, and links to slides, papers, and the Slack announcement). It is rendered by assets/meetings.js from data/meetings.json, with page-specific styles in assets/meetings.css.
To add or edit an entry, edit data/meetings.json on main and push; Pages republishes within about a minute. Each talk is one object in talks with date (YYYY-MM-DD), presenter, title, abstract (plain text; <b>, <i>, <code>, <br>, and <a href="https://..."> are allowed, anything else is stripped), keywords (array), links (array of { "label", "url", "kind" } with kind one of slides, paper, code, video, announcement), status (upcoming or past; the page groups by this field, not by today's date, so flip it after a talk happens), and an optional reader-facing note. Past talks are grouped by semester, derived from the date (Jan–May Spring, Jun–Aug Summer, Sep–Dec Fall) unless the entry sets term. The semester block at the top holds the current meeting time, location, Zoom link, and the sign-up sheet URL; bump updated when you change the file. Slides live in Slack, so slide links point at the Slack message that carries the file (login required); do not commit slide files to this repository.
A daily automated sync reads the announcements in #group-meetings (Slack channel C083Q60ESNS) and the sign-up sheet (Google Sheet 1jcNUKmm2uvCUYQMNY8rUwx8yA91LiCYYOIfEvkDuJIQ, current-semester tab) and updates data/meetings.json. Channel announcements take precedence over the sheet when the two disagree about the same talk. The top-level sync object in the JSON records the channel id, the sheet id and tab, the precedence rule, the date of the last run, and channel_last_ts, the newest Slack message ts already reflected in the data (the next run only reads messages after it). Manual edits to the JSON are preserved: the sync overwrites a field only when the channel or the sheet later supplies a non-empty value for that same field.