J’ai bossé sur la licence/charte/engagement des membres de la Ǧ1, sur la licence, charte ou autre concernant les forgerons…
Je bosse aussi sur une version pour le comité technique dont voici le brouillon :
Il y a clairement pas mal de chose à retravailler dedant, mais pour éviter de rester en tunnel solo, je le pose là pour que vous puissiez vous exprimer dessus également.
Merci 1000i100 pour ce travail de structure et compilation.
Tu connais mes réserves sur la précipitation à créer des organes statutaires, car ils finissent par avoir leur vie propre et reproduire les schémas familiers. Je ne recommence pas ici, mais d’une manière générale, je trouve que tu grilles des étapes, et tu me sembles chouia trop confiant sur la façon de prévenir des risques et dérives de pouvoirs potentiels.
Pourquoi ne pas se concentrer sur les briques élémentaires ? Et partir de la nécessité :
J’entends l’argument de la durée que pourrait prendre la conception, même si je la trouve très hypothétique car cela ne serait pas moins “lourd et complexe” que le présent travail. J’entends la position “on commence par faire simple, on prendra le temps par la suite”. Ok avec ça, mais pourquoi se précipiter sur un “Comité technique” qui veut tout et rien dire, mais qui appelle irrémédiablement à son institutionnalisation, sa durée ? Pourquoi ne pas se contenter de ce qu’il est vraiment, de façon explicite ?
→ un petit groupe de personnes qui définit les variables de la décision on-chain, qui autorise l’upgrade. C’est “l’autorité du runtime upgrade”.
Tu mets le doigt à juste titre sur les mécanismes d’influences et de potentiels pouvoirs qui sont à l’œuvre de façon implicite, lorsqu’ils ne sont pas explicites. Mais avant de se précipiter sur tout une édification institutionnelle sensée prévenir les problèmes de notre écosystème, pourquoi ne pas simplement … rendre explicite (ce qui ne le serait pas) ?
Ici, on aurait l’éclairage des 6 personnes actuelles qui constituent “l’autorité de l’upgrade”. Si l’on n’aime pas ce terme Autorité ? tant mieux. Il désigne ce qu’elle est dans les faits, dans ses écueils mais aussi dans ses vertus ; elle autorise.
Et lorsqu’il y aura un problème à résoudre, on se concentrera sur la façon de le résoudre.
Par exemple, si l’on se met dans cet état d’esprit et que l’on raisonne processus, on réalise assez rapidement le problème prioritaire à résoudre n’est pas à l’endroit des pouvoirs et contre pouvoirs : les devs du moment font ce qu’ils peuvent (c’est leur pouvoir) et les autres disposent. Les utilisateurs n’ont aucun pouvoir sur les décisions l’endroit de l’écosystème. Nous avons un plein pouvoir au niveau des usages. Quel(s) problème(s) montrent nos 8 années d’expérience collective ? / sur la question du processus de déploiement logiciel.
Il est bien davantage sur un trou béant qui se révèle alors dans cette observation du processus : personne ne relit le code.
Donc de mon point de vue, avant de raisonner sur des contrepouvoirs théoriques, qui seraient dans notre contexte de facto factices, il me semble plus fertile et constructeur de robustesse de se pencher sur un processus incluant une relecture, non ? (dosage, indice critique, décentralisation, rétribution, …)