---
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.