Salut la bande,
Désolé d’avoir raté les 2 premières visios du lundi, alpagué par mon retour après 2 semaines déconnectées. J’ai lu les posts et les pads, bravo et merci.
En ce qui concerne ma contribution, voici ce que je peux vous proposer :
. de la rédaction à la demande, passez vos commandes si vous le souhaitez.
. une mobilisation sur “objectif lune : consensus sans fork”.
[ j’ai bien noté dans le pad du 25.3 que ce ne devait pas constituer le leitmotiv de comm, je comprends cette recommandation dans les règles de l’art, mais perso c’est cet objectif d’hugo qui me plait le plus et c’est pour moi le vif de sujet ].
Ma démarche peut être satellitaire (c’est-à-dire perso plus que vs. axiom), mais il y aura des convergences. Je propose par exemple :
. le lancement et le maintien d’une FAQ façon wiki (qui me semble être une bonne façon de répondre à la question de Paola et l’outil pourra potentiellement évoluer vers une sorte de “kowleddge center” après migration).
. un “cahier de doléances” pour traiter les craintes et les espoirs, les objections et les wishlists.
. un “panorama”, outil d’aide à la décision pour les forgerons, visuel.
RQ : le cahier de doléances recueille les expressions libres et toute la matière (sujets à craintes, polarités, échelles de priorités, …) permettant de “dessiner” le panorama. Cette matière première permet de concevoir des sondages puisés dans le réel, pour mesurer le poids et l’intensité de chaque tendance, position, préoccupation.
Ça peut démarrer par un post de type témoignage.
Brouillon :
RLM 18 - Migration v2s
Témoignage d’utilisateur
Le sujet de ces RML18 est la migration de duniter v1 dans un environnement plus solide et structuré, un framework du nom de substrate. On s’en approche doucement mais surement. Il est évoqué, avec grande prudence, une ligne de mire au 1er trimestre 2025.
Il y avait une quinzaine de devs et une demi-douzaine de junistes touristes comme moi, dont quelques piliers du groupe local de Mayenne. C’était donc une édition très studieuse, “entre devs”, ce à quoi aspirait pas mal Kimamila qui était le « porteur » de cette édition. L’heure est en effet aux calages et aux plans d’action.
Les devs ont tous des profils très différents, des positions et des postures variées, j’ai trouvé cette séquence de 3 jours à la fois amusante et instructive sur le paysage de notre écosystème technique. J’ai trouvé un équilibre relativement magique, entre les réflexions et les intentions. Je vais vous en donner plus loin un ou deux exemples très concrets.
Sans plus de préambule, je passe directement aux sujets qui peuvent fâcher certaines personnes, ceux qui peuvent inquiéter d’autres personnes.
- Le fork.
Ce qu’il faut réaliser c’est que pour l’intégralité des devs présents (je compte les adminsys quand je dis dev bien sûr), cette migration n’est pas, n’est plus, une option. Elle est une nécessité ; la v1 était le POC, le prototype grandeur nature, relativement artisanal et fragile, cette v2 permet non seulement de passer à l’échelle mais c’est aussi une condition à la longue durée.
Les devs ont choisi en 2017 de créer un réseau propre à nos 2 blockchains, donc de ne pas utiliser un réseau déjà existant comme polkadot ou solana. Ils choisissent aujourd’hui de continuer sur cette voie pour la v2. Substrate facilite et structure le dev et l’administration, mais on conserve notre propre réseau maison. Ce sont les fameux nœuds, avec derrière ces machines qui créent et signent nos blocks, les forgerons.
Aujourd’hui, les forgerons v1 ont tout pouvoir. En effet ce sont eux qui décident de mettre à jour leur nœud, ou pas. Dès que 2/3 des nœuds ont effectué la mise à jour, le réseau switche, les clients (Cesium, G1nkgo, Silkaj) se connectent aux nœuds à jour, tout le monde tourne sur la mise à jour.
Aujourd’hui il peut y avoir, et il y a eu plusieurs fois, des forks involontaires du fait que les forgerons zappent une mise à jour et qu’il faut donc « courir après ».
Première conclusion perso :
Quoi que l’on pense, dise ou fasse, la décision de migrer sur V2 appartient aux forgerons, à 100%.
=> l’idée selon moi est donc de leur donner les moyens … de décider.
Que leur faut-il ?
. Un document de référence, exhaustif et transparent de ce que contient le runtime upgrade.
. Une lecture fine et claire des positions, craintes et désirs de la communauté.
Comment produire cela ?
. Le document de référence doit être fait par les devs évidemment, mais dans un langage prosaïque. D’autant plus que ce document doit être compris par tous les curieux, car il est également le socle qui permet à tout un chacun de forger son jugement, donc à la communauté de se positionner.
[ l’intérêt d’un doc de référence est d’autant plus utile que les posts, les capsules vidéos, visios filmées, et autres formats vont être très nombreux, et qu’il sera facile de se noyer un peu, ou seulement craindre de rater de l’info ].
Les forgerons doivent réaliser par exemple, que cette migration a pour effet de distribuer le pouvoir. Leur abstention vaudra dorénavant validation (alors qu’elle était jusque là bloquante). Ils pourront toujours refuser une mise à jour, mais il devront le faire volontairement. Sinon, le collectif des devs pourra opérer la mise à jour des nœuds automatiquement. C’est d’ailleurs tout le propos et ce qui donnera un gage de fiabilité et de longévité à notre réseau.
Les forgerons doivent aussi réaliser que ce sera dans la symbolique version v1.10.1 que leur décision sera prise, car elle embarquera le killswitch qui permettra aux nœuds de basculer de concert, donc une migration instantanée de tout le réseau pour éviter bugs ou interruptions de service.
Cette distribution des pouvoirs techniques entre les forgerons et les devs est plutôt claire, elle tient dans le protocole du “runtime upgrade”, IN or OUT, c’est le cœur de ce pouvoir technique ou toute modif mineure comme essentielle est possible.
Mais au fait, c’est qui … les devs ?
A cet endroit c’est moins clair, et pour cause, nous quittons ici le code et la technique pour rentrer dans a belle nébuleuse de l’organisation … humaine.
Aujourd’hui “les devs”, c’est ledit "collectif des devs’', qui rassemble dans une belle indéfinition les codeurs et les admins présents, en fonction de leur mobilisation du moment, leur dispo, leur légitimité technique. C’est le collectif des devs qui a par exemple tenu le premier “cercle de répartition” pour affecter les euros collectés de nos dons (crowdfunding, helloasso axiom).
Aujourd’hui, émerge doucement le terme “Comité technique” pour donner corps à cette entité protéiforme, lui donner une figure plus institutionnelle, plus familière, plus reconnue. Rien n’est vraiment formalisé dans ce registre, mais il me semble qu’il va s’imposer puisque le gros changement de la v2 est cette distribution de pouvoir technique.
Comme je vois ce terme “Comité technique” s’inviter dans les CR et les Pads, je me demande s’il serait possible et préférable de continuer en mode “Collectif des devs” et d’institutionnaliser davantage un “Cercle de décisions” qu’un “Comité technique”, un protocole davantage qu’un organe statutaire. Je ferme la digression 
. Le second chapitre, brosser le paysage des positions de la communauté, est plus ambitieux encore. Car il ne s’agit pas de simplement trouver un format de vote pour dire oui ou non, il s’agit ici de brosser un paysage pour nourrir les décisionnaires, qui seront seul(e)s face à leur décision.
- Migration sans fork - forkless.
Le monde idéal est pour beaucoup d’éviter une sorte de schismo-genèse de la June. La communauté semble encore si petite et fragile que ce serait un coup dur ; cela apporterait en effet complication et confusion.
[ Toutes les personnes qui ont fait des présentations de la june verront bien de quoi je parle 
]
Parmi les devs, le plus fervent défenseur de la recherche d’un consensus, c’est Hugo pour ne pas le citer. Il est évidemment lucide sur le fait que rien ne puisse remporter une unanimité, et en vient donc à se demander quelle proportion de refus serait « cool », « acceptable », « contrariante » ou « rédhibitoire » (ces termes sont les miens, pas les siens ;-). Et c’est là que ça se complique évidemment, comment poser des chiffres là-dessus ? C’est déjà difficile de le faire pour soi, alors se mettre d’accord collectivement… mission impossible. Pire encore, une forte proportion des utilisateurs s’en fiche royalement, probablement ; le fameux biais de ladite majorité silencieuse.
Quelques devs pensent que c’est une impasse, que la communauté leur a fait confiance sur la v1, et qu’il n’y a pas de raison pour qu’elle ne suive pas sur la v2. Ce sont les mêmes personnes après tout.
Et voici un exemple très précis d’équilibre entre les différentes tendances et nuances, d’où émerge l’idée par exemple de produire de l’information structurée pour qu’on puisse tous s’y retrouver, celle de procéder à des sondages, mais aussi celle de donner les moyens à ceux qui veulent reprendre et poursuivre une v1.9, de le faire. Paquet cadeau pour que la liberté de choisir ne soit pas factice, même si ce choix leur parait étrange et illusoire.
Il ne m’appartient pas de commencer à structurer les différentes positions et arguments, même si j’en ai déjà identifié un bon nombre. On le fera à plusieurs à partir d’un cahier de doléances.
L’idée de ce cahier est de nous exprimer librement sur 3 questions :
. Ce que je ne comprends pas.
. Ce que je crains.
. Ce que je souhaite.
A partir de là on extraira tous les sujets, les polarités, les échelles de priorités, et on cherchera à restituer ça de façon visuelle (phase qualitative).
Dans un second temps, en plus de répondre aux interrogations, on procédera à des sondages pour visualiser le poids des sujets et des tendances (phase quantitative). L’idée serait de pouvoir changer ses réglages, ses positions, de voir ce panorama évoluer, jusqu’au moment de la décision par les forgerons.
L’idée de ce panorama est de présenter une image vivante de notre consensus, dans toutes ses nuances.
[ ouverture d’un cahier de doléances ]
[ ouverture d’une FAQ Wiki ]
[ expérimentation d’un panorama ]
[ recrutement dev dataviz (ManUtopik ?) ]
[ recrutement relais canaux ]
=> à lundi
