= Engagement forgeron Ğ1
1000i100
v0.0.5, 2025-02-03: 16:40

Version {revnumber} du {revdate}

:toc: right
:toclevels: 1

== Intention
S'assurer en tant que communauté que les forgerons qui gère l'ecosystè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 (vol, incendie, oubli de mot de passe... au moins une des versions lui reste 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 noeud à jour et correctement synchronisé.
* [x] J'ai noté le style de configuration (packet debian, docker-compose...) qu'utilise le certifié pour son noeud (et cette configuration n'a pas de faille connue, notament n'exposer 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 noeud 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 :

. A chaque certification, l'ensemble des clauses sont présentées une à une au certificateur, dans un ordre aléatoire.
  afin 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 rare. 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 re-tenter 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 la quelle 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 diverstié d'implication de la communauté et que les moins actifs ne bloque pas la possiblité d'évoluer quand il y en as besoin. La sur-pondération des votes contre étant là 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. (à terme, via gouvernance on-chain)

==== Processus en attendant la version on-chain :

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 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.
4. 30 jours après publication de la proposition finale sur le forum les résultats du votes sont dépouillés. En fonction des résultats, la proposition est adoptée et remplace le document actuel, ou elle est rejeté et ce document reste en vigeur.

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éterminé l'issue du vote
Si les conditions d’adoption ne sont pas réunies, la proposition est rejetée.
Les conditions d'adoptions sont :
. Parmis 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 approbation par des forgerons.
Les oppositions (votre "contre" noté dans la formule ci-dessus `OPPONENT_COUNT`) sont traité de manière identique que le membre soit forgeron ou non.

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

|...
|...
|=== 


Sont considéré comme membre:: Toute personnes dont le compte est reconnu membre par la toile de confiance Ǧ1 en vigueur.

Sont considéré comme Forgeron:: V1 : les membre 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 de 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, quel qu'en soit la langue. En d'autre termes, il est nécessaire de vérifier que les versions dans d'autres langues n'ont pas intégrer d'évolution de type A ou B avant de faire une proposition. Si une tel évolution as 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 (en ne considérant que les propositions accepté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*`
====

|===