Vote: Engagement comité tech 2.0.0-fr

Contexte (indépendant du vote)

Avec la V2, un comité technique est mis en place pour :

  1. auditer le code blockchain destiné à être mis en production
  2. vérifier l’absence de code malveillant
  3. vérifier que le code produit bien les évolutions annoncées
  4. mettre en production uniquement les évolutions au service de la communauté

Objet du vote

Pour réduire les risques d’abus des pouvoirs associés à cette fonction et mieux permettre de faire évoluer les processus liés à cette dernière, nous avons créé un engagement comité technique minimaliste.

Il ne dit presque rien, si ce n’est comment faire évoluer l’engagement comité technique quand le besoin s’en fera sentir.
Vous en trouverez les termes précis en 1er commentaire.

Modalité de vote

  • S’il vous semble préférable d’avoir ce document comme première étape de garde-fou, c’est le moment de voter pour.
  • Si vous pensez qu’il vaut mieux commencer sans. C’est le moment de voter contre. (ou de coder une autre approche et de la faire adopter par le comité technique)

Nous vous proposons un système de vote unani-majoritaire via votre compte monnaie libre pour exprimer votre accord ou désaccord sur l’adoption de l’engagement comité technique.
Ouverture des votes : du 04 février au 06 mars 2026.

Listes des actions mises en oeuvre à l'issue du vote si la proposition est adoptée
  • Ajouter l’engagement des membres du comité technique au dépot charte/license (via merge request avec 1 validation minimum)
  • Vérifier que chaque membre du comité technique accepte l’engagement.

Concrètement, pour voter entre le 04/02/2026 et le 06/03/2026, envoyez 0.01 Ǧ1 depuis votre compte membre vers :

  • Mieux que rien (POUR/OUI) : 6CFXPiv1EEbZu64bD4CpDUp6LbaE4K61ssRhAtQai43Z:6ou

  • Pire que rien (CONTRE/NON) : 7s4kQuD3ZuxYrvCACAHF2DZz9u1ypwBZxKemLE83HSpu:E9P

Suivi des votes :

G1 vote view : Engagement comité technique v2.0.0

Infos techniques pour G1 Vote view

talk: 32960
mode: D30M50B.1G.2T.1

Merci pour votre implication !

4 « J'aime »
Texte intégral de l'engagement comité technique v2.0.0-fr

date: 2026-02-04
version: 2.0.0-fr

Engagement des membres du comité technique

Intention & enjeux

L’objectif est de garantir que la communauté G1 conserve sa souveraineté.

Pour le bon fonctionnement de la blockchain Duniter, un organe en charge de gérer certaines tâches est formalisé avec DuniterV2.
Il s’agit du comité technique dont la fonction est de :

  1. auditer le code blockchain destiné à être mis en production
  2. vérifier l’absence de code malveillant
  3. vérifier que le code produit bien les évolutions annoncées
  4. mettre en production uniquement les évolutions au service de la communauté

Pour que le pouvoir de mettre en production des évolutions reste sous la souveraineté de la communauté, il est essentiel qu’elle puisse définir les modalités du mandat fait aux membres du comité technique (les mandatés).
À savoir :

  • ce qu’on attend d’eux
  • les limites à ne pas franchir
  • comment s’obtient et se perd le mandat

À cet effet, chaque mandaté s’engage à ce qui suit :

Engagements

  • Respecter les règles décrites dans la version en vigueur de ce document
  • Démissionner en cas de désaccord avec les règles en vigueur
  • Voter le retrait du mandat à qui en enfreint visiblement les règles

Gouvernance pour modifier le présent document

Conditions d’adoption :
Vote à seuil unani-majoritaire (voir lexique) + une portion des mandatés

Formule de calcul du seuil :

 votesPour >= ceil⌈WotSize^0.1 + (0.5 + (1 - 0.5) × (1 - (TotalVotes/WotSize)^0.2)) × TotalVotes⌉ 
et
 votesCoTecPour >= ceil⌈CoTecSize^0.1⌉ 

