Inspiration
Every hackathon has a second event running alongside the code: the conversation. Challenge channels fill with rule questions, logistics, progress updates and requests for teammates. We wanted to capture that conversation as data during TAMU Datathon 2026 and ask a simple question: what do participants actually need while they build? We also wanted to do it honestly, without pretending a partial sample is a census.
What it does
Participant Pulse is a dataset plus an interactive website driven by it.
- The dataset: 140 unique observed messages from all 8 challenge channels, with all 30 source fields, 11 observation snapshots and 150 snapshot–message links (the extra 10 are repeat sightings of the same Rev's Casino messages, not new messages). It ships as JSON, CSV views, an Excel workbook, a 135-field data dictionary and a SHA-256 manifest.
- Findings from the same records:
- 41 / 140 (29.3%) messages are help, rules or logistics discussion.
- 24 / 140 (17.1%) are strategy, progress or collaboration.
- 11 / 140 (7.9%) are participation self-report posts.
- The website: an overview with eight equal-size challenge nodes, a gallery of eight original animated SVG scenes, story cards that open the underlying evidence, and a message explorer filtering by challenge, category, snapshot, role and search. Every message opens to its paraphrase, source link, display time and full provenance.
- Coverage & method: partial samples are shown as partial and unread channels as missing, never as zero.
- Import and export: export JSON or CSV, and import new coded messages that merge by exact message ID, with conflict checks.
- A separate, clearly labeled fictional scenario: nine synthetic teams and 21 allocations, kept out of the observed data.
How we built it
- Collection: during the event (November 7–8, 2026), messages in the Datathon Discord challenge channels were read through an authorized Chrome session. For each message we recorded the exact 19-digit message ID, displayed date and time, source link, a channel-scoped alias and a neutral paraphrase, never the raw handle.
- Deduplication: each message is counted once by its ID, so scrolling overlap and rereads don't inflate counts.
- Coding: each message has one of 12 observed content categories, assigned by AI-assisted single-assistant coding. All 140 records are marked
human_reviewed: false, and the documentation says so. - Packaging: a Node.js script validates source identities and snapshot links, copies the original JSON bytes and refreshes the SHA-256 manifest. Message IDs are stored as text so Excel can't round them.
- Website: dependency-free HTML, CSS, JavaScript and SVG, deployed to GitHub Pages by a GitHub Actions workflow that runs the tests and checks that the published downloads match the canonical dataset.
- Testing: 31 tests pass, covering sample reconciliation, snapshot membership, duplicate handling, import validation, CSV escaping and separation of synthetic data. A browser review at 1440 × 1000 and 390 × 844 found no horizontal overflow.
Challenges we ran into
- Partial, unequal coverage: channels were sampled over different windows, from 9 to 30 messages each, so we refused to rank channels or compute messages per hour.
- Identity without names: aliases are scoped to one channel and never combined into a person or team count.
- Big numbers vs spreadsheets: 19-digit Discord IDs get rounded by Excel and by JSON numbers, so IDs are strings everywhere.
- Access: early navigation attempts were blocked; a later authorized session reached the remaining seven channels. The history of that limitation stays in the snapshot notes.
- Unknowns stay unknown: the posting timezone and exact capture times weren't recorded, and only 2 messages have inspected reaction counts. Missing values stay missing.
Accomplishments that we're proud of
- Every number reconciles: 140 rows and 140 distinct IDs; 150 snapshot links equal 140 unique messages plus 10 repeat sightings; all five packaged JSON files match their original bytes.
- Traceability: every count in the website can be opened down to the individual records behind it.
- A reusable acquisition protocol in
dataset/METHOD.md, so someone else can collect a comparable dataset. - A clean wall between observed and synthetic data, enforced by tests and by the import rules.
What we learned
A small dataset can be valuable if it is honest about what it is. The hardest part wasn't counting messages; it was saying precisely what the counts don't mean. These are messages, not people; samples, not a census; interpretations, not verified emotions. Designing the data model around provenance first made the dashboard trustworthy.
What's next for Participant Pulse
- Fixed, equal observation windows across all channels, so channels can be compared fairly.
- A second human coder on a subset of messages to measure coding agreement.
- Consent-based in-person data: short surveys at the venue to pair the online conversation with what participants report directly.
- Reuse at future events, so organizers can see which rules and logistics questions recur and fix them in the guides.
