Proposition : Licence Ğ1 - v0.3.0

Toile de Confiance Ğ1 Modifications de la licence
1

Proposition : Licence Ğ1 - v0.3.0

Notre proposition de Charte 1.0 était une refonte changeant beaucoup de choses d’un coup. Bien qu’elle ait reçu davantage de votes d’approbation que d’opposition, au regard du mode de vote que nous avons proposé, qui vise à se rapprocher du consensus, elle n’a pas été retenue.

Voici une proposition se limitant à un seul aspect :

Définir un processus de modificiation pour faire évoluer le document.

Par rapport à la licence v0.2.9 les seuls changements sont :
Le numéro de version : v0.2.9 → v0.3.0
La date de dernière modification : 2021-04-20 21:00 → 2025-02-11 21:30
Et en fin de document est ajouté le processus de modification que nous vous proposons d’adopter.

Pour voter pour l’adoption de cette proposition, avec votre compte membre, allez faire une transaction vers ce compte :
7NiCpGSteBvdgsimsyLZFhGibCz9sk96dTz4CdRAcK6A:BJc

Pour voter contre cette proposition, et conserver la [version actuelle] avec votre compte membre, allez faire une transaction vers ce compte :
3tQNDZ1jdhv8YE5d2Pov5vuxUWFAR1M4X3fYwQZ4KhLp:Gd8

Voici le « diff » de notre proposition, soit la liste des changements par rapport à la v0.2.9 au caractère près :

Texte intégral de la proposition :

Licence Ğ1 - v0.3.0
===================

:Date: 2017-04-04 12:59
:Modified: 2025-02-11 21:30

**Licence de la monnaie et engagement de responsabilité.**

Toute opération de certification d'un nouveau membre de la monnaie Ğ1 doit préalablement s'accompagner de la transmission de cette licence de la monnaie Ğ1 dont le certificateur doit s'assurer qu'elle a été étudiée, comprise et acceptée par la personne qui sera certifiée.

Tout événement de rencontre concernant la Ğ1 devrait s'accompagner de la transmission de cette licence, qui peut être lue à haute voix, et transmise par tout moyen.

Toile de confiance Ğ1 (TdC Ğ1)
------------------------------

**Avertissement :** Certifier n'est pas uniquement s'assurer que vous avez rencontré la personne, c'est assurer à la communauté Ğ1 que vous connaissez suffisamment bien la personne que vous vous apprêtez à certifier et que vous saurez ainsi la contacter facilement, et être en mesure de repérer un double compte effectué par une personne certifiée par vous-même, ou d'autres types de problèmes (disparition…), en effectuant des recoupements qui permettront de révéler le problème le cas échéant.

**Conseils fortement recommandés**

Bien connaître une personne suppose que vous êtes en mesure de la contacter par plusieurs moyens différents (physique, électronique, autre…) mais aussi que vous connaissez aussi plusieurs personnes qui la connaissent tout aussi bien et sont donc aussi en mesure de la contacter de même. Notamment si vous ne connaissez pas bien aucun de ses autres certificateurs c'est une indication forte que vous ne connaissez pas bien la personne et une certification de ce type déclenche une alerte vers toute la communauté Ğ1. En cas de connaissance insuffisante il convient de ne surtout pas certifier.

Ne certifiez jamais seul, mais accompagné d'au moins un autre membre de la TdC Ğ1 afin d'éviter toute erreur de manipulation. En cas d'erreur, prévenez immédiatement d'autres membres de la TdC Ğ1.

