3cb1754592
Backend: 7 nouveaux endpoints (advance, assign, revoke, create-vote-session), services enrichis avec creation de sessions de vote, assignation de mandataire et revocation. 35 nouveaux tests (104 total). Frontend: store mandates, page cadrage decisions, detail mandats, composants DecisionWorkflow, DecisionCadrage, DecisionCard, MandateTimeline, MandateCard. Documentation mise a jour. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
143 lines
8.7 KiB
Markdown
143 lines
8.7 KiB
Markdown
---
|
|
title: Decisions
|
|
description: Guide des processus decisionnels sur Glibredecision
|
|
---
|
|
|
|
# Decisions
|
|
|
|
## Principe
|
|
|
|
Une decision est un processus structure qui conduit a un choix collectif. Chaque decision suit un ensemble d'etapes definies, de la qualification a l'execution. Le systeme garantit la tracabilite de chaque etape et l'integration avec le systeme de vote WoT.
|
|
|
|
## Types de decisions
|
|
|
|
| Type | Description | Cas d'usage |
|
|
| ------------------ | ------------------------------------------------------ | -------------------------------------------------------- |
|
|
| `runtime_upgrade` | Mise a jour du runtime de la blockchain Duniter | Upgrade du reseau, changement de parametres consensus |
|
|
| `document_change` | Modification d'un item de document de reference | Amendement de la Licence G1, modification d'un engagement |
|
|
| `mandate_vote` | Vote pour l'attribution d'un mandat | Election d'un membre du Comite Technique |
|
|
| `parameter_change` | Modification de parametres systeme | Changement de duree de vote, seuil de majorite |
|
|
| `custom` | Decision personnalisee | Tout autre type de decision collective |
|
|
|
|
## Cycle de vie d'une decision
|
|
|
|
Une decision progresse a travers six statuts successifs :
|
|
|
|
```
|
|
Brouillon --> Qualification --> Examen --> Vote --> Executee --> Cloturee
|
|
|
|
|
+--> Rejetee (si le vote echoue)
|
|
```
|
|
|
|
| Statut | Description |
|
|
| ----------------- | ---------------------------------------------------------------- |
|
|
| `draft` | Brouillon initial. La decision est en cours de redaction et peut etre modifiee librement ou supprimee. |
|
|
| `qualification` | Phase de verification. On s'assure que la proposition est recevable (forme, competence, pertinence). |
|
|
| `review` | Periode d'examen et de discussion par la communaute. Les membres peuvent commenter et suggerer des amendements. |
|
|
| `voting` | Session de vote formelle. Le seuil de validation WoT s'applique. Une session de vote est creee et liee a l'etape correspondante. |
|
|
| `executed` | La decision a ete adoptee et est en cours de mise en oeuvre. |
|
|
| `closed` | La decision est cloturee. Le resultat est archive dans le sanctuaire. |
|
|
|
|
Si le vote echoue (seuil non atteint), la decision passe en statut "rejetee" et ne peut plus avancer.
|
|
|
|
## Etapes d'une decision (decision_steps)
|
|
|
|
Chaque decision est composee d'etapes ordonnees qui definissent le workflow concret. Les types d'etapes disponibles sont :
|
|
|
|
| Type d'etape | Description |
|
|
| --------------- | ---------------------------------------------------------------- |
|
|
| `qualification` | Verification que la proposition est recevable |
|
|
| `review` | Periode d'examen et de discussion par la communaute |
|
|
| `vote` | Session de vote formelle avec seuil de validation WoT |
|
|
| `execution` | Mise en oeuvre de la decision adoptee |
|
|
| `reporting` | Compte-rendu de l'execution et archivage des resultats |
|
|
|
|
Chaque etape possede un statut individuel :
|
|
|
|
| Statut | Description |
|
|
| ----------- | ---------------------------------------------------------- |
|
|
| `pending` | L'etape n'a pas encore commence |
|
|
| `active` | L'etape est en cours |
|
|
| `completed` | L'etape est terminee avec succes |
|
|
| `skipped` | L'etape a ete ignoree (non applicable pour ce type de decision) |
|
|
|
|
## Comment le workflow avance
|
|
|
|
Le workflow d'une decision avance via l'action **"Avancer"** (endpoint `POST /decisions/{id}/advance`). A chaque appel :
|
|
|
|
1. **S'il y a une etape active** : elle est marquee `completed`, et la prochaine etape `pending` est activee.
|
|
2. **S'il n'y a pas d'etape active** : la premiere etape `pending` est activee. Si la decision est en `draft`, elle passe automatiquement en `qualification`.
|
|
3. **Si toutes les etapes sont terminees** : le statut global de la decision avance au statut suivant dans le cycle de vie.
|
|
|
|
Ce mecanisme garantit que les etapes sont parcourues dans l'ordre defini (`step_order`) et qu'aucune etape ne peut etre sautee involontairement.
|
|
|
|
## Creation d'une session de vote
|
|
|
|
Quand une etape de type `vote` est active, il faut creer une session de vote liee a cette etape. Cela se fait via l'action **"Creer une session de vote"** (endpoint `POST /decisions/{id}/steps/{step_id}/create-vote-session`).
|
|
|
|
La session de vote :
|
|
- Est automatiquement liee au protocole de vote de la decision
|
|
- Prend un snapshot des tailles WoT, Smith et TechComm au moment de la creation
|
|
- Calcule la date de fin en fonction de la duree definie dans la formule du protocole
|
|
- Est rattachee a l'etape via le champ `vote_session_id`
|
|
|
|
Une fois la session de vote cloturee (manuellement ou par expiration), l'etape peut etre completee et le workflow peut avancer.
|
|
|
|
## Creer une decision
|
|
|
|
Les membres authentifies peuvent creer une decision :
|
|
|
|
1. Cliquez sur **Nouvelle decision**.
|
|
2. Renseignez le **titre** : un intitule clair et concis de la proposition.
|
|
3. Renseignez la **description** : le detail de ce qui est propose.
|
|
4. Renseignez le **contexte** : pourquoi cette decision est necessaire (cadrage).
|
|
5. Choisissez le **type de decision** : `runtime_upgrade`, `document_change`, `mandate_vote`, `parameter_change` ou `custom`.
|
|
6. Selectionnez un **protocole de vote** qui definit les parametres de la formule de seuil WoT (duree, majorite, gradient, criteres Smith/TechComm).
|
|
7. **Ajoutez les etapes** necessaires dans l'ordre souhaite (qualification, examen, vote, execution, reporting).
|
|
8. Soumettez. La decision est creee en statut `draft`.
|
|
9. Utilisez l'action **"Avancer"** pour lancer la premiere etape et demarrer le processus.
|
|
|
|
## Supprimer une decision
|
|
|
|
Les decisions en statut `draft` peuvent etre supprimees via l'action **"Supprimer"** (endpoint `DELETE /decisions/{id}`). Une fois le processus demarre (statut `qualification` ou au-dela), la decision reste dans le systeme pour tracabilite.
|
|
|
|
## Suivre une decision
|
|
|
|
1. Rendez-vous dans la section **Decisions**.
|
|
2. Filtrez par type ou statut pour trouver la decision qui vous interesse.
|
|
3. La page de detail affiche toutes les etapes avec leur statut (en attente, active, terminee, ignoree).
|
|
4. Si une etape de vote est active et qu'une session de vote est ouverte, vous pouvez voter directement depuis la page de decision.
|
|
5. Le resultat du vote (seuil, participation, criteres Smith/TechComm) est affiche en temps reel.
|
|
|
|
## Exemple : Processus de Runtime Upgrade
|
|
|
|
Un Runtime Upgrade suit un processus en 5 etapes strictement definies :
|
|
|
|
```
|
|
1. Qualification -> Verification technique par le Comite Technique
|
|
2. Examen -> Review du code par les forgerons, discussion communautaire
|
|
3. Vote -> Vote WoT avec criteres Smith et TechComm obligatoires
|
|
4. Execution -> Deploiement du runtime sur le reseau
|
|
5. Reporting -> Compte-rendu post-deploiement, verification de stabilite
|
|
```
|
|
|
|
**Deroulement concret :**
|
|
|
|
1. Un membre cree une decision de type `runtime_upgrade` avec le contexte technique (version, changelog, hash du wasm).
|
|
2. Il ajoute les 5 etapes dans l'ordre.
|
|
3. Il avance la decision : l'etape "Qualification" devient active. Le Comite Technique verifie le build.
|
|
4. Une fois la qualification validee, il avance : l'etape "Examen" devient active. Les forgerons reviewent le code.
|
|
5. Il avance : l'etape "Vote" devient active. Une session de vote est creee avec le protocole incluant les criteres Smith et TechComm.
|
|
6. Les membres votent. Le seuil WoT s'applique avec inertie. Les criteres Smith (`ceil(SmithWotSize^S)`) et TechComm (`ceil(CoTecSize^T)`) doivent aussi etre atteints.
|
|
7. Si adopte, il avance : l'etape "Execution" devient active. Le runtime est deploye.
|
|
8. Il avance : l'etape "Reporting" devient active. Le compte-rendu est redige.
|
|
9. Il avance une derniere fois : la decision passe en statut `closed`.
|
|
|
|
## Lien avec les documents
|
|
|
|
Quand une decision de type `document_change` est adoptee, la modification proposee est automatiquement appliquee a l'item du document concerne. L'ancienne version est conservee dans l'historique des versions (`item_versions`).
|
|
|
|
## Lien avec les mandats
|
|
|
|
Les decisions de type `mandate_vote` sont utilisees pour les elections de mandats. La decision contient une etape de vote qui determine le resultat de l'election. Voir la section [Mandats](/user/mandates) pour plus de details.
|