Stakeholder Feedback & Feature Requests
En bref
A structured intake funnel for feature requests, improvement suggestions and bug reports from any of the platform's ~123 stakeholder types: a six-section public form with live Markdown preview, generating task-specs that drop directly into the product backlog, plus email confirmation, MongoDB-backed audit trail, multilayer anti-spam controls and full WCAG 2.1 AA accessibility across four launch languages.
Comment ça fonctionne
The public form at /feature-request is a six-section wizard — contact, stakeholder category, request details, acceptance criteria, attachments, priority — with a live Markdown preview rendering the generated task-spec next to the form so submitters can see exactly what the product team will receive. The category dropdown lists 11 stakeholder categories (federation officer, club admin, player, umpire, sponsor, ...) with dynamic subcategory filtering, and the related-feature picker is a searchable dropdown over the live feature inventory of 1 250+ items so requests can be linked to existing capabilities rather than filed in isolation.
On submit the backend assembles a Markdown file in the standard task-spec format used by the backlog runner: front-matter with stakeholder metadata, body sections matching the form, acceptance criteria as a checklist. The file is stored on disk under a generated task ID and a feature_requests document is written to MongoDB carrying the same metadata plus revision tracking and soft-delete. Two emails go out via Azure Communication Services — a notification to the support address with the generated spec attached, and a confirmation to the submitter with their reference number. Admin triage runs through REST endpoints that list, fetch detail, change status and soft-delete; the same audit trail captures every state change.
Three spam controls layer over the form: a hidden honeypot field that bots tend to fill, a Cloudflare Turnstile CAPTCHA token verified server-side, and a per-IP rate limit of five submissions per hour. The form ships in English, French, Spanish and Swedish with the generated Markdown always normalised to English so the product team has a single working language. Accessibility is WCAG 2.1 AA — labelled fields, aria attributes, keyboard navigation, contrast compliance — and SEO comes from per-language meta tags, a JSON-LD ContactPage schema and sitemap inclusion so search engines surface the form for users hunting for a feedback channel.
Capacités clés
- Six-section structured form with live Markdown preview of the generated task-spec
- Stakeholder category and subcategory selection across 11 categories
- Searchable dropdown over 1 250+ existing features for related-feature linking
- Markdown task-spec generation in backlog runner format
- Email delivery via Azure Communication Services with submitter confirmation
- MongoDB storage with revision tracking and soft-delete plus admin triage endpoints
- Honeypot, Cloudflare Turnstile and 5/h IP rate limit anti-spam stack
- Multilingual form (en/fr/es/sv) with normalised English output and WCAG 2.1 AA compliance
En pratique
A regional umpire keeps running into a missing feature: the umpire dashboard does not show pending availability requests in chronological order. He opens petanque.life/feature-request in Swedish, picks Stakeholder → Officials → Umpire, types the problem in the request-details section, lists three acceptance criteria, attaches a screenshot. The right-hand pane shows the formatted Markdown spec live as he types.
He submits; Turnstile verifies in the background, an email lands within seconds confirming reference FR-2026-04-178. The product owner sees the generated spec in the triage queue the next morning, links it to F05.04 already in the inventory, and accepts it into the backlog with a single status change.
Fonctionnalités de ce sous-système
20| ID | Status | Fonctionnalités |
|---|---|---|
| F16.07.01 | Livré | Structured feature request form with 6 sections (contact, stakeholder category, request details, acceptance criteria, attachments, priority) ✅ PL-F1607a |
| F16.07.02 | Livré | Live Markdown preview — real-time rendering of generated task-spec alongside the form ✅ PL-F1607a |
| F16.07.03 | Livré | Stakeholder category/subcategory selection — 11 categories with dynamic subcategory filtering ✅ PL-F1607a |
| F16.07.04 | Livré | Feature inventory integration — searchable dropdown over 1 250+ features for "related feature" linking ✅ PL-F1607a |
| F16.07.05 | Livré | Markdown task-spec generation — structured .md file following backlog runner format ✅ PL-F1607a |
| F16.07.06 | Livré | Email delivery via Azure Communication Services — support notification + stakeholder confirmation ✅ PL-F1607a |
| F16.07.07 | Livré | MongoDB storage with audit trail — feature_requests collection with revision tracking and soft-delete ✅ PL-F1607b |
| F16.07.08 | Livré | Admin triage endpoints — list, detail, status update, soft-delete via REST API ✅ PL-F1607b |
| F16.07.09 | Livré | Anti-spam protection — honeypot field, Cloudflare Turnstile CAPTCHA, rate limiting (5/h per IP) ✅ PL-F1607b |
| F16.07.10 | Livré | i18n — form available in EN, FR, ES, SV; generated Markdown always in English ✅ PL-F1607b |
| F16.07.11 | Livré | WCAG 2.1 AA accessibility — labelled fields, aria attributes, keyboard navigation, contrast compliance ✅ PL-F1607b |
| F16.07.12 | Livré | SEO — per-language meta tags, JSON-LD ContactPage schema, sitemap inclusion ✅ PL-F1607b |
| F16.08.01 | Livré | Score entry offline med WatermelonDB — WatermelonDB-compatible pull/push sync protocol with delta timestamps, per-table change tracking (match_scores, mene_scores), idempotent push with version-based conflict detection ✅ PL-F1608a |
| F16.08.02 | Livré | License-verifiering med cachad data — HMAC-SHA256 integrity hash on license bundles, incremental delta download via previous_hash, server-side license verification endpoint ✅ PL-F1608a |
| F16.08.03 | Livré | Sync-status indikator — sync session creation/completion, per-type progress tracking with percentage, pending/completed/failed/conflict counts, enhanced UI progress bar and per-type breakdown ✅ PL-F1608a |
| F16.08.04 | Livré | Konflikthantering vid sync (last-write-wins) — configurable per-resource-type policies with auto/manual field classification, LWW/server-wins/client-wins/manual strategies, full audit trail via ConflictAuditEntry ✅ PL-F1608a |
| F16.08.05 | Livré | Bakgrundssync vid wifi-anslutning — per-user wifi-only preference (BackgroundSyncPreference), auto-sync on reconnect, periodic sync interval, quiet hours, sync trigger evaluation based on connection type and preferences ✅ PL-F1608b |
| F16.08.06 | Livré | Offline-fönster max 7 dagar — configurable max offline window (default 7 days), 12h grace period, 5-day warning threshold, per-data-type validation, automatic invalidation of expired offline data ✅ PL-F1608b |
| F16.08.07 | Livré | Selective sync (bara aktuell tävling) — per-user competition scope (SelectiveSyncScope), sync only selected competitions, estimated data size calculation, automatic inclusion of requested competition in scope ✅ PL-F1608b |
| F16.08.08 | Livré | Bandwidth-medveten sync (3G vs wifi) — per-connection-type profiles (wifi/5G/4G/3G/2G/ethernet), adaptive batch sizing based on effective bandwidth and signal strength, image sync control, compression, throttling ✅ PL-F1608b |
Sous-systèmes liés
Parties prenantes qui ont besoin de ce sous-système
Apparaît dans 2 analyses de parties prenantes