Avant toute certification, assurez-vous de vérifier si son compte (qu'il soit en cours de validation ou déjà membre) a déjà reçu une ou plusieurs certifications. Le cas échéant demandez des informations pour entrer en contact avec ses autres certificateurs afin de vérifier ensemble que vous connaissez bien la personne concernée par la création du nouveau compte, ainsi que la clé publique correspondante.

Vérifiez que le futur certifié maîtrise bien son compte : un bon moyen de vérifier cela est de transférer quelques Ğ1 vers le compte cible, et de demander ensuite un renvoi vers votre propre compte, cela assure de la bonne maîtrise par le futur certifié de sa clé privée.

Vérifiez que vos contacts ont bien étudié et compris la licence Ğ1 à jour.

Si vous vous rendez compte qu'un certificateur effectif ou potentiel du compte concerné ne connaît pas la personne concernée, alertez immédiatement des experts du sujet au sein de vos connaissances de la TdC Ğ1, afin que la procédure de validation soit vérifiée par la TdC Ğ1.

Lorsque vous êtes membre de la TdC Ğ1 et que vous vous apprêtez à certifier un nouveau compte :


**Vous êtes vous assuré :**

1°) De suffisamment bien connaître (pas seulement de la connaître "de visu") la personne qui déclare gérer cette clé publique (nouveau compte). Voir les conseils fortement recommandés ci-dessus pour s'assurer de "bien connaître".

2°) D'avoir personnellement vérifié avec elle qu'il s'agit bien de cette clé publique que vous vous apprêtez à certifier (voir conseils ci-dessus).

3°) D'avoir bien vérifié avec la personne concernée qu'elle a bien généré son document Duniter de révocation de compte qui lui permettra le cas échéant de pouvoir désactiver son statut de membre (cas d'un vol de compte, d'un changement de ID, d'un compte créé à tort etc.).

4a°) De rencontrer la personne physiquement pour vous assurer que c'est bien elle que vous connaissez bien et qui gère cette clé publique.

4b°) Ou bien de vérifier à distance le lien personne / clé publique en contactant la personne par plusieurs moyens de communication différents, comme courrier papier + réseau social + forum + mail + vidéo conférence + téléphone (reconnaître la voix). Car si l'on peut pirater un compte mail ou un compte forum, il sera bien plus difficile d'imaginer pirater quatre moyens de communication distincts, et imiter l'apparence (vidéo) ainsi que la voix de la personne en plus.

Le 4a°) restant toutefois préférable au 4b°), tandis que les points 1°) 2°) et 3°) sont préalablement indispensables.

**Règles abrégées de la TdC :**

Chaque membre a un stock de 100 certifications possibles, qu'il ne peut émettre qu'au rythme de 1 certification / 5 jours.

Valable 2 mois, une certification pour un nouveau membre n'est définitivement adoptée que si le certifié possède au moins 4 autres certifications au bout de ces 2 mois, sinon le processus d'entrée devra être relancé.

Pour devenir un nouveau membre de la TdC Ğ1 il faut donc obtenir 5 certifications et se trouver à une distance <= à 5 pas de 80% des membres référents de la TdC.

Un membre de la TdC Ğ1 est membre référent lorsqu'il a reçu et émis au moins Y[N] certifications où N est le nombre de membres de la TdC et Y[N] = plafond N^(1/5). Exemples :

* Pour 1024 < N ≤ 3125 on a Y[N] = 5
* Pour 7776 < N ≤ 16807 on a Y[N] = 7
* pour 59049 < N ≤ 100 000 on a Y[N] = 10

Une fois que le nouveau membre est partie prenante de la TdC Ğ1 ses certifications restent valables 2 ans.

Pour rester membre il faut renouveler son accord régulièrement avec sa clé privée (tous les 12 mois) et s'assurer d'avoir toujours au moins 5 certifications valides au delà des 2 ans.

Monnaie Ğ1
----------

Ğ1 se produit via un Dividende Universel (DU) pour tout être humain membre de la Toile de Confiance Ğ1, qui est de la forme :

* 1 DU par personne et par jour

**Code de la monnaie Ğ1**

Le montant en Ğ1 du DU est identique chaque jour jusqu'au prochain équinoxe où le DU sera alors réévalué selon la formule (avec 1 jour = 86 400 secondes) :

* DUjour(équinoxe suivant) = DUjour(équinoxe) + c² (M/N)(équinoxe) / (182,625 jours)

Avec comme paramètres :

* c = 4,88% / équinoxe
* DU(0) = 10,00 Ğ1

Et comme variables :

* *M* la masse monétaire totale à l'équinoxe
* *N* le nombre de membres à l'équinoxe

Logiciels Ğ1 et licence Ğ1
--------------------------

