m/fdbck
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

New question type: wann-treffen — multi-day rating grid + hosting flag + threshold alerts (FIFA-Runden) #5

New Issue
Closed
opened 2026-05-09 09:30:45 +00:00 by mAi · 1 comment
mAi commented 2026-05-09 09:30:45 +00:00
Copy Link

Idea (m, PWA-Voice 2026-05-09 11:29)

"Eine besondere Idee nochmal für unser Feedback-Projekt. Einen ganz bestimmten Fragetypen. Und zwar 'wann treffen'. 'Wann treffen' ist so ähnlich wie das Date-Rating. Und es geht darum, mit den Viva-Jungs abzustimmen, wann man sich das nächste Mal treffen kann.

Brauchen ein Minimum von vier Leuten verlässlich, die eine 5 geben an einem Tag, und einer von denen muss angekreuzt haben 'kann hosting' oder so. Das heißt, wir suchen quasi gleichzeitig einen Host und genug Leute.

Und wenn wir da einen bestimmten Schwellenwert erreichen, dann sollen Alerts ausgelöst werden, zum Beispiel eine WhatsApp-Gruppennachricht, sodass das dann eben organisiert werden kann.

Im Kern möchte ich, dass du also Otto FIFA-Runden für mich organisieren kannst, aber so, dass die Leute eben abstimmen auf einer Webseite, möglichst komfortabel, dass sie sagen 'passt mir gut, passt mir nicht gut', also auf ein Rating von 1 bis 5, 'ich könnte hosting' / 'ich kann nicht hosting'. Und dass wir das eben so ein bisschen als stehendes Ding haben und immer, wenn sich da etwas herauskristallisiert, dann soll es einen Alert geben."

Concept: a new question type "wann-treffen"

Sibling to the existing date-rating type, but with a multi-day grid + threshold-driven alerting + standing (not one-shot) semantics.

Per respondent, per candidate day:

  • Availability rating: 1–5 ("passt mir gar nicht" → "passt mir perfekt")
  • Hosting flag: "kann hosting" / "kann nicht hosting" (boolean per day)

