Avant de lire la suite, merci d’aller voir la proposition principale qui indique l’intention et la structuration des différentes propositions.
Notre intention concernant les règles de modifications de la licence Ǧ1 :
Légèrement ajuster la forme sans changer le fond pour rendre la modalité actuelle plus simple à comprendre et à utiliser.
Reporter à une évolution ultérieure les changements significatifs du processus de modification.
Les ajustements :
L’heure de départ de la période de 30 jours, n’est plus l’heure de publication de la proposition du vote sur le forum, mais l’heure du premier vote (plus robuste avec la possibilité de vérifier en blockchain)
Nous avons précisé le montant recommandé : 0,01G1 (pour éviter de se questionner sur le montant alors que ce n’est pas l’enjeu)
Nous avons choisi arbitrairement la caisse rémuniter comme destination des centimes de Ǧ1 collectées à l’occasion du vote pour éviter de polémiquer sur la destination de ces quelques Ǧ1 alors que ce n’est pas l’enjeu.
La proposition d'ajustement des ''Règles de modifications''
Règles de modifications du présent document
Note introductive :
Les personnes qui émettent des propositions, qui les soutiennent ou qui les votent doivent être membres de la TDC.
Processus :
Étape optionnelle : Il est possible de partager son processus d’élaboration d’une proposition sur les plateformes de communication de la Ǧ1 (forum Monnaie Libre, forum Duniter, Télégram monnaie libre…).
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 présentant la proposition et indiquant les clefs publiques associées à chaque options de vote.
Mettre en premier commentaire le texte exact proposé à l’adoption
Toute modification (réédition) du premier commentaire entraine l’annulation du vote.
Les personnes votantes sont invitées à se prononcer par virement depuis leur compte membre vers le compte associé à leur choix de vote. 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.
le vote est cloturé 30 jours après le premier vote émis pour cette proposition. les résultats sont dépouillés comme suit :
La proposition est adpotée s’il y a au moins 5 votes « pour » par vote « contre » (soit 83% de « pour » minimum) en plus des 20 premiers votes « pour ». (Exemple: 25 « pour » si 1 « contre », 30 « pour » si 2 « contre »…)
Si les conditions d’adoption ne sont pas réunies, la proposition est rejetée.
Le montant associé à un vote n’impacte pas sa validité (somme conseillée : 0.01 Ǧ1)
Une fois le vote clos, les organisateurs du vote s’engagent à reverser les junes à la caisse remuniter : TENGx7WtzFsTXwnbrPEvb6odX2WnqYcnnrjiiLvp1mS:AXW
Cependant, le destin des Ǧ1 collectées lors du vote n’impacte pas la validité du vote.
Vivement le système de vote directement branché sur l’authentification duniter
Comment tu fais pour vérifier si les transactions proviennent de comptes certifiés ? tu as une ligne de commande ?
Comme ce n’est pas précisé, je déduis que :
« j’ai le droit de changer d’avis, pour le faire il me suffit de poser un centime de Ğ1 sur l’autre option pour annuler et refaire cet acte une seconde fois pour exprimer mon vote »
Tu confirmes ?
En général, le post ne contient pas seulement le texte proposé à l’adoption, mais aussi d’autres informations (comme, par exemple, des explications sur la manière de voter ou sur la motivation de la proposition).
Il faudrait que le premier post puisse être modifié sans que cela n’entraîne l’annulation du vote, à condition que les modifications ne portent pas sur le texte proposé à l’adoption.
Ceci serait dans le post initial. Le premier commentaire à ce post initial serait le texte intégral sur lequel on vote, et c’est pour ça que ce premier commentaire ne pourra pas être modifié.
On avait envisagé aussi cette option mais pour plus de simplicité, pour l’instant on a pensé ça comme ça, ce qui n’empêche pas de changer. @elois et @1000i100 ont bossé sur le logiciel qui comptabilise les votes et j’imagine qu’il suffirait de le programmer dans ce sens (un compte membre qui a voté plus de fois « pour » que « contre » comptabilise un vote « pour » et vice-versa)
Je réponds dans le sujet. C’est mieux que ce soit une heure blockchain plutot que l’heure du forum.
J’apporte un complément. Je constate en faisant des transactions que l’heure blockchain présente un net décalage par rapport à l’heure Temps Universel sur laquelle est réglée mon ordinateur.
Aux développeurs: Les ordinateurs faisant oeuvrer des noeuds duniter1 sont-ils synchronisés par NTP?
Ah mince! Justement, on s’était posé la question, et il me semble que @1000i100 avait bien vérifié que la blockchain avait cette précision horaire et aussi qu’elle respectait le décalage horaire (pardon si je dis une bêtise ou si j’enfonce une porte ouverte, je n’y connais rien en blockchain).
Par exemple si je fais une transaction à 15h en été en France, elle apparaîtra au Paraguay comme faite à 9h.
Il faudrait peut-être ajouter dans les règles de modifs le conseil suivant :
« Si les organisateurs du vote indiquent dans leur communication l’heure de fin de vote, il faudra indiquer une heure UTC. »
Quand je fais une transaction, quand tout marche bien ce qui est le cas huit fois sur dix, elle est enregistrée au bloc suivant. Chaque bloc étant séparé de cinq minutes du précédent. Et c’est cette heure blockchain qui fait foi.
Je constate qu’il y a suivant les noeuds, un décalage de moins ou plus vingt minutes.
Je ne parle pas des heures en plus ou en moins qui dépendent des fuseaux horaires. Il s’agit de minutes et pas seulement d’une ou deux.
Ça c’est le client qui fait la conversion. La blockchain, elle, a des données figées.
J’ose espérer que non puisque notre monnaie étant internationale, il faut faire fi des lieux des uns ou des autres. C’est ma logique. Après je sais que peu de monde pense en international, le local perdure. Mais pour quelque chose d’universel je pense que ceci coule de source.
Ça devrait changer avec la V2? Mais même si c’est le cas, si le vote se fait pendant la V1, il va falloir régler ce point, en effet.
Oui en effet, c’est logique.
Quand je disais « heure locale » je voulais dire heure locale de celui qui utilise le logiciel, c’est à dire qu’il affiche l’heure de fin de vote adaptée au fuseau horaire ou alors il faudrait qu’il précise que c’est l’heure UTC.
En fait j’avais en tête deux choses différentes : l’heure de la blockchain, qui fait foi pour le vote, et l’heure qu’affichent les logiciels qui vont montrer ces données. Par exemple, quand je parlais des différents pays, je pensais par exemple au cas où un retardataire voudrait voir s’il a encore le temps de voter. Beaucoup d’utilisateurs penseraient à aller voir l’heure du premier vote sur le compte Césium dédié, mais pas dans le bloc, juste sur l’affichage des opérations. Ou alors ils iraient voir aussi sur le site de décompte des votes j’imagine.
On ne peux pas l’obliger, mais en général c’est le cas.
Le décalage viens, en V1, du fait que l’heure blockchain est calculée selon la moyenne (ou médiane) des heures enregistrées dans les blocs de la fenêtre courante, hors avec 1 bloc toutes les 5 minutes, le temps blockchain se retrouve avec un certain retard. On essai de le compenser avec une heuristique (on rajoute 1h au temps UTC je crois) mais ça laisse q uand même quelques décalage.
Selon moi ce n’est pas grave pour les votes pour la raison suivante :
Dès lors que le comptage du temps se fait sur le même référentiel pour le début et la fin du vote, Qu’il y ai 20minutes ou même 3h de décalage dans l’affichage ne change rien au fait qu’il y a bien 30 jours entre l’ouverture (par le premier vote en blockchain) et la fermeture (30jours plus tard) des votes. Pour éviter la confusion, le logiciel d’affichage du comptage intègre l’heuristique de réajustement pour réduire l’écart entre le temps local et celui blockchain, mais ça n’influe pas la durée du vote.