Les logiciels Ğ1 permettant aux utilisateurs de gérer leur utilisation de Ğ1 doivent transmettre cette licence avec le logiciel ainsi que l'ensemble des paramètres techniques de la monnaie Ğ1 et de la TdC Ğ1 qui sont inscrits dans le bloc 0 de Ğ1. Un logiciel qui ne remplirait pas ces obligations de la licence n'est pas compatible Ğ1.

Pour plus de précisions dans les détails techniques il est possible de consulter directement le code de Duniter qui est un logiciel libre ainsi que les données de la blockchain Ğ1 en les récupérant via une instance (ou nœud) Duniter Ğ1.

Plus d'informations sur le site de l'équipe Duniter https://www.duniter.org

Règles de modifications du présent document
-------------------------------------------

**Note introductive :**

Les personnes qui émettent des propositions, qui les soutiennent ou qui les votent doivent être membres de la TDC.

**Processus :**
1. Étape optionelle : Il est possible de partager son processus d'élaboration d'une proposition sur les plateformes de communication de la Ǧ1 (forum Monnaie Libre, forum Duniter, Télégram monnaie libre...).
2. Quand une proposition est considérée comme finalisée, il faut :
   - Créer un compte portefeuille pour chaque option : un "pour", un "contre".
   - Créer dans la catégorie dédiée du forum monnaie libre un sujet reprenant la proposition finale suivie des clefs publiques associées à chaque option.
   - Toute modification (réédition) du texte de la proposition finale entraine l'annulation du vote.
3. Les personnes votantes sont invitées à se prononcer par virement depuis leur compte membre vers le compte associé à leur choix de vote (le montant est ignoré). Si un compte membre émet plusieurs virements vers un même compte, un seul vote sera comptabilisé. Des virements du même compte membre vers les deux comptes ("pour" et "contre") sont considérés comme nuls.
5. 30 jours après publication de la proposition finale sur le forum les résultats du vote sont dépouillés :
    - Si la proposition a récolté au moins 20 votes/virements "pour" et aucun vote "contre", elle est adoptée.
    - Pour chaque vote "contre", 5 votes "pour" supplémentaires sont nécessaires pour que la proposition puisse être adoptée. (25 "pour" si 1 "contre", 30 "pour" si 2 "contre"...)
    - Si les conditions d'adoption ne sont pas réunies, la proposition est rejetée.

Une fois le vote clos, les Ǧ1 versées à l'occasion des votes peuvent être reversées ou non à une caisse (Mégadon, soutiens aux devs, remuniter...). Cela n'impacte pas la validité du vote.

