Operators need shared state as well as fast updates
OWKR operations include team setup, admin selection exams, recruitment, waiting lists, and rules. Match editing must prevent one operator from silently overwriting another, rather than merely showing updates quickly.
Give each operational tool an explicit state boundary
Match: two operators editing the same roster
In PR #10, I implemented shared roster editing. If one operator adds a participant while another rearranges positions, replacing the full roster with the last write can lose the first change.
A Redis Lua operation checks the expected revision and updates atomically. Separate read and write calls could both pass the same check. A stale write receives a conflict with the current state.
The PR #10 client applies the current roster on conflict and asks the operator to reapply needed changes. Participant order and team positions are validated under one revision to keep the saved roster consistent.
Match: limit replicated data and update scope
Sessions store Discord IDs, participant order, and optional team positions. Display names and role tiers are hydrated from the user sheet rather than copied into every session. Missing or duplicate IDs and incomplete team positions are rejected.
PR #10 uses polling with delayed local publishing. Polling avoids overwriting pending local edits, skips hidden tabs, and does not run while publishing. PR #17 adds authenticated editor presence and recent changes to the existing response.
Presence and recent changes travel through the existing polling response, while revision checks validate the final save. Collaboration feedback and persistence rules have separate responsibilities.
Match: deployment constraints and regression coverage
Live collaboration and snapshot sharing use modes within the same Vercel Function. This fits the Hobby function limit while retaining the existing snapshot-sharing path.
Store tests check revision advancement and stale-write conflicts; contract tests check participant and waiting-list order, full team positions, and invalid IDs.
Other contributors improved authentication and matchup UI. My work covers the shared contract, API, hook, UI integration, and editor presence.
Exam: server-owned time controls
The app covers Discord sign-in, assigned codes, answer saving, submission, questions, and grading. In PR #4, I added pause, resume, and extension state on the server with regression checks for ownership, admin authority, expiration, submission locks, and repeated actions. PR #5 separates test attempts from normal admin records.
Gather Bot: recruitment and restart recovery
I worked on the Python and SQLite recruitment bot with per-session actors, participants, waiting lists, tier collection, and restart recovery. Authored changes include substitute recruitment, lobby assignment, migrations, and tests. It remains in development and testing without automatic Match integration.
Docs: maintain guidance alongside the tools
The Astro site provides rules, participation instructions, and FAQs. My commits update participation and notification rules and connect the entry points for the tools.
A connected set of community operations tools
Match is used for community match setup and result sharing, with collaboration and presence changes included in production deployments. Exam deployments include time controls and test-attempt separation. The operations guide is published on GitHub Pages; Gather Bot is in development and testing.
The work covers collaborative editing conflicts, server-owned exam state, event processing, recovery, and operational documentation.
Trace
- Match
- Used by community operators
- Exam
- Implemented and deployed
- Gather Bot
- Development and testing