[Backend] Feed an RSVP of "no" into the session at-risk evaluation #525

New issue

Closed

opened 2026-09-06 04:06:30 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-09-06 04:06:30 +00:00

Collaborator

Follow-up from #370 (v4.3.0 phase 4), deliberately left out of that change because it alters when the at-risk Discord pings fire.

availability_service.evaluate_session_at_risk counts explicit time-slot votes only. With web RSVP in place, a confirmed session now carries session_attendance.rsvp_status (yes | maybe | no, NULL = no answer) for every member, which is a better attendance signal than a slot vote cast weeks earlier: a party where three of five have answered "no" is at risk even if the slot vote was unanimous.

Proposal: treat rsvp_status = "no" as a declared absence and "maybe" as half-weight (or as unanswered; decide and document), so the at-risk warning reflects what people said most recently. Keep the existing threshold semantics and the campaign's reminder_offsets_minutes; add tests for a session that is at risk only because of RSVPs and one that stops being at risk once RSVPs come in.

Follow-up from #370 (v4.3.0 phase 4), deliberately left out of that change because it alters when the at-risk Discord pings fire. `availability_service.evaluate_session_at_risk` counts explicit time-slot votes only. With web RSVP in place, a confirmed session now carries `session_attendance.rsvp_status` (`yes | maybe | no`, NULL = no answer) for every member, which is a better attendance signal than a slot vote cast weeks earlier: a party where three of five have answered "no" is at risk even if the slot vote was unanimous. Proposal: treat `rsvp_status = "no"` as a declared absence and `"maybe"` as half-weight (or as unanswered; decide and document), so the at-risk warning reflects what people said most recently. Keep the existing threshold semantics and the campaign's `reminder_offsets_minutes`; add tests for a session that is at risk only because of RSVPs and one that stops being at risk once RSVPs come in.

claude-bot referenced this issue

2026-09-06 04:22:13 +00:00

v4.3.0 build order: Product Surface in eight phases #514

claude-bot referenced this issue

2026-09-06 04:22:32 +00:00

feat(webapp): web RSVP, post-session task statuses, and a "Needs you" dashboard (phase 4 of v4.3.0) #526

claude-bot referenced this issue

2026-09-06 04:22:52 +00:00

[Frontend] Add a web RSVP control — RSVP has no web surface at all #370

claude-bot referenced this issue

2026-09-06 09:54:06 +00:00

v4.3.0 build order: Product Surface in eight phases #514

rbrooks referenced this issue from a commit

2026-09-12 23:33:38 +00:00

feat(backend): feed RSVPs into the session at-risk evaluation (#525)

claude-bot referenced this issue from a pull request that will close it,

2026-09-12 23:33:52 +00:00

feat(backend): feed RSVPs into the session at-risk evaluation (#525) #636

claude-bot closed this issue

2026-09-14 01:58:24 +00:00

claude-bot referenced this issue from a commit

2026-09-14 01:58:26 +00:00

Merge pull request 'feat(backend): feed RSVPs into the session at-risk evaluation (#525)' (#636) from feat/525-rsvp-at-risk into main

claude-bot commented

2026-09-14 01:58:43 +00:00

Author

Collaborator

Done in #636 (merged as 5c25ed9, CI run 1083 green).

Each member contributes 1 / 0.5 / 0 to likely_attendance: a recorded absence is 0 and is never overridden; otherwise the most recent answer wins — RSVP no/maybe/yes → 0 / 0.5 / 1, falling back to the slot vote when there is no RSVP. at_risk is judged on the exact value; the reported figure is floored so a Discord message never overstates it. Six new tests in test_availability.py.

Behaviour change: the at-risk ping now fires on tables that RSVP'd "no" against a unanimous slot vote, and stops for ones that have since all RSVP'd yes.

Done in #636 (merged as 5c25ed9, CI run 1083 green). Each member contributes 1 / 0.5 / 0 to `likely_attendance`: a recorded absence is 0 and is never overridden; otherwise the most recent answer wins — RSVP `no`/`maybe`/`yes` → 0 / 0.5 / 1, falling back to the slot vote when there is no RSVP. `at_risk` is judged on the exact value; the reported figure is floored so a Discord message never overstates it. Six new tests in `test_availability.py`. Behaviour change: the at-risk ping now fires on tables that RSVP'd "no" against a unanimous slot vote, and stops for ones that have since all RSVP'd yes.