= Engagement forgeron Äž1
1000i100
v0.0.6, 2025-02-05: 13:50
Version {revnumber} du {revdate}
:toc: right
:toclevels: 1
== Intention
S'assurer en tant que communauté que les forgerons qui gèrent l'écosystème technique le font avec :
compétence, rigueur, sécurité et réactivité.
== Clauses d'engagement forgeron
* [ ] Je certifie sous la menace ou autre forme de pression.
* [ ] J'ai réclamé une contrepartie en échange de ma certification.
* [x] Je sais joindre efficacement et rapidement la personne certifiée (téléphone généralement).
* [x] Je peux joindre le certifié par au moins 2 canaux (sms, email, xmpp, matrix...).
* [x] Le certifié m'assure avoir stocké son document de révocation membre sur plusieurs supports physiques (numérique ou non), récupérables indépendamment. En cas de vol, incendie, oubli de mot de passe... au moins une des versions lui est accessible.
* [x] J'ai vérifié que le certifié savait où consulter https://git.duniter.org/documents/g1_monetary_license[le présent document] dans son intégralité.
* [x] J'ai vérifié que le certifié gère déjà un nœud à jour et correctement synchronisé.
* [x] J'ai noté le style de configuration (packet debian, docker-compose...) que le certifié utilise pour son nœud (et cette configuration n'a pas de faille connue, notamment n'expose pas l'api unsafe publiquement).
* [x] Le certifié s'est engagé auprès de moi à m'informer de tout changement significatif de sa config (pour pouvoir transmettre les infos de manière ciblée si problème)
* [x] J'ai vérifié avec le certifié qu'il connait les risques pour le réseau d'être offline sans l'avoir annoncé, et qu'il se considère en mesure d'assurer un uptime suffisant.
* [x] J'ai informé le certifié que sans être validateur en ligne pendant https://doc-duniter-org.ipns.pagu.re/pallet_smith_members/pallet/trait.Config.html#associatedtype.SmithInactivityMaxDuration[`6 mois` (SmithInactivityMaxDuration)] il sera radié des forgerons.
* [x] J'ai vérifié que le certifié connait les délais de passage en ligne/hors ligne du validateur.
* [x] Je m'engage à contacter sous 24h max ce forgeron si j'apprends qu'un défaut concerne son nœud validateur (désynchronisé, pas à jour, inaccessible...).
* [x] J'ai questionné l'intention du certifié à rejoindre les forgerons et je reste prêt à le certifier.
* [x] J'ai vérifié que le certifié savait où consulter les règles détaillées de la TdC forgeron.
* [x] J'ai demandé au certifié quelles étaient ses pratiques de sécurité et je les estime suffisantes pour le réseau actuel.
== Annexes
=== Notice d'implémentation
À destination des développeurs de logiciels permettant de certifier :
. À chaque certification, l'ensemble des clauses sont présentées une à une au certificateur, dans un ordre aléatoire. Ceci dans le but de s'assurer de la lecture attentive du certificateur de chacune de ces clauses. (Contrairement aux certifications membres, ces certifications ne périment pas automatiquement et sont plus rares. Dans ce contexte, vérifier seulement un sous ensemble des clauses à chaque certification a été exclu).
. Il peut répondre *<-non* ou *oui->* à chaque clause.
. Le document de certification n'est émis qu'après avoir répondu correctement à chaque clause.
. Les clauses cochées ci-dessous doivent recevoir pour réponse *oui->* pour que le document de certification soit émis.
. Les clauses non cochées ci-dessous doivent recevoir pour réponse *<-non* pour que le document de certification soit émis.
. Toute réponse invalide interrompt la procédure de certification et présente le message suivant :
"Les questions suivantes n’ont pas reçu la réponse attendue. [... question concernées...] Nous vous invitons à relire l'ensemble des engagements forgerons et à en discuter avec d’autres forgerons avant de retenter de certifier."
=== Gouvernance pour faire évoluer le présent document
NOTE : L'intention de ce mode de gouvernance est de créer une séparation des pouvoirs : que ça ne soit pas les détenteurs d'un pouvoir qui définissent les règles et limites de ce pouvoir. Pour autant décider sans les concernés peut mener à des choix dangereux, raison pour laquelle l'adhésion d'une fraction d'entre eux est nécessaire. Enfin, le nombre de membre exprimé minimum est gardé faible pour tenir compte de la diversité d'implication de la communauté et que les moins actifs ne bloquent pas la possibilité d'évoluer quand il y en a besoin. La surpondération des votes "contre" étant présente pour qu'il soit facile de s'opposer s'il y a des raisons de le faire.
Tout coproducteur de monnaie Ǧ1 (membre) peut proposer au vote une version révisée du présent document.
==== Processus manuel en attendant une intégration dédiée aux votes dans les outils de l'écosystème Ǧ1 :
1. Elaboration de la proposition (solitaire ou coopérative, en s'appuyant sur le forum Monnaie Libre, le forum Duniter, Télégram monnaie libre ou autre…).
2. Quand une proposition est considérée comme finalisée, il est nécessaire de :
. Créer un compte portefeuille pour chaque option de vote : 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 de vote.
. 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 de vote, 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.
4. 30 jours après publication de la proposition finale sur le forum, les résultats du vote sont dépouillés. En fonction des résultats, la proposition est adoptée et remplace le document actuel, ou elle est rejetée et ce document reste en vigueur.
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.
==== Dépouillement : mode de comptage pour déterminer l'issue du vote
Si les conditions d’adoption ne sont pas réunies, la proposition est rejetée.
Les conditions d'adoptions sont :
. Parmi les votes "pour", au moins `ceil(pow(SMITH_COUNT,0.3))` votes sont émis par des forgerons
. Il y a au moins `3*OPPONENT_COUNT + ceil(pow(MEMBER_COUNT,0.3))` votes "pour" émis par des membres.
Soit une majorité au 3/4 des votes exprimés + quelques approbations par des forgerons.
Les oppositions (vote "contre" noté dans la formule ci-dessus `OPPONENT_COUNT`) sont traitées de manière identique, que le membre soit forgeron ou non.
===== Exemple 1 : De justesse !
Avec 15 forgerons et 8000 membres
Le vote obtient après 30 jours :
20 votes "pour" dont 3 des forgerons
1 vote "contre".
`ceil(pow(SMITH_COUNT,0.3))` = 3 requis (et 3 forgerons ayant voté "pour") : le nombre d'approbation forgeron est atteint de justesse !
`3*OPPONENT_COUNT + ceil(pow(MEMBER_COUNT,0.3))` = 3*1 + 15 = 18 requis (et 20 obtenus) nombre d'approbation atteint, la proposition est adoptée, mais il s'en est fallu de peu sur chacun des critères.
===== Exemple 2 : Proposition non consensuelle
Avec 20 forgerons et 5000 membres
Le vote obtient après 30 jours :
40 votes "pour" dont 5 des forgerons
15 votes "contre" dont 2 des forgerons.
`ceil(pow(SMITH_COUNT,0.3))` = 3 requis (5 forgerons ayant voté "pour") ce critère est atteint.
`3*OPPONENT_COUNT + ceil(pow(MEMBER_COUNT,0.3))` = 3*15 + 13 = 58 requis (et 40 obtenus) trop d'opposition pour que la proposition soit retenue (le fait que des forgerons aient voté "contre" ne change rien au comptage).
===== Exemple 3 : Proposition invisible (ici par et pour les forgerons)
Avec 5 forgerons et 6000 membres
Le vote obtient après 30 jours :
5 votes "pour" dont 5 des forgerons
0 votes "contre".
`ceil(pow(SMITH_COUNT,0.3))` = 2 requis (5 forgerons ayant voté "pour") ce critère est atteint.
`3*OPPONENT_COUNT + ceil(pow(MEMBER_COUNT,0.3))` = 3*0 + 14 = 14 requis (et 5 obtenus). Pas assez de communication pour que d'autres que les forgerons se prononcent, la proposition est rejetée.
===== Exemple 4 : Proposition intenable pour les forgerons
Avec 15 forgerons et 6000 membres
Le vote obtient après 30 jours :
350 votes "pour" dont 0 des forgerons
10 votes "contre" dont 5 des forgerons.
`ceil(pow(SMITH_COUNT,0.3))` = 3 requis (0 forgerons ayant voté "pour") pas assez d'approbation forgeron, la proposition est rejetée.
`3*OPPONENT_COUNT + ceil(pow(MEMBER_COUNT,0.3))` = 3*10 + 14 = 44 requis (et 350 obtenus) ce critère passe largement, mais l'absence d'approbation forgeron reste blocante.
===== Tableau du nombre d'approbations requises selon la taille de la toile. (traduction de la formule `ceil(pow(WOT_SIZE,0.3))`).
[cols="2"]
|===
|Taille de la toile,
|Approbations requises
|1
|1
|2 Ã 10
|2
|11 Ã 38
|3
|39 Ã 101
|4
|102 Ã 213
|5
|214 Ã 392
|6
|393 Ã 656
|7
|657 Ã 1024
|8
|1025 Ã 1516
|9
|1517 Ã 2154
|10
|2155 Ã 2960
|11
|2961 Ã 3956
|12
|3957 Ã 5165
|13
|5166 Ã 6613
|14
|6614 Ã 8323
|15
|8324 Ã 10321
|16
|10322 Ã 12632
|17
|12633 Ã 15284
|18
|15285 Ã 18302
|19
|18303 Ã 21715
|20
|...
|...
|===
Est considéré comme **membre** : Toute personne dont le compte est reconnu membre par la toile de confiance Ǧ1 en vigueur.
Sont considérés comme Forgerons
- V1 : les membres ayant écrit au moins un bloc au cours des 7 derniers jours
- V2 : les membres de la toile forgeron en vigueur.
=== Convention d'incrémentation du numéro de version vA.B.C :
* A : Refonte du document, changement de vision, changement majeur de gouvernance, changement impliquant de nouveaux développements pour les logiciels permettant de certifier.
* B : Evolution mineur de la gouvernance (changement de seuils), ajout/suppression/modification des clauses impactant certaines modalités d'engagement.
* C : Correction de typo, clarification/reformulation sans changer l'intention, traduction dans une autre langue
Les composant A et B du document doivent être à jour au regard des autres langues dans toute nouvelle proposition impactant ces composantes, quelle qu'en soit la langue. En d'autres termes, il est nécessaire de vérifier que les versions dans d'autres langues n'ont pas intégré d'évolutions de type A ou B avant de faire une proposition. Si une telle évolution a eu lieu dans une autre langue sans être traduite dans la votre, commencer par la traduire pour que votre proposition d'évolution en tienne compte.
Exemple (seul les propositions acceptées sont considérées):
[cols="2"]
|===
|Chronologie
|Versions en vigueur
|J0
|*v1.0.0-fr*
|J1
|v1.0.0-fr, (v1.0.0-fr) -> *v1.0.1-es*
|J2
|v1.0.0-fr, v1.0.1-es, (v1.0.0-fr) -> *v1.0.1-en*
|J3
|v1.0.0-fr, (v1.0.1-es) -> *v1.1.0-es*, v1.0.1-en
|J4
|(v1.1.0-es) -> *v1.1.1-fr*, v1.1.0-es, v1.0.1-en
|J5
|(v1.1.1-fr) -> *v1.2.0-fr*, v1.1.0-es, v1.0.1-en
|J6
a|v1.2.0-fr, v1.1.0-es,
[WARNING]
====
`(v1.0.1-en) -> v1.1.0-en` or `(v1.0.1-en) -> v1.3.0-en` are incorrect.
Do first `(v1.2.0-fr) -> v1.2.1-en` then `(v1.2.1-en) -> *v1.3.0-en*`
====
|===