Si vous avez besoin d'aide pour suivre ce processus de mise au vote, rendez-vous sur : [Comment mettre au vote une proposition d'évolution ?](https://forum.monnaie-libre.fr/t/a-propos-de-la-categorie-modifications-de-la-licence/31065)
9 « J'aime »
2

Pour mémoire, voici la proposition de charte 1.0 qui a été proposé précédemment.

Le choix de rester sur le même processus de modification que celui que nous (@Maaltir @Natha @pini et moi-même) avions proposé pour la charte 1.0 est motivé par les points suivants :

  • prendre en compte les retours, considérant qu’il ne fallait pas tout changer à la fois, mais voir un par un les points qui convenaient à la communauté.
  • Essayer de faire adopter en premier lieu un mode de prise de décision simple et fonctionnel, plutôt que de viser le processus parfait en intégrant toutes les suggestions directement.
  • Valider par l’expérience que ce mode de vote permet de valider une proposition qui convient comme il a permis de refuser une proposition qui ne convenait pas. (si nous l’avions changé pour cette proposition et qu’elle se retrouve adopté, le nouveau mode de vote n’aurait pas prouvé sa capacité à faire refuser une proposition qui ne convient pas).

Ça ne remet pas en cause la pertinence d’intégrer dans un second temps d’autres retours, comme celui de la traduction en d’autres langues qui me semble essentiel. Mais sur ce coup-ci, une chose à la fois plutôt que tout d’un coup.

PS :
Pour suivre l’avancée des votes :

4 « J'aime »
3

Ça y est, nous avons également des votes contre.
Dans l’optique de pouvoir intégrer les objections constructives à de futures propositions, pourriez-vous expliciter ce que vous mène à vous opposer à cette proposition ?
@BigFoot @Ccil

PS : Chacun⋅e est libre de son vote. Je pourrais avoir peur que l’impatience de certain⋅es se traduise en reproche à l’égard des personnes ayant voté pour. Je vous prie de ne rien en faire afin que la liberté de voter selon ses convictions personnelles soit préservée.

Si plus tard, nous avons un moyen technique de permettre du vote à bulletin secret, tout en ne prenant en compte que les votes membres, je serais ravi d’opter pour cette option. Et si c’est toujours avec le mode de vote actuel mettant une pondération bien plus forte au vote contre qu’au vote pour, les votes « contre » seraient alors associés à un motif à rédiger anonymement mais partagé avec son vote. Cela afin de correspondre à l’approche de recherche de consensus, où plutôt que de chercher la majorité, on cherche l’unanimité, et pour cela les objections doivent être justifié afin qu’il soit possible d’améliorer la proposition jusqu’à les lever.

8 « J'aime »
4

Je rejoins complètement @1000i100.

Ça ne se remarque peut-être pas, mais nous avons passé beaucoup d’énergie a élaborer ces propositions. Nous ne sommes pas des communicants alors nous n’avons pas présenté la démarche en long et en large, organisé des ateliers ouverts, etc… Parce qu’on ne sait pas faire.

Merci par avance si vous avez des doutes, des oppositions, d’en discuter avec nous ici avant de voter afin qu’on puisse y répondre et surtout que nous ayons des retours sous une autre forme que « Vote pour » / « Vote contre », et que de ces échanges puisse émerger un consensus qui rendra le prochain essai plus satisfaisant pour tout le monde.

La bienveillance, toussa :slightly_smiling_face:

4 « J'aime »
5

Merci d’être passé aux propositions étapes par étapes, ça permet de dégrossir !

Concernant une édition mineure de la forme de la licence, faut-il passer par cette procédure ?
S’il y a une typo, une faute de grammaire dans la langue source le français, est-ce possible de passer par une demande de changement (MR GitLab sur le dépôt git) ?

Est-ce que ce cas peut-être traité dans cette proposition v0.3.0 ? En définissant la nature et la taille du changement acceptable pour passer par une MR.

Pour les traductions, je dirais qu’elles ont libre cours de modifier la forme tant qu’elles traduisent correctement le contenu.

3 « J'aime »
6

Bonjour tout le monde.

Bel effort et la procédure que vous proposez est intéressante, merci.

Au rayon des objections, je me permets de dire que je pense que c’est trop complexe. Pour beaucoup de monde (qui n’osera pas le dire), le coup des 20 votes ‹ pour › + 5 votes ‹ pour › par vote ‹ contre › est une usine à gaz. J’aurais préféré quelque chose de sans doute moins parfait mais plus simple, donc plus inclusif.

Désolé de râler.

4 « J'aime »
7

On n’a pas prévu le cas. Je me pose la question de comment différentier de manière déterministe un changement anecdotique, qui pourrait bénéficier d’une procédure simplifiée de révision, d’une évolution significative.

Vu qu’on ne l’a pas prévu, pour moi non, mais on peut l’inclure dans une v0.3.1, en même temps que les enjeux de traduction par exemple.

Comment évaluer que ce n’est que la forme qui est changée et non le contenu ? Si ce n’est par un vote d’adoption des traductions ?

8

Merci de râler :wink:

Si tu as des idées pour faire plus simple, tout en étant fonctionnel pour la communauté Ǧ1, je suis preneur.

  • On aurait pu partir sur du classique vote à la majorité (que j’ai entendu nommer avec une pointe de malice « tyrannie des 51% ») mais d’une part, ça peut faire beaucoup de mécontent (50%-1) d’autre part, pour que le résultat soit perçu comme légitime et donc qu’il ait des chances d’être respecté, il faudrait un taux de vote exprimé élevé, hors, le degré d’implication des membres de la Ǧ1 est variable et difficile à prédire, donc le risque de se retrouver coincé à ne plus pouvoir rien changer parce qu’on a défini un quorum de vote exprimé trop élevé me semble significatif.
  • Pour la question du nombre du quorum (pour les systèmes de vote à quorum) une piste pourrait être de jouer avec les demi-vies : Pour qu’un vote soit clôturé en 1 jour, il faut que 100% des membres vote. En 2 jours, 50%. En 4 jours, 25%… En 32 jours, 3%… En 256 jours 4‰. Ce qui avec une TdC de 8000 membres donne 250 membres à 32 jours ou 32 membres à 256 jours. Mais est-ce simple à comprendre comme système, pas sûr. Et coté rythme d’évolution, ça impliquerait d’avoir plusieurs propositions en vote simultané et la première qui atteint les critères pour être adopté rend obsolète toutes les autres (qui pourront être re-proposé en se basant sur la nouvelle version adoptée).

Pour l’instant, la proposition « usine à gaz » est la plus simple que j’ai pu imaginer pour répondre aux enjeux précédemment cités.

@Pini avait aussi proposé de s’inspirer de ce qui se fait chez Débian, avec un vote de Condorcet (classer chacune des propositions, incluant la proposition de ne rien changer, par ordre de préférence), c’est conceptuellement simple, mais avec les outils techniques à notre disposition, ça me semble assez complexe à mettre en place, et dans le cas où il n’y a qu’une proposition en plus de la version en vigueur, ça revient à un vote à la majorité simple, avec les mêmes problématiques donc. Et s’il y a davantage de propositions, ça pose la question de comment on met dans un même pool de vote des propositions, ou comment on les garde pour un pool ultérieur.

On a aussi envisagé d’intégrer un anti-spam (collecter quelques soutiens avant que ne soit diffusé une proposition) mais dans un premier temps, on s’est dit qu’on allait faire sans pour faire plus simple, et qu’il serait toujours temps de l’ajouter quand un outil permettra de l’inclure de manière fluide pour l’utilisateur et/ou que le problème se présente (trop de proposition pour que la communauté y prête attention et vote)

Des idées ?

2 « J'aime »
9

Merci pour le Taff !!

vote envoyé !!

2 « J'aime »
10

+1 envoyé, parce que à 'ment donné, on va pas tergiverser des plombes :wink:

1 « J'aime »
11

En traduisant la proposition de vote pour le forum espagnol, je me suis rendu compte qu’il manque le point 4 dans la nouvelle proposition de modification. Je suppose que c’est plutôt une amélioration de forme, donc comme vous le dites, cela pourrait être fait dans une future version 0.3.1.

Il manque une mention de la date limite de vote, le 13 mars, en incluant l’heure exacte afin d’éviter tout conflit. ( 21:30 comme la date de la modification?)

J’ai également remarqué que le calcul des votes « pour » et « contre » est incorrect :

(25 « pour » si 1 « contre », 30 « pour » si 2 « contre »…)

Cela devrait être 25 « pour » si 5 « contre » et 30 « pour » si 6 « contre ».

Et si le facteur entre les votes « contre » et « pour » est de 1x5… je ne comprends pas la proposition suivante :

  • Si la proposition reçoit au moins 20 votes/transactions « pour » et aucun vote « contre », elle est considérée comme adoptée.

Ne devrait-elle pas aussi être adoptée si elle reçoit au maximum 4 votes « contre », puisque 20 et 4 respectent le facteur 1x5 ?

5 « J'aime »
12

Bonjour,

ce serait utile de préciser dans la licence que le « stock » des 100 certifications se « renouvelle » et qu’une certification redevient disponible 2 ans après la date de son émission.
Car il y a des Junistes qui pensent qu’il s’agit de 100 certifications à vie.
La licence me semble l’endroit adapté pour apporter cette précision.

A part ce point je suis favorable à la nouvelle proposition.

3 « J'aime »
13

Non justement. Le principe c’est que chaque vote « contre » impose d’avoir 5 votes « pour » en plus pour faire passer la proposition.

Le seuil de votes « pour » validant la proposition évolue donc ainsi, en fonction du nombre de votes « contre » :

  • 0 vote « contre » → au moins 20 votes « pour »
  • 1 vote « contre » → au moins 25 votes « pour »
  • 2 votes « contre » → au moins 30 votes « pour »
  • N votes « contre » → au moins 20 + (N x 5) votes « pour »
7 « J'aime »
14

:slight_smile:

Je crois que les derniers messages montrent bien la complexité de la procédure, même si, je le redis, elle a bien d’autres mérites. C’est sûr qu’une approche Condorcet ou jugement majoritaire serait tentante aussi.

Mais à mon avis la simplicité devrait primer. Un vote à seuil (nécessité de 75% d’avis favorables par exemple) avec quorum (10% des membres par exemple) me semblerait être clair pour tout le monde, et pas tellement plus arbitraire au final.

Enfin, c’est mon point de vue.

3 « J'aime »
15

Ah merci Pini, oui je suis d’acord avec @MatthieuLatapy , il est trop complexe pour comprendre comment elle est écrit a la proposte de license, ça serait plus facil parler de nécessité de x%(par exemple 83.33% si c’est 1x5 la proportion d’avis favorables) par exemple avec quorum minimum de y%

1 « J'aime »
16

(Introduire un quorum nous pousserait à activement encourager les membres à voter, ce qui me semble vertueux.)

5 « J'aime »
17

Tout d’abord merci pour le travail
Je ne suis pas spécialiste des votes mais j’ai peur que le ratio 1x5 conduise à des obstructions à répétition. (pourquoi ce ratio?)
J’ai voté non à la première proposition et je m’étais dit déjà que le OUI ne passerai jamais.
Je n’ai malheureusement pas de solution mais je me rapproche de l’avis de @MatthieuLatapy

Vu que les remarques du précèdent fil ont été prises en compte je vais voter OUI pour valider l’expérimentation.

ps: peut être préciser que 1G1 suffit pour voter :slightly_smiling_face:

2 « J'aime »
18

Merci @kapis pour la traduction :slight_smile:

Effectivement, c’est une coquille dans le texte source, la numérotation se faisant automatiquement pour le rendu html. Ce sera effectivement à corriger dans la v0.3.1

Effectivement, on pourrait expliciter plus précisément pour éviter les malentendus.
Pour moi le plus fiable serait de compter à partir du 1er vote émis donc 22h09.

Ce n’est pas une erreur, mais on pourrait peut-être simplifier ainsi en effet.
En l’état, pour que la proposition soit adoptée, elle doit avoir récolté à la fin du 30ᵉ jour au moins le nombre d’approbations suivant : 20 + 5*OPPONENT_COUNT
On pourrait simplifier à : 5*OPPONENT_COUNT ce serait peut-être plus simple à comprendre sans que ça change profondément le degré d’adhésion nécessaire, mais ça peut laisser passer des propositions pour lesquelles aucune communication n’a été faite et ça je ne suis pas sûr que ce soit une bonne chose.

1 « J'aime »
19

ça me semble une précision utile en effet, mais pour moi, ce serait davantage le lieu d’une livre blanc/white paper que de la licence. C’est ce que je développe ici :

2 « J'aime »
20

Au regard de vos retours, il faudra probablement à minima reformuler pour rendre plus clair l’algo de pondération des votes, et peutêtre le faire évoluer dans la direction de ce que tu suggère @MatthieuLatapy

En revanche, l’approche avec quorum me semble aujourd’hui très largement plus bloquante que le ratio 1 pour 5. Ou alors il faudrait qu’il soit ridiculement bas, et dans ce cas ça ne fait plus sens de le nommer quorum selon moi puisqu’il ne représente plus un seuil de vote exprimé considéré comme suffisant pour représenter l’ensemble, et donc la légitimité du résultat doit reposer sur autre chose (ici la proportion de vote pour > 5x les contre + 20 et la durée durant laquelle la proposition est publique et votable, ici 30 jours).

Pourquoi une approche par quorum me semble davantage bloquante ?

Parce qu’à 8 000, avec les outils de diffusion de la proposition de vote actuel et le degré d’implication de la communauté, espérer 800 votes (10%) me semble illusoire, et qu’abaisser ce quorum suffisamment pour que des modifications puissent passer (j’imagine 1% soit 80 votes) me semble inefficace pour construire la légitimité du résultat (imagine un opposant scander que dans la Ǧ1, ce sont les 1% qui décide, il n’y a qu’à voir leur quorum de vote… ça ferais mauvaise presse avec l’association culturelle des 1% aux plus riches dont les intérêts de classe divergent de ceux du commun des mortels)
Bref, pour moi nous ne pouvons pas compter sur la notion de quorum avec la communauté tel qu’elle est aujourd’hui et les outils dont nous disposons.
Si dans le futur, un outil permet de notifier efficacement tous les membres, pas seulement ceux qui se connectent régulièrement, je pourrais réenvisager la notion de quorum comme facteur de légitimité d’une décision par vote au sein de la Ǧ1 :wink:

Je te rejoins sur ce point, mais pas assez pour être favorable à l’approche quorum aujourd’hui.
Outre ce que j’ai dit plus haut, voici pourquoi :
Si l’énergie nécessaire pour atteindre le quorum est très élevée, cela encourage à ne dépenser cette énergie que rarement, donc à préparer tout ce qu’on aimerait voir changer d’un coup (comme nous l’avons fait dans la proposition précédente « Charte 1.0 ») pour ne dépenser l’énergie d’atteindre le quorum qu’une seule fois, plutôt que de multiplier les propositions dédiées à un aspect chacune. Or, il me semble bien plus difficile d’atteindre un degré d’adhésion élevé (se rapprocher d’un consensus) sur une proposition changeant de nombreux aspects d’un coup, que sur une proposition n’en changeant qu’un seul. De ce fait, il faudrait aussi baisser le ratio de 5 pour chaque contre vers au mieux une majorité au 2/3, au pire une majorité simple, ce qui change la philosophie du vote.

Philosophie associée au type de scrutin / vote

Ce que je prône avec l’approche actuelle, c’est de viser le consensus, en intégrant chaque objection pertinente dès lors que c’est possible. Ce qui envoie le message que les paroles même minoritaire/divergentes comptent et enrichissent le résultat final ; soit un paradigme de coopération valorisant l’écoute de l’autre.

Au contraire, un vote à la majorité (voir au 2/3) véhicule selon moi bien davantage une image de rapport de force ou la majorité a raison et écrase les voies divergentes sur son passage ; soit un paradigme de compétition valorisant les comportements de domination en cherchant à imposer sa vérité et faire taire les autres pour gagner la bataille.

J’y vais peut-être un peu fort, mais cela illustre pour moi l’enjeu sous-jacent de proposer des modes décisionnels différents de nos habitudes pour faire évoluer notre culture dans une direction qui me semble désirable.
Je suis d’accord qu’il ne faut pas que ça se face au prix de la simplicité, sans quoi on tombe dans un autre travers - élitiste - de réserver le pouvoir décisionnel aux seules personnes qui ont le temps et les capacités d’en comprendre les rouages.
Comment faire alors ? Se creuser la tête pour arriver à simplifier au maximum le procédé de vote et sa description, sans faire de concession sur les ambitions qu’il porte.

Mon approche pour arriver à ça est la suivante :

  1. en valider les concepts fondamentaux en les mettant à l’épreuve de la pratique, même si au départ on tombe dans le travers élitiste d’avoir quelquechose de trop complexe/déroutant pour être accessible au plus grand nombre / compréhensible du premier coup
  2. Trouver le juste équilibre entre élaguer le superflu pour viser la simplicité et intégrer les nuances manquante (comment gérer les traductions et corriger les coquilles le plus simplement possible, sans permettre de faire n’importe quoi sous couvert de juste corriger une coquille)
  3. Mettre en place des outils qui simplifie l’usage bien au dela de ce qu’une reformulation des modalités de vote peut faire.
  4. Perfectionner l’ergonomie des outils à partir des difficulté rencontrées et critiques émises, avec une vigilance au biais du survivant.
10 « J'aime »