Soit:
Le processus de cooptation que tu commence à décrire, serait d’avantage compris si des chiffres étaient proposés pour permettre une projection claire. Il faut modéliser un minimum, sinon personne ne peut comprendre les impacts.
1 Like
Une autre idée qui m’est venue comme çà :
La première certification reçue aurais une validité de 4 mois, la 2è 8mois, la suivante 12 mois, et ainsi de suite, ce ne serait qu’a partir de la 6 certification reçue que la validité resterait à 2 ans.
L’idée c’est qu’une personne continue de venir aux rencontres ou au moins de garder le contact pour rester cocréateur de monnaie.
Personnellement j’incite les gens à se faire certifier au minimum une fois tous les 4 mois, pour ne jamais être en manque de certification.
Je sais pas comment modéliser le truc, ni si cela serait efficace. Je propose simplement.
4 Likes
Je me permets de répondre ici, car je ne suis pas certain d’avoir trouvé le thread actuel qui parle de modifications de la licence. Je vois qu’il y a une MR ouverte sur le repo, mais inactive depuis juillet 21. Est-ce qu’il y a une raison à cela ? J’aimerais proposer une version allemande de la licence, mais ça ne vaut pas trop la peine si la version française change encore avant.
Est-il vraiment indispensable d’être développeur pour être relecteur ? Pour l’instant seul 4 ont “signé”
Soit il faut élargir la notion de relecteur, soit il faut diminuer le nombre de relecteurs requis.
1 Like
Tu peux proposer une traduction en allemand.
La source ne devrait pas changer de si tôt.
Perso je trouve la licence actuelle trop verbeuse avec plein de conseil redondant.
Du coup je propose une version totalement différente, que je met en partage ici : Framapad semestriel
Dites-moi si cela vous semble pertinent.
Je n’ai aucune idée de comment soumettre un changement de licence.
4 Likes
Très bonne reformulation ! Je me suis permis deux modifications.
C’est entre deux validations le délai de 5 jours par entre les émissions.
@Poka effectivement appeler cela charte plutôt que licence serait une bonne idée
c’est moi qui ai fait cette modif et rayé les nombre de jours (que je trouve trop lourd et inutiles).
Ce comportement prête parfois à confusion justement, la validation des certifs tous les 5 jours se fait dans un ordre aléatoire, ce n’est pas du tout intuitif et pratique, tout en étant inutile à préciser.
Dans Duniter v2s, il s’agit bien désormais de l’émission des certifications qui sont séparés par un délais de 5 jours. Je trouve cela beaucoup mieux sachant qu’on aura ET une gestion de contact pour garder trace de quelqu’un facilement, ET éventuellement la possibilité de planifier des certifs via la palette scheduler (reste aux client d’intégrer ça bien…)
Non les certif ne seront pas planifiables, ou alors dans un futur très limité et sans périodicité, pour éviter le renouvellement automatique des certif, qui conduirait à ne plus revérifier tout les 2 ans que l’on est toujours suffisamment en lien avec nos certifiés.
Et en tous les cas ce ne sera pas la pallet scheduler qui est conçue pour être utilisée uniquement par la gouvernance on chain, on doit développer notre propre pallet pour ça: Feat: add automatic transfers feature (#69) · Issues · nodes / rust / Duniter v2S · GitLab
1 Like
@poka Je pense que @Maaltir propose une modification pour la Ğ1v1 actuelle, en tout cas je ne vois aucune raison d’attendre la migration sur la Ğ1v2 pour améliorer la licence Ğ1 dès à présent 
1 Like
Oui moi aussi, je sais que le comportement réel est un délais de confirmation, mais je trouve qu’il est plus sage d’expliquer aux gens d’attendre 5 jours entre l’émission de 2 certifs, pour éviter toute congestion et randomisation de l’ordre des certifs probablement non voulu pour l’utilisateur.
Mais je sais que c’est confusant l’un comme l’autre, car techniquement tu peux certifier 10 personnes d’un coup.
Sinon gardez la première formulation, mais quelque part dans l’onboarding il faut préciser que si tu as plus d’une certif en attente, l’ordre de validation est aléatoire, même si c’est pénible de devoir indiquer ça à l’utilisateur (en vrai c’est le genre d’info qui devrait être indiqué par Cesium au moment où tu certifies quelqu’un en ayant déjà une autre certif en cours de validation… Parceque je ne vois pas comment indiquer ça dans la charte sans alourdir inutilement le propos).
1 Like
2- Je n’ai et n’aurai jamais qu’un seul compte créateur de monnaie.
Je comprends que si je perds mon compte, c’est mort à tout jamais. Il manque un “simultanément”, mais ça rendrait la phrase plus longue et complexe.
5- Je ne certifierai jamais une personne sans avoir d’abord vérifié qu’elle respecte bien tous les engagements.
Quels engagements ? Je préciserais qu’il s’agit de ceux de cette même charte.
6- Je signalerai à la communauté toutes les personnes qui ne respecteraient pas ces engagements.
C’est un peu fort, des fois il suffit de le signaler à la personne, des fois à ses certificateurs, des fois à toute la toile. Ça donne l’impression qu’on s’engage à être un délateur inconditionnel en place publique.
Les mots “cocréateur” et “membre” sont utilisés, et le mot “cocréateur” est introduit au milieu d’une notion déjà assez compliquée. Il mériterait son paragraphe à lui tout seul (ou avec la notion de membre), pour ne pas être confondu avec le membre référent.
2 Likes
Je pense aussi qu’il faudrait introduire le DU avant de parler de cocréateur. (sinon, on cocrée quoi ?)
Donc déplacer la partie TdC plus bas. Ça fait une coupure avec les engagements mais ça permet de ne pas accumuler sur des paragraphes des notions inconnues.
Pour moi, cette partie, ce sont les explications de comment ça fonctionne, et non pas de comment l’utiliser. En essayant d’être concis.
J’ai essayé d’être le plus concis possible en restant assez clair. Je vais chercher une autre formulation si celle-ci n’est pas assez claire.
Cela me semblait évident, j’aurais dû mettre ces engagements au lieu de les
J’ai essayé de reporter l’idée qui était là
En cas d’erreur, prévenez immédiatement d’autres membres de la TdC Ğ1.
et là
Si vous vous rendez compte qu’un certificateur effectif ou potentiel du compte concerné ne connaît pas la personne concernée, alertez immédiatement des experts du sujet au sein de vos connaissance de la TdC Ğ1, afin que la procédure de validation soit vérifiée par la TdC Ğ1.
C’est peut-être un peu fort en effet. Mais je veux aussi attirer l’attention sur l’importance de respecté ces engagements. Je vais chercher une autre formulation.
En effet, je pense qu’il faut supprimer cette notion de membre (ce n’est pas un club)
Je me demande si à la place de “membre” de la TdC on pourrait employer le terme “Tisseur” de la toile ? Ça me vient comme ça à l’instant.
Je crois que c’est une bonne idée, je n’étais assez disruptif par rapport à l’actuelle licence 
Aviez-vous remarqué que dans la licence actuelle, il n’est pas écrit qu’on ne doit avoir qu’un seul compte ?
J’aimerais aussi ne pas utiliser le mot « membre », mais il est utilisé dans les clients, donc il faudrait soit le garder pour ne pas perdre les gens, soit mettre à jour Cesium et les autres outils en même temps. Ça peut être l’occasion, de toute façon il faudra mettre à jour la licence dans les clients.
1 Like
Perso je trouve que le terme « membre » convient très bien, je ne vois pas pourquoi le changer.
Pour le reste je ne vais pas m’impliquer dans le travails rédactionnel, mais quand une MR sera ouverte sur le gitlab je ferai une review
Le sujet du mot « membre » est discuté ici.
C’est pour éviter de donner l’impression que la monnaie est réservée aux membres d’un groupe fermé. On est membre d’un groupe, ou on n’est pas dans le groupe. Alors qu’on peut utiliser la Ğ1 sans la cocréer. On peut être membre de groupes junistes sans être membre selon la blockchain.
Ça permet aussi de se démarquer de certaines utilisations générales et parfois abusives du mot « membre », avec un terme plus concret : membre d’un site Internet (càd abonné aux newsletters), membre d’une secte…