Description du processus complet

Annexes

Contenu des annexes non contractuel, modifiable sans vote à des fins de clarification.

Entrer ou sortir du comité technique

Ceci n’est pas l’objet de l’engagement, mais une clarification du mécanisme technique actuel, qui n’a aucune prétention à perdurer ainsi, c’est juste l’implémentation actuelle.

Pour rejoindre le comité technique, ou le quitter (démission, exclusion…) un seul mécanisme actuellement :

  • 1 membre du comité technique propose une nouvelle composition du comité technique
  • 2/3 des membres du comité technique valident cette nouvelle composition (qu’elle inclue ou retire des membres)
  • 1 membre du comité technique clôture le vote une fois le seuil des 2/3 atteint, pour que la nouvelle composition prenne effet.

Techniquement, modifier ce fonctionnement implique qu’un dev implémente autre chose et que 2/3 des membres du comité technique valide le runtime-update proposés par le dev (ou peut-être que les forgerons installe le nécessaire si les changements dépassent ce qui a lieu en runtime).

1 « J'aime »

Pourquoi ne pas utiliser, comme pour tous votes “binaire”, l’item “Ne se prononce pas?

C’est un avis comme un autre, qui permet à tous de voter.

Personnellement, quelque soit mon avis, je ne participe pas à ce type de vote restrictif…

La modification de ce document ne passant pas par une proposition en blockchain (si ?), le seuil des 2/3 du comité ne s’applique pas dans ce cas, seulement le seuil |comité|^0.1 qui vaut toujours 2. Donc il n’y a pas de quorum, comment on s’assure que suffisamment de gens ont eu l’occasion de voter pour que le nombre de votes exprimés ait un sens ?

1 « J'aime »

Pour ne pas donner une illusion d’impact quand le processus d’arbitrage/comptage n’en tiens pas compte. Dit autrement : par honnêteté intellectuelle.

Je cherche à ce qu’il soit possible de faire évoluer les règles d’une manière fonctionnelle et ayant souvent des retours comme quoi je fait trops compliqué, j’essai de faire au plus simple. Une fois que la sécurité d’avoir un moyen de faire évoluer les règles est validé, y ajouter de la nuance et de la finesse, que ce soit avec du « ne se prononce pas » ou du jugement majoritaire, ou d’autres approche me parle, mais seulement si ça permet de faire mieux et pas de donner l’illusion de faire mieux tout en le réduisant à un vote binaire derrière (ce qui mènerais à un vote à 2 vitesse : ceux qui vote selon l’ergonomie mise en avant, et ceux qui analyse les mécanique derrière pour maximiser leur efficacité de vote au regard du système de vote en place)

3 « J'aime »

En effet. Le seuil de 2/3 s’applique pour les décisions on-chain produite par le comité technique.
Ici, il s’agit de valider un texte/engagement qui permet de réclamer des comptes au comité technique. L’idée n’est pas que ce soit le comité technique qui en décide (démocratiquement, ça me semble important que ce ne soit pas les détenteurs d’un pouvoir qui définisse les limites de ce pouvoir). Il me semble néanmoins utile que les modalités soit viable, donc qu’il existe des membres du comité technique qui l’approuve (mais pas besoin que ce soit une majorité). C’est la raison du seuil très faible :

Au contraire, le seuil d’adésion communautaire lui est bien plus élevé :

Vu sous forme de Quorum, il n’est pas si élevé (17 votes membres pour), mais il est élevé en taux d’adhésion à la proposition : Pour le moindre vote CONTRE, il faut beaucoup de votes POUR supplémentaire afin de surpasser le CONTRE. J’ai conçu cette approche afin d’éviter l’immobilisme, de ne rien pouvoir changer si trop peu sont actifs, tout en rendant simple de s’opposer à une proposition dangereuse. J’explique ça plus en détail ici :

Bonjour à toutes et tous,

