Désolé, ça fait pas mal de messages destinés au @technical-committee en deux jours.
Actuellement, le seuil minimal pour effectuer un runtime upgrade est fixé à 2/3 des membres du comité.
Étant donné que, parfois, exécuter un runtime upgrade est nécessaire pour corriger un bug critique en production, je propose d’abaisser ce seuil à 1/3, en prévision pour la Ğ1, afin de donner plus de liberté au comité et de permettre de faire passer plus rapidement des runtime upgrades en cas de correctif critique.
À terme, l’idéal serait de pouvoir différencier les types de runtime upgrade avec des seuils distincts, accompagnés de droits de veto possibles. Mais pour l’instant, cette proposition me semble représenter un juste milieu entre un sudo unique ayant tous les pouvoirs et un comité trop complexe et protocolaire.
Ce seuil pourra être relevé plus tard, lorsque les processus de gouvernance auront été mieux rodés en production, que le comité se sera élargi et que nous aurons gagné en confiance dans ce mécanisme.
Cette proposition n’est pas indispensable et ouverte aux débats.
Je ne suis pas convaincu. Ça veut dire que tu veux pouvoir enclencher des modifs alors que seule un minorité du CT est OK. Je vois l’intention mais c’est se tirer une balle dans le pied à mon avis.
Ben non, parce que les mêmes arguments pourront être réutilisés (réactivité pour la correction de bugs critiques).
À mon humble avis les membres du CT doivent s’engager à une forme d’astreinte pour agir sur la réactivité plutôt que sur le seuil de validation.
Je ne sais pas si c’est possible, je me demande un truc.
Voici mon idée
La proposition est acceptée ou rejetée si 2/3 ont voté dans les 24h,
Au bout de 72 heures, si la moitié a voté, le vote est pris en compte
Et au bout 128 heure 1/3 de votant suffit pour valider le vote.
Éventuellement, prévoir une exclusion automatique du CT des personnes qui n’ont pas participé aux 5 derniers votes.
Les chiffres sont au pif, mais l’idée est que si les membres du comité technique dorment, les votent peuvent être validé au bout d’un peu plus de temps. Et on ne compte plus sur ceux qui font le mort.
Il faudrait fourcher une palette mais oui c’est codable.
Pour se laisser la possibilité de voter des propositions non urgentes, il faudrait que ce mécanisme soit optionnel.
Pour éviter qu’une minorité en profite pour prendre le pouvoir au moment où les autres sont en vacances, il pourrait y avoir un veto de l’exécution anticipée dès 1 vote contre :
après 24h, si 0 contre et 2/3 pour, alors on accepte
ensuite, les règles déjà proposées
Mais ce “veto d’urgence” a l’inconvénient d’obliger à attendre un certain temps avant d’accepter, même si le “seuil d’urgence” est atteint rapidement.
J’abonde. Il ne faudrait pas que l’on confonde vitesse et précipitation car nous sommes humains et que même un correctif “urgent” nécessite un certain contrôle pour éviter le sur-accident.
Si le correctif est urgent on doit pouvoir solliciter le CT à toute heure.
Pour la ĞTest l’astreinte de nuit me semble un peu extrême, mais pour la Ğ1 on peut s’accorder sur un système de sollicitation comprenant différentes plateformes et différents niveaux d’urgence dont la sollicitation de nuit.
