decision/docs/content/user/4.decisions.md

title, description

title	description
Decisions	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 pour plus de details.