Après relecture du texte d’engagement du Comité Technique (v2.0.0-fr), je clarifie ma position : je voterai pour. Initialement contre, je comprends que ce texte n’empêche pas le Comité Technique ni le fonctionnement de la blockchain, mais vise à encadrer son rôle, définir ses limites et formaliser ses règles, permettant ainsi à la communauté de garder le contrôle.

Le vote donne à la communauté le pouvoir de décider :

  • des modifications du document d’engagement,
  • du mandat et des règles du Comité Technique.

Sans adoption, le comité continuera d’exister, mais sans cadre clair. L’objectif est de garantir que les développeurs ne soient pas les seuls décideurs et que leur travail respecte la Monnaie Libre.

La communication autour de ce vote aurait pu être plus explicite ; j’espère que cette synthèse aidera à mieux comprendre l’enjeu. Il est important que la communauté garde un cadre clair pour exercer sa souveraineté. Je vous invite à participer au vote avant le 06/03/2026 à 21h00.

Faite circuler l’info svp :folded_hands:

Texte intégral de l’engagement Comité Technique v2.0.0-fr ici : Vote: Engagement comité tech 2.0.0-fr - #2 par 1000i100

Pour voter c’est par ici : Ğ1 vote view

Liste des membres du Comité Technique ici : Ğ1 vote view

5 « J'aime »

@AlphaCentauri @AnimeMaxime @chrisaiki @ClaireGason @Cywil @Damery @Diane @duoduo @ENO @GC59avesnois @hypericum @Jerome035 @LaFeeClochette @MArie.Potterre @Ninon82 @OlivierMichel @PascalEnden @Poesy @Pol @solaiye @xavislow @Yvv @zap @C-Bill @flassave @Hugo-Trentesaux @ManUtopiK @RutenRolf @sfouludo @yann

Merci Paola pour cette synthèse ! En effet ça m’apporte de la clarté et m’aide à orienter mon vote, là où j’ai eu de la difficulté à vraiment saisir l’idée de ce vote.

@1000i100 Merci pour le site G1 Vote View ! Je ne le connaissais pas, il explique avec beaucoup de clarté différents mécanismes de votation, c’est très bien fait. Seule petite suggestion, attention sur certains mots leur couleur est la même que l’arrière-plan, ce qui les rend illisibles (on est obligés de les surligner en sélectionnant avec la souris pour les voir).

3 « J'aime »

Merci à toi pour tout ce que tu/vous faites et pour aider à que les informations techniques soient diffusées, surtout avec l’arrivée de la V2 le 08.03.26 :folded_hands:

1 « J'aime »

Texte intégral de l’engagement comité technique v2.0.0-fr (lecture directe pour ceux pour qui l’informatique est un “autre monde”)


date: 2026-02-04
version: 2.0.0-fr

Engagement des membres du comité technique

Intention & enjeux

L’objectif est de garantir que la communauté G1 conserve sa souveraineté.

Pour le bon fonctionnement de la blockchain Duniter, un organe en charge de gérer certaines tâches est formalisé avec DuniterV2.
Il s’agit du comité technique dont la fonction est de :

  1. auditer le code blockchain destiné à être mis en production
  2. vérifier l’absence de code malveillant
  3. vérifier que le code produit bien les évolutions annoncées
  4. mettre en production uniquement les évolutions au service de la communauté

Pour que le pouvoir de mettre en production des évolutions reste sous la souveraineté de la communauté, il est essentiel qu’elle puisse définir les modalités du mandat fait aux membres du comité technique (les mandatés).
À savoir :

  • ce qu’on attend d’eux
  • les limites à ne pas franchir
  • comment s’obtient et se perd le mandat

À cet effet, chaque mandaté s’engage à ce qui suit :

Engagements

  • Respecter les règles décrites dans la version en vigueur de ce document
  • Démissionner en cas de désaccord avec les règles en vigueur
  • Voter le retrait du mandat à qui en enfreint visiblement les règles

Gouvernance pour modifier le présent document

Conditions d’adoption :
Vote à seuil unani-majoritaire (voir lexique) + une portion des mandatés

