Refonte du système de votes de la roadmap (championnat mensuel) #116

New Issue

2026-07-14T11:44:56+02:00

ColinMaudry commented

2026-07-14 11:44:56 +02:00

(Migrated from github.com)

Refonte du mécanisme de vote de la roadmap. Spec complète :
docs/superpowers/specs/2026-07-14-refonte-votes-roadmap-design.md

Résumé

Championnat mensuel : le classement d'une feature n'agrège que ses votes du mois courant (fenêtre glissante sur created_at, Europe/Paris). Pas de cron, pas de reset — la fenêtre glisse. Corrige le comptage cumulatif à vie qui avantageait les vieilles features.
Recharge des votes le lundi : 3 votes rechargés chaque lundi 00h00 (Europe/Paris), sans report. Cadence globale remplaçant le timer glissant par-user. C'est le rythme hebdo qui favorise les utilisateurs fréquents.
Pas de cap par feature : concentration libre. Le risque « qu'un seul fasse basculer une feature » est neutralisé non par un cap (demi-mesure à faible effectif) mais par une précondition de déploiement.
Précondition de déploiement : ne pas mettre en prod tant que le nombre d'utilisateurs votant n'a pas dépassé un seuil (à fixer).
Horloges découplées : le passage de saison (1er) ne touche pas le solde ; ballot figé par convention (re-labelliser GitHub seulement au 1er).

Impact technique

Aucune migration de schéma. Logique seulement : vote_counts (fenêtre saison) dans src/roadmap/db.py, credit_pending/next_recharge_at (lundi calendaire) dans src/subscriptions/db.py, retouches UI, tests. spend_vote/record_vote/bouton « + »/source GitHub inchangés.

Points différés

Valeur du seuil de déploiement · snapshot du ballot pour figer strictement l'appartenance · signalétique utilisateur · cap par feature en durcissement futur si besoin.

🤖 Generated with Claude Code

Refonte du mécanisme de vote de la roadmap. Spec complète : [`docs/superpowers/specs/2026-07-14-refonte-votes-roadmap-design.md`](https://github.com/ColinMaudry/colibre/blob/dev/docs/superpowers/specs/2026-07-14-refonte-votes-roadmap-design.md) ## Résumé - **Championnat mensuel** : le classement d'une feature n'agrège que ses votes du **mois courant** (fenêtre glissante sur `created_at`, Europe/Paris). Pas de cron, pas de reset — la fenêtre glisse. Corrige le comptage cumulatif à vie qui avantageait les vieilles features. - **Recharge des votes le lundi** : 3 votes rechargés chaque lundi 00h00 (Europe/Paris), **sans report**. Cadence globale remplaçant le timer glissant par-user. C'est le rythme hebdo qui favorise les utilisateurs fréquents. - **Pas de cap par feature** : concentration libre. Le risque « qu'un seul fasse basculer une feature » est neutralisé non par un cap (demi-mesure à faible effectif) mais par une **précondition de déploiement**. - **Précondition de déploiement** : ne pas mettre en prod tant que le nombre d'utilisateurs votant n'a pas dépassé un seuil (à fixer). - **Horloges découplées** : le passage de saison (1er) ne touche pas le solde ; ballot figé par convention (re-labelliser GitHub seulement au 1er). ## Impact technique Aucune migration de schéma. Logique seulement : `vote_counts` (fenêtre saison) dans `src/roadmap/db.py`, `credit_pending`/`next_recharge_at` (lundi calendaire) dans `src/subscriptions/db.py`, retouches UI, tests. `spend_vote`/`record_vote`/bouton « + »/source GitHub inchangés. ## Points différés Valeur du seuil de déploiement · snapshot du ballot pour figer strictement l'appartenance · signalétique utilisateur · cap par feature en durcissement futur si besoin. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: colin/colibre#116