Threshold rule (configurable per question, defaults from m's voice):

  • ≥ N respondents rated this day a 5 (default N = 4)
  • AND ≥ M of those marked "kann hosting" (default M = 1)
  • → Alert fires.

Standing question: doesn't expire after one round. Stays open, days roll forward (window of next 4–8 weeks?), respondents update as their availability shifts. Once a day "kristallisiert sich heraus", alert fires once, day gets marked as "alarmed" so it doesn't re-fire.

Surfaces

Voter UX (web):

  • Date grid for the next N weeks
  • Tap a day to set 1–5 + hosting flag, all in two taps
  • Visible "current state" (anonymised counts: how many 5s, how many hosting offers)
  • Mobile-first — voters are friends, not power users

Alert channels:

  • WhatsApp group message (m's "Viva-Jungs" group) via the Evolution API
  • Optionally: PWA push to m, Telegram fallback
  • Alert content: "Treffen-Fenster: . Stimmen mit 5/5, Host: . Bestätigen / planen?"

Technical sketch (for the design phase)

  • Question schema additions: question.type = "wann-treffen", plus config = { window_weeks: int, min_yes_count: int, min_yes_score: int (default 5), require_host: bool, alert_channels: [...] }.
  • Response schema: extra fields availability_score: 1..5 | null, host_capable: bool | null, indexed by (question_id, respondent_id, day).
  • Threshold-evaluation job: trigger on every response insert. Compute the threshold per day, fire alert if just-crossed (state transition).
  • Anti-spam: max 1 alert per day per question (idempotency on (question_id, day)).
  • Group registry: a "respondent group" concept — m defines once "Viva-Jungs = phone-A + phone-B + phone-C + …", question references the group, alerts route to that group's WA chat ID.

Open design questions

  1. Standing vs. cyclic: standing window (rolling 8 weeks always visible) or cyclic ("we play monthly, vote on next month")? m's voice suggests standing.
  2. Anonymity in counts: voters see "3/4 with 5" but do they see WHO voted what? Probably yes within the friends group, but worth confirming.
  3. Re-trigger when a previously-alerted day gets a 4th '5': re-fire? Or only first crossing?
  4. Cancellation: m wants to cancel a day after alerting (e.g. host got sick) — separate "cancel"-flow, removes the day from the standing window for some weeks?
  5. Voter authentication: magic-link per phone? Open-link with name input? OAuth? Lightweight is preferred for friends.
  6. Question-pinning by m: should this question type live alongside other fdbck question types, or get its own surface (a "/treffen" page)?
  7. Recurring rules: m defines "we play roughly weekly" → system pre-fills the grid with optimistic candidates? Or pure manual day-by-day?

Out of scope (this issue)

  • Implementation
  • Other group-coordination types (out-of-fdbck — not the home for general scheduling)
  • Calendar integration (CalDAV write on threshold) — nice-to-have, separate phase

Workflow

Park-only. When m wants to pursue:

  1. Inventor designs the voter UX + answers Open Questions, drafts the schema additions
  2. Coder stage 1: question type, response schema, voter UI, threshold computation
  3. Coder stage 2: alert-channel adapters (WA group first, then PWA push)
  4. Coder stage 3: standing-window mechanics + anti-re-fire idempotency
  5. Optional stage 4: CalDAV-write on confirmed day, RSVP follow-through

Refs

  • m's voice via PWA 2026-05-09 11:29 (parking + scoping request)
  • Existing date-rating question type as the closest sibling — extend, don't duplicate
  • WA group send: wa.sh / mai-whatsapp skill (group-message support needs verifying — file separate issue if missing)
  • Use case: m's "Viva-Jungs" friend group, FIFA rounds — but the type is generalisable to any "friends pick a day" workflow
## Idea (m, PWA-Voice 2026-05-09 11:29) > "Eine besondere Idee nochmal für unser Feedback-Projekt. Einen ganz bestimmten Fragetypen. Und zwar 'wann treffen'. 'Wann treffen' ist so ähnlich wie das Date-Rating. Und es geht darum, mit den Viva-Jungs abzustimmen, wann man sich das nächste Mal treffen kann. > > Brauchen ein Minimum von vier Leuten verlässlich, die eine 5 geben an einem Tag, und einer von denen muss angekreuzt haben 'kann hosting' oder so. Das heißt, wir suchen quasi gleichzeitig einen Host und genug Leute. > > Und wenn wir da einen bestimmten Schwellenwert erreichen, dann sollen Alerts ausgelöst werden, zum Beispiel eine WhatsApp-Gruppennachricht, sodass das dann eben organisiert werden kann. > > Im Kern möchte ich, dass du also Otto FIFA-Runden für mich organisieren kannst, aber so, dass die Leute eben abstimmen auf einer Webseite, möglichst komfortabel, dass sie sagen 'passt mir gut, passt mir nicht gut', also auf ein Rating von 1 bis 5, 'ich könnte hosting' / 'ich kann nicht hosting'. Und dass wir das eben so ein bisschen als stehendes Ding haben und immer, wenn sich da etwas herauskristallisiert, dann soll es einen Alert geben." ## Concept: a new question type "wann-treffen" Sibling to the existing date-rating type, but with a multi-day grid + threshold-driven alerting + standing (not one-shot) semantics. **Per respondent, per candidate day:** - **Availability rating**: 1–5 ("passt mir gar nicht" → "passt mir perfekt") - **Hosting flag**: "kann hosting" / "kann nicht hosting" (boolean per day) **Threshold rule** (configurable per question, defaults from m's voice): - ≥ N respondents rated this day a 5 (default N = 4) - AND ≥ M of those marked "kann hosting" (default M = 1) - → Alert fires. **Standing question**: doesn't expire after one round. Stays open, days roll forward (window of next 4–8 weeks?), respondents update as their availability shifts. Once a day "kristallisiert sich heraus", alert fires once, day gets marked as "alarmed" so it doesn't re-fire. ## Surfaces **Voter UX (web)**: - Date grid for the next N weeks - Tap a day to set 1–5 + hosting flag, all in two taps - Visible "current state" (anonymised counts: how many 5s, how many hosting offers) - Mobile-first — voters are friends, not power users **Alert channels**: - WhatsApp group message (m's "Viva-Jungs" group) via the Evolution API - Optionally: PWA push to m, Telegram fallback - Alert content: "Treffen-Fenster: <Datum>. <N> Stimmen mit 5/5, Host: <Name>. Bestätigen / planen?" ## Technical sketch (for the design phase) - Question schema additions: `question.type = "wann-treffen"`, plus `config = { window_weeks: int, min_yes_count: int, min_yes_score: int (default 5), require_host: bool, alert_channels: [...] }`. - Response schema: extra fields `availability_score: 1..5 | null`, `host_capable: bool | null`, indexed by `(question_id, respondent_id, day)`. - Threshold-evaluation job: trigger on every response insert. Compute the threshold per day, fire alert if just-crossed (state transition). - Anti-spam: max 1 alert per day per question (idempotency on `(question_id, day)`). - Group registry: a "respondent group" concept — m defines once "Viva-Jungs = phone-A + phone-B + phone-C + …", question references the group, alerts route to that group's WA chat ID. ## Open design questions 1. **Standing vs. cyclic**: standing window (rolling 8 weeks always visible) or cyclic ("we play monthly, vote on next month")? m's voice suggests standing. 2. **Anonymity in counts**: voters see "3/4 with 5" but do they see WHO voted what? Probably yes within the friends group, but worth confirming. 3. **Re-trigger when a previously-alerted day gets a 4th '5'**: re-fire? Or only first crossing? 4. **Cancellation**: m wants to cancel a day after alerting (e.g. host got sick) — separate "cancel"-flow, removes the day from the standing window for some weeks? 5. **Voter authentication**: magic-link per phone? Open-link with name input? OAuth? Lightweight is preferred for friends. 6. **Question-pinning by m**: should this question type live alongside other fdbck question types, or get its own surface (a "/treffen" page)? 7. **Recurring rules**: m defines "we play roughly weekly" → system pre-fills the grid with optimistic candidates? Or pure manual day-by-day? ## Out of scope (this issue) - Implementation - Other group-coordination types (out-of-fdbck — not the home for general scheduling) - Calendar integration (CalDAV write on threshold) — nice-to-have, separate phase ## Workflow Park-only. When m wants to pursue: 1. **Inventor** designs the voter UX + answers Open Questions, drafts the schema additions 2. **Coder stage 1**: question type, response schema, voter UI, threshold computation 3. **Coder stage 2**: alert-channel adapters (WA group first, then PWA push) 4. **Coder stage 3**: standing-window mechanics + anti-re-fire idempotency 5. **Optional stage 4**: CalDAV-write on confirmed day, RSVP follow-through ## Refs - m's voice via PWA 2026-05-09 11:29 (parking + scoping request) - Existing `date-rating` question type as the closest sibling — extend, don't duplicate - WA group send: `wa.sh` / mai-whatsapp skill (group-message support needs verifying — file separate issue if missing) - Use case: m's "Viva-Jungs" friend group, FIFA rounds — but the type is generalisable to any "friends pick a day" workflow
mAi commented 2026-05-09 09:32:35 +00:00
Author
Copy Link

Moved to m/mCompete#8 (m/mCompete#8) — m re-scoped 2 minutes after the original parking: this is fundamentally about autonomous event planning (host + participants + venue + result-logging), not generic feedback collection. Closing here.

Moved to m/mCompete#8 (https://mgit.msbls.de/m/mCompete/issues/8) — m re-scoped 2 minutes after the original parking: this is fundamentally about autonomous event planning (host + participants + venue + result-logging), not generic feedback collection. Closing here.
m closed this issue 2026-05-09 09:32:35 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/fdbck#5
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?