J’aimerais te dire oui mais :
Du coup je te propose d’éditer plutôt ce message Proposition Charte 1.0 - #14 par 1000i100 et on intègrera tes corrections pour le prochain vote 
Oui totalement, l’idée est de test artisanalement avec la V1 un mode de scrutin au consenssus mou (en gros, ça passe facilement (corum bas) si tout le monde est d’accord mais ça bloque très vite s’il y a des objections significative non prise en compte, pour autant s’il y a juste quelques réfractaire au changement qui ne justifie pas leur opposition, il y a des chances qu’il reste suffisament peu suivi pour ne pas bloquer l’évolution).
Dès qu’on aura des outils pratiques, si le principe de scrutin au concenssus mou marche bien, on le garde mais on change la procédure poru qu’elle soit plus pratique.
Et si justement on utilise quelquechose du type « runtime upgrade », on vote pour un hash ou une signature, donc impossible de changer la moindre virgule une fois le vote lancé, d’où le fait que pour jouer le jeu, je t’invite à éditer mon commentaire 14 et non le texte de référence.
On a envisagé de ne tenir compte que du dernier vote depuis chaque identité membre pour permettre de changer d’avis, mais ça complexifiait légèrement les explication et le dépouillement, donc on a fait au plus simple, dans l’idée qu’on améliorerais ça quand on aura des outils de vote dédié dans la V2 pour faire ça mieux.
On aurait pu, mais avec les débat sur la suppression des commentaires de transactions ces dernières années, on a préféré ne pas s’appuyer dessus.
Pour moi non, c’est justement quelquechose qui m’a toujours déranger dans la licence.
C’est important pour moi de séparer les responsabilité/intensions :
- Comprendre comment ça marche et pourquoi ces choix et principes théorique, c’est le role d’un contenu informatif, de vulgarisation, comme la page d’accueil du site monnaie-libre.fr ou nombre d’autres documents destiné à faire découvrir la Ǧ1, et s’il faut un document de référence précis pour ça, il y a la TRM, et si certaines personnes ne sont pas à l’aise avec l’écrit, il y a des vidéo qui fond le job, bref, on est sur de l’information, de la transmission de connaissance et de concepte, pas sur de l’engagement.
- Ce à quoi il est nécessaire de veiller scrupuleusement et sur le quel chaque membre doit s’engager, ça cest le role d’un document contractuel qui est engageant. Pour moi, mélanger les deux introduit de la confusion dans le rôle du document et dilu l’engagement, ce qui fait que d’une personne à l’autre il pourra y avoir beaucoup de variation dans le serieur avec le quel il est considéré ou oublié au milieu du reste.
Pour moi, cette responsabilité ne reviens pas à la charte (ou licence) mais à ce qui est souvent appellé un « white paper ». Et son absence dans le cas de la Ǧ1 est souvent reprochée par les personnes qui viennent découvrir depuis le monde des crypto.
Ceci dit je suis très favorable à ce qu’un white paper soit rédigé pour expliquer la formule du DU et les autres concepts fondamentaux de la Ǧ1 de manière synthétique et aussi compréhensible que possible, et que la charte y fasse référence plutôt que d’avoir une annexe.
Et dans la checklist avoir une question qui vérifie que la personne certifiée sais où trouver le white paper et qu’il décrit les conceptes fondamentaux de la monnaie libre Ǧ1 me semble une bonne idée.
Oui, de même qu’il est régulièrement question de rendre le permis voiture à durée limité, pour vérifier que les personnes sont toujours en mesure de le respecter, et de pouvoir leur transmettre les évolutions quand il y en a.
Dans la licence actuel il est toujours question de « bien connaitre la personne » notion flou interprétable de manière très différente selon la sensibilité de chacun⋅e. Si ma perception de bien connaitre est dangeureusement laxiste et que pour renforcer la fiabilité du système on fait évoluer ça, les question à chaque certification permettent de transmettre les nouveauté aux anciens qui du haut de leur ancienneté peuvent considérer tout savoir et ne pas avoir besoin de se mettre à jour.
Bref, je suis très favorable à l’approche par checklist plutôt que document à lire et accepter. J’en avais parlé pour la première fois au RML12
Un autre aspect pour moi, en faveur de cette aproche, c’est que la charge reviens à la personne qui certifie, soit quelqu’un qui a fait plus de chemin dans l’écosystème Ǧ1 que la personne à certifier, au moins pour la première certification. Du coup, la courbe d’apprentissage me semble plus douce. On a envisagé de mettre moins de questions lors du renouvellement, mais par simplicité nous n’avons pas retenu cette option. Si on met dans une future version la checklist en annexe pour les développeurs, on pourra le ré-envisager.
A chaque avenant à un contrat, il y a besoin de le re-signer.
Si la validation de la charte/licence se faisait en blochain, associée à sa version, on pourrait à chaque évolution de la charte demander sa revalidation par les membres, en présentant ce qui change. ça répondrais à l’aspect mis à jour avec plus de finesse, mais :
- ça me semble demander plus de taf technique, qui n’est pas du ressort des rédacteur du document.
- ça ne répond pas à mon point « courbe d’apprentissage » ou la personne qui certifie se charge de vérifier (auprès dula certifié⋅e) qu’iel s’engage là ou c’est nécessaire et que les points de compréhension et/ou sécurité sont aquis, plutôt que de compter sur la personne qui débarque pour assimler le nécessaire de son coté avec le texte à lire, comprendre et accepter.
- la répétition me semble utile à l’intégration, mais en effet, pour quelqu’un de très actif, cette répétition pourrais être une fois par an, pour sa propre ré-adhésion plutôt qu’a chaque certification.
Le logiciel n’est pas conforme à la charte, ce qui peut mener la communauté à le déconseiller ou le boycotter, tout comme une personne qui ne respecte pas la charte/licence vera normalement la communauté lui refuser le renouvellement de certification.
Ce n’est pas une conséquence automatique, ça reste au final, les personnnes qui décident comment gérer les situations de non respect de la charte/licence.
Tout à fait d’accord, en l’état nous avons essayer d’avoir un format et, le plus intelligible pour des lecteurices humain⋅es, et suffisament consistant pour être interprétable par du code.
A parament le compromis semble trop technique pour les humains et pas assez pour les dev, donc peutêtre qu’il va falloir revoir la copie de ce coté
Aurais-tu trouvé plus serieux de dire « Le certifié » ?
Personnellement, pour une monnaie ayant comme date anniversaire le 8 mars, et ayant choisi le féminin pour désigner son symbole monétaire, ça me semble cohérente d’adopter du langage inclusif ou du féminin neutre dans ses documents de référence plutôt que de reproduire l’usage popularisé si je ne me trompe au XIXème scièce du « le masculin l’emporte sur le féminin ». Mais je peux concevoir que ni l’idée ni la façon de la mettre en pratique ne fasse l’unanimité. Pour limiter au maximum les clivage que ce sujet pourrait généré, nous avons privilégié les tournures épicène autant que possible, sauf lorsqu’elle alourdissent trop les phrases.
Rajouter personnes entre « La » et « certifiée » passe du féminin neutre à une tournure épicène, je n’y vois pas d’inconvénient dans les phrase qui ne contienne pas déjà le terme personne (pour éviter les tournure trop lourdes).
D’autre part, le racourcie explicite permet d’introduire la notion de tutelle qui me semble utile pour la certification d’enfant ou de personnes agée ou handicapé, bref pour tout les cas ou une personne physique vivante n’est pas autonome pour gérer son compte, mais reste légitime à accéder à sa part de création monétaire.
Si le changement de nom est accepté, ça me semblerait cohérent oui.
Je suis en bonne partie d’accord.
Si ça passe en l’état, selon moi, on aura gagné du temps, si ce n’est pas le cas, ça me semble pertinant de reproposer les changements tel que tu le suggère.
Pour moi, l’idée de proposer la refonte totale est de pouvoir proposer un tout cohérent qui n’est pas un simple ajustement de la version précédente. (un peu comme un logiciel qui change de version majeur, la rétrocompatibilité n’est pas nécessairement assurée) Hors, sans ce coté refonte radical, je voyais difficilement comment sortir du mélange engagement → charte et information → white paper qui cohabitait jusqu’ici maladroitement à mon gout dans la licence.
En outre, proposer la version avec tout les changement d’un coup, nous permet d’avoir des retours sur l’ensemble des aspects, et vu qu’il y a la charte forgeron et celle du comité technique sur le feu pour la V2, ces retours me semble plus que bienvenue pour les intégrer au plus tôt dans ces autres documents pour qu’ils soient prêts au lancement.
@Moul , Ais-je répondu à toutes tes questions ?