Formule de calcul du seuil :

 votesPour >= ceil⌈WotSize^0.1 + (0.5 + (1 - 0.5) × (1 - (TotalVotes/WotSize)^0.2)) × TotalVotes⌉ 
et
 votesCoTecPour >= ceil⌈CoTecSize^0.1⌉ 

Description du processus complet

Annexes

Contenu des annexes non contractuel, modifiable sans vote à des fins de clarification.

Entrer ou sortir du comité technique

Ceci n’est pas l’objet de l’engagement, mais une clarification du mécanisme technique actuel, qui n’a aucune prétention à perdurer ainsi, c’est juste l’implémentation actuelle.

Pour rejoindre le comité technique, ou le quitter (démission, exclusion…) un seul mécanisme actuellement :

  • 1 membre du comité technique propose une nouvelle composition du comité technique
  • 2/3 des membres du comité technique valident cette nouvelle composition (qu’elle inclue ou retire des membres)
  • 1 membre du comité technique clôture le vote une fois le seuil des 2/3 atteint, pour que la nouvelle composition prenne effet.

Techniquement, modifier ce fonctionnement implique qu’un dev implémente autre chose et que 2/3 des membres du comité technique valide le runtime-update proposés par le dev (ou peut-être que les forgerons installe le nécessaire si les changements dépassent ce qui a lieu en runtime).

3 « J'aime »

Salut à tous !

Alors, j’ai bien lu toute la discussion, notamment la clarification de Italpaola, mais je ne comprends toujours pas trop l’intérêt de voter pour un texte qui, d’après ma compréhension, dit “Il faudrait penser un jour à créer un texte qui défini les règles à suivre pour les personnes faisant partie du comité technique”.
Parce que là, le seul truc qui est dit c’est que les membres du comité technique s’engagent à respecter les modalités du mandat, qui n’existent pas.

Est-ce qu’il n’aurait pas été plus direct de définir un premier mandat définissant les modalités de participation des membres du comité technique ?

Parce que tant que ce document n’existera pas, le vote pour l’engagement comité tech n’aura pas de sens…

Merci pour vos éclaircissements ! :folded_hands:

2 « J'aime »

Bonjour, le texte du mandat est ici (cliquer sur la flèche pour le déplier)
Mais j’entends parfaitement qu’il n’est pas de lecture aisée (moi la première rien compris au début)

Si si, le mandat indique clairement :
Le comité technique existe pour contrôler et sécuriser les mises à jour de la blockchain afin de préserver la souveraineté de la communauté G1.

Il doit :

*** Auditer le code avant mise en production**
*** Vérifier l’absence de code malveillant**
*** Vérifier que le code correspond aux évolutions annoncées**
*** Mettre en production uniquement ce qui sert la communauté**

Ses membres doivent :

*** Respecter les règles du mandat**
*** Démissionner s’ils ne sont plus d’accord**
*** Voter l’exclusion de tout membre qui enfreint clairement les règles**

Le mandat peut être modifié par un vote exigeant de la communauté, avec une participation minimale du comité.

L’entrée ou la sortie d’un membre nécessite actuellement l’accord des 2/3 du comité.

En gros ce mandat indique clairement que le Comité Technique :

  • :cross_mark: ne peut pas mettre en production du code non annoncé (changement TRM par exemple)
  • :cross_mark: ne peut pas ajouter des fonctionnalités cachées (modification calcul DU par exemple, ou écarter les membres critiques et fonctionner par cooptation)
  • :cross_mark: ne peut pas orienter le projet contre l’intérêt de la communauté (favoriser certains membres du comité par exemple)
  • :cross_mark: ne peut pas ignorer le cadre du mandat
    En conclusion ce mandat rappelle au CT qu’il est délégué et prévoit des mécanismes d’entrée/sortie

Dans la réalité le CT existe depuis le début de la rédaction du code de DUNITERV2 : il est composé des membres développeurs actifs, les devs qui ont mis en place et gèrent la GTEST. C’est ce même CT qui est en V2

La discussion préalable à la rédaction de cet engagement/charte était ici

3 « J'aime »