Bonsoir Sylvain, Quelques première réponses.
Sylvain Chevillard <[EMAIL PROTECTED]> writes: > Je voudrais réagir aux différentes interventions de Vincent Becker qui > me semble soulever des points importants. Je vous préviens, c'est > long. Mais c'est parce que ça fait pas mal de temps que j'accumule des > remarques et je n'ai jamais pris le temps de les formuler auparavant. La prochaine fois, ce serait pas mal de fragmenter les différents points en différents emails, comme l'a fait Vincent, pour faciliter les réponses et permettre des créer des threads spécifiques. > Cela signifie que le logiciel ne doit pas être développé > dans l'objectif unique du projet « Expérience démocratique » mais bien > avec le soucis de généralité qu'on peut attendre d'un tel logiciel. Disons que faire un logiciel générique n'est pas non plus simple ni à coût nul, donc c'est un équilibre permanent entre nos propres besoins et des contraintes « externes ». Mais il est vrai que des expériementations extérieures nous aideraient peut-être (tant pour le logiciel que pour le projet politique). > À ce propos, je voudrais introduire ici une comparaison entre demexp et > wiki. Les divers logiciels wiki ont été écrits dans l'idée de > développer wikipedia, Le concept de wiki est bien antérieur à Wikipedia ;-) http://fr.wikipedia.org/wiki/Wiki > mais pour autant, l'outil a été conçu pour être > le plus souple possible de façon à ce qu'on puisse déployer des wikis > dans d'autres contextes. La préoccupation n'était pas inutile : pour > preuve les wikis qui fleurissent sur les sites de différents projets > logiciels (demexp en premier lieu). La souplesse d'un logiciel est généralement obtenue par raffinement successifs. Mais il faut des développeurs pour raffiner un soft. :-) > Cette comparaison m'amène à une autre réflexion : la question des > droits. Dans un soucis de démocratie la plus large possible, vous vous > interdisez la création de droits particuliers pour certains > utilisateurs. Comme le fait remarquer Vincent, ça bride l'usage du > logiciel. J'ajouterai qu'introduire la notion de droits ne signifie pas > qu'on est obligé de les utiliser de sorte qu'il vaut mieux avoir un > logiciel qui permet de gérer de droits que non. Entièrement d'accord. > Mais surtout, regardez les wikis : n'est-ce-pas là un logiciel qui a > pour vocation la totale liberté d'édition par tous ? Pourtant le > logiciel a été conçu pour permettre l'utilisation de droits, et > l'usage qui en est fait (même s'il est le plus limité possible) permet > une bonne régulation des contributions et facilite l'utilisation du > logiciel. Je pense donc qu'il faudrait réfléchir sérieusement à cela > pour introduire la fonctionnalité dans les futures versions. Cela a été un des sujets de discussion de la dernière réunion. Jérémy et moi-même allons essayer de voir ce qu'on peut faire pour avancer concrêtement. > - Une réponse systématique à toute question : « cette question est sans > objet » Déjà fait. :-) La réponse « Question rejected » de toute question. Évidemment, avoir une réponse configurable et en en français pourrait être un plus. ;-) > - Possibilité de fermer le vote de certaines questions Fonctionnalité de limite temporelle de vote. Prévu depuis le début mais jamais codée. > Lorsque le vote est fermé, les questions, > leurs réponses et la position de la base à leur sujet doivent rester > visibles, mais dans une autre rubrique du logiciel. Idée intéressante. En gros, changer la classification automatiquement à la fermeture du vote. Je le note. > - Sur la navigation dans l'interface, il y a beaucoup de choses à > dire, :-) > mais je pense que ça viendra dans (très) longtemps. Il faudra à terme > pouvoir faire des liens hypertextes entre questions, associer à chaque > question et à chaque réponse un lieu de débat (nous avions commencé à y > réfléchir avec un copain. C'est assez délicat. À l'occasion je vous > soumettrais nos idées là-dessus). Oui. Il faut absolument que je créé une page web pour y mettre nos propres idées. Pour résumer grossièrement : un site web de débat contraint, où la même place est accordée à chacun, avec authentification forte, et un espace libre, style-genre wiki, sorte de page perso pour tout participant. > Il faudrait qu'il y ait un classement des questions en différentes > rubriques, à la base même de demexp de façon à différencier clairement > des choses qui n'ont rien à voir. Le système actuel n'est pas parfait mais c'est quand même le cas dans le serveur officiel. > Par exemple, les questions classées, les questions urgentes, les > questions de fond, les questions concernant l'application de décisions > prises par la communauté, que sais-je... De manière générale, la > catégorisation des questions est la plus grosse faille de la version > actuelle de demexp d'après moi. Plus précisemment, quelle critique tu lui portes ? > Au fait, une question doit pouvoir être classée > dans plusieurs catégories ou sous-catégorie. C'est déjà le cas. Nous avons une classification par « tags », plusieurs tags pouvant être attachés à une même question. > Il y a aussi les méta-questions : « doit-on considérer que la question > machin n'a plus lieu d'être ? » par exemple. Il faut songer à mettre > en place un nombre de voix exprimées minimal pour que la base prennent > position. Je considère que ce genre de système relève plus de la politique autour du serveur que du logiciel proprement dit. À noter que le client 0.7 affiche le nombre de votes sur une question. > Bien sûr dans très long temps, il faudra inclure un moteur de recherche > malin, un moyen d'avoir une vue globale de la base avec ses différentes > rubriques. Il suffit juste d'attendre que Google s'intéresse à nous. ;-) > À terme, il faudrait qu'il y ait une rubrique : « questions sur > lesquelles vous ne vous êtes pas encore exprimées », ou encore « > questions datant de moins de tant de jours ». Oui. À noter tout de même qu'en cliquant sur un intitulé de colonne du client GTK, on peut classer les items suivant ce critère (par exemple sur V pour voir regroupées toutes les questions votées/non votées). À long terme, j'aimerai bien qu'on puisse utiliser la technologie LIS pour naviguer dans la base : http://article.gmane.org/gmane.politics.organizations.demexp.devel/736 > - À propos de la délégation, au moment où elle sera mise en place, il > faudra à ce qu'on puisse déléguer une question particulière ou bien > tout une catégorie de questions. C'est prévu. La délégation se fera tag par tag. Il y a un gros problème de gestion de conflits à résoudre : http://article.gmane.org/gmane.politics.organizations.demexp.devel/547 > Il faut bien sûr pouvoir déléguer les > réponses à différentes personnes suivant les questions C'est prévu. > Il faudra > pouvoir voir rapidement les questions qu'on a déléguées et quelles > réponses y ont été faites. C'est prévu, la boucle de rétro-action étant à la base de demexp. Par contre, l'interface utilisateur pour faire ça simplement n'est pas évidente. Si tu as des idées... > En particuliers, il faut une rubrique « > changements de position prises par vos délégués depuis la dernière fois > ». Intéressant (mais comme toujours, compliqué à coder côté client). > Cette dernière fonctionnalité est indispensable pour éviter les abus > du genre : je délègue à Machin qui prend une position qui me plaît bien > mais qui, dès que j'ai le dos tourné change d'avis sans me le dire. On compte un peu sur le bouche à oreille et autres moyens « hors bande » pour éviter ce genre de comportement. > La délégation ne doit bien évidemment pas empêché que je donne ma > propre opinion plutôt que celle de mon délégué si je ne suis pas > d'accord avec lui ponctuellement. Yep. > Au fait, une réflexion qui m'est venue : la délégation n'est pas > forcément quelque chose d'unilatéral. Lorsque je délègue mon vote à un > ami qui a les même idées que moi, il pourrait vraisemblablement me > déléguer lui aussi les mêmes questions. Oulà, difficile ! Ça crée des cycles dans le système de délégation. A priori, je ne vois pas comment permettre ce genre de système. Déjà, avec un système sans cycles, c'est pas simple (cf. mon message ci-dessus). > Dans ce cas, on est dans une > situation où l'on décide à plusieurs de se répartir le travail : > n'importe qui de Bidule ou de Machin a le droit de répondre à telles > questions et lorsqu'il prend position, cela prend simultanément > position pour Bidule et pour Machin. Ainsi, on peut se regrouper en > courant de pensée et traiter à plusieurs toutes les réponses à une > catégorie de questions où on sait qu'on est tous d'accord. Pour ce genre de comportement, on peut imaginer qu'un individu, par exemple François H., demande qu'on lui délégue les questions et qu'il votera on fonction des positions de son groupe. On peut aussi imaginer que le groupe utilise son propre serveur demexp pour prendre des décisions. > - De manière générale, tout ajout de question ou de réponse dans la > base, ou toute modification de formulation doit être traité avec le > plus grand soin : par exemple, lorsqu'on ajoute une réponse à une > question, il est délicat de considérer que les votes précédents > tiennent toujours car l'introduction d'une réponse nouvelle peut > changer la donne. D'un autre côté, on ne peut pas remettre à zéro tous > les votes à une question sous prétexte qu'une réponse à changer. Exactement. > À > cela, je vois deux solutions, non mutuellement exclusives. La première > est une information systématique et automatique des gens lorsqu'une > question ou une réponse change dans la base (cf. idées développées plus > haut). C'est déjà en parti fait. Il y a un flux RSS associé à la base. Pour l'instant, le format est un peu pas terrible et mériterait d'être amélioré (notamment revenir au vieux format où on distinguait facilement nouvelle question et nouvelle réponse). > La deuxième est d'introduire une catégorie « Question en cours > d'élaboration » qui permet de nettement séparer la phase de préparation > des questions et de leur réponses et la phase de vote. Je penche très > fort en faveur de la mise en place d'un tel système. Pour le projet politique, ce n'est pas ce qu'on (le core team) veut mais rien n'empêche d'utiliser la classification pour le faire (cela relève de la politique du groupe social). Avec une gestion de droits un peu plus fine, on devrait pouvoir réaliser la politique que l'on veut. > À ce propos, ça me permet de dire qu'il serait agréable de pouvoir > modifier la formulation d'une question ou d'une réponse, de supprimer > une question ou une réponse à tout moment. Pour éviter les abus, je > milite pour l'introduction de droits (par exemple, seul un collège > d'administrateurs a le droit de faire ce genre de modifications ; si on > veut, on peut mettre en place des systèmes sophistiqués du genre : on > soumet d'abord au vote une autorisation de modification. Évidemment, le > risque est rapidement de tomber dans de la lourdeur administrative). Cf. réponse ci-dessus, on va voir ce qu'on peut faire pour les droits. > - À propos de sécurisation : ce n'est pas indispensable dans un premier > temps, même si sur un projet politique à grande échelle, c'est > indispensable. Yep. > Mais dans le cadre de petites structures, généralement, > on se fait confiance. Par conséquent, l'effort principal ne devrait pas > être porté là-dessus d'après moi. D'autant qu'en concevant bien les > interfaces de communications, ce ne sera rien que de rajouter une > couche de SSL le temps venu. Surtout que quelqu'un bosse déjà dessus. ;-) Gerd Stolpmann, le développeur de la couche ONC RPC en OCaml, est en train de travailler sur une version qui tourne sur SSL. > À ce propos, j'attire votre attention sur une faille possible de la > méthode Condorcet en matière d'anonymat. Quelqu'un qui veut forcer le > vote peut s'y prendre ainsi : on introduit une quinzaine de réponses > pipeau. Puis, on le chef de la mafia va voir Bidule et lui dit : « les > questions pipeau, tu les mets à la fin de ton vote, et dans l'ordre > précis que voilà. En première position de ton vote, tu votes pour moi > ». Comme il y a 15! possibilités, ça permet à la mafia de donner une > signature unique à chacun. Si elle a accès au dépouillement du > serveur, Heuu... le chef de la mafia n'a pas accès au serveur. Mais pour la sécurité à long terme, il faudrait que même s'il avait accès au serveur il ne puisse pas comprendre les votes (cf. mon autre réponse sur cette liste). > elle peut alors savoir qui a suivi ou n'a pas suivi la consigne de vote > et aller flinguer qui de droit. La ruse est indépendante de la > sécurisation des transactions. D'aucun diront, il suffit alors > d'interdire à la mafia de voir le dépouillement. Mais alors on a un > grave problème de publicité de la méthode : comment savoir si le > serveur qui dépouille (qu'on n'a pas le droit de voir dépouiller) n'est > pas un serveur trafiqué par la mafia qui élit toujours le chef de la > mafia quoiqu'il arrive ? > Bref, il y a là quelque chose d'assez délicat à propos duquel je n'ai > pas trouvé de solution satisfaisante. Il y a plusieurs pistes possibles (cf. les archives de demexp-dev) : hash du binaire sur une infrastructure de type Trusted Computing (cf. le matériel d'IBM), avoir des assesseurs pour vérifier que la mise en route est correctement faite, etc. Beaucoup de points intéressants à creuser. :-) > - Où en est l'interface Web ? Ça me semble une bonne chose de la mettre > en place. Mais ce n'est pas forcément urgent. http://www.linux-france.org/cgi-bin/demexpweb.cgi C'est une interface « brut de pomme ». :-) > - Je finirais par une remarque sur le vote Condorcet : il a trois > défaut. > Le premier est de demandé de classer des réponses plutôt que de juste > donner une réponse. À la longue, ça peut être fastidieux. Pour une fois, je trouve que l'interface de mon soft est pas trop nul sur ce point. Non ? > Néanmoins, si le logiciel est bien pensé et si le système de > délégation fonctionne efficacement, je pense que le problème > disparaît. Oublions donc ce point. Chouette. :-) > Le deuxième défaut est qu'il oblige les gens à classer sur une même > échelle des réponses qui leur conviennent et des réponses qui ne leur > conviennent pas. Ainsi, aux présidentielles, je préfère Bidule à > Machin, mais je les aime bien tous les deux, alors que je n'ai pas du > tout Truc. Cependant, il faut préciser que Truc serait moins pire tout > de même que Chose, qui vraiment n'est pas bien du tout. Ça demande > beaucoup de pédagogie d'expliquer aux gens qu'il faut classer les gens > qu'on aime bien et les gens qu'on aime pas sur une même échelle sans > indiquer où commencent les gens dont on ne veut pas. Le « je ne veux pas » est toujours relatif. Normalement, le vote Condorcet permet justement de faire cette gradation fine entre les réponses. Le seul (gros ?) inconvénient de l'interface actuelle, c'est qu'elle ne permet pas de mettre des réponses ex-aequo (alors que le vote Condorcet le permet). > Je pense que ça amène une certaine méfiance vis-à-vis du système de > vote. Donc il faut faire de la pédagogie. Pourquoi ne pas enrichir le guide du votant ? http://www.demexp.org/fr/doku.php?id=guide_du_votant > Troisième défaut : que faire lorsqu'aucun candidat Condorcet ne se > dégage et qu'on a un ensemble de Schwarz non trivial ? Là, il y a > plusieurs variantes possibles et le choix de l'une d'elle est > arbitraire. Dans ce cas, le logiciel sorte toutes les réponses de l'ensemble de Schwarz. C'est au groupe social de décider comment il résoud le conflit, si conflit il y a (nouvelle question, non décision, ...). > Je propose donc deux choses : d'abord que le choix de la méthode de > vote soit fait de façon bien modulaire dans le code de façon à ce que > tout un chacun puisse avoir le loisir de changer la méthode lorsqu'il > met en place un serveur demexp pour un besoin particulier. On pourrait > alors proposer par défaut avec demexp plusieurs systèmes et > l'administrateur de la base ferait son choix au moment du déploiement > du logiciel. En outre n'importe qui pourrait facilement écrire son > propre module sans avoir à lire tout le code de demexp. Ça nécessite de > bien documenter le module « méthode de vote ». Je ne suis pas contre ce genre de modification mais : - faire une bonne interface générique est un boulot *très* difficile ; - si une méthode de vote a besoin de stocker des informations particulières (vote par système de points par exemple), cela nécessite de stocker ça de manière générique et c'est pas simple ; - [raison récurrente] il faut du temps pour le faire. ;-) > Quant à moi, je me demande si on ne pourrait pas résoudre les deux > derniers défauts soulevés de la manière suivante : les gens font deux > listes : une liste de réponses auxquelles ils adhèrent et une liste de > réponses auxquelles ils n'adhèrent pas. Les deux listes sont > ordonnées. Pour choisir la réponse gagnante, on fait d'abord un vote > Condorcet en concaténant les deux listes. Si un candidat Condorcet se > dégage, c'est le vainqueur. Sinon, on choisit le vainqueur dans > l'ensemble de Schwarz en faisant un vote par assentiment : pour chaque > votant, on ne considère plus que la liste des gens auxquels il adhère > et on les met ex-aequo. Celui de l'ensemble de Schwarz qui totalise le > plus de voix gagne le vote. > Il me semble qu'on bénéficie ainsi à la fois des avantages du vote > Condorcet et du vote par assentiment. Mais je m'étonne de n'avoir > jamais entendu parler d'un tel protocole. En tout cas je trouve que ça > mériterait qu'on y réfléchisse parce que ça permet de régler les deux > défauts principaux de la méthode Condorcet. Joker. :-) > Voilà. Ce fut long, mais c'est le fruit d'un an de réflexions autour de > demexp. J'espère que ce sera profitable. C'est profitable. Mais la prochaine fois, distille tes réflexions en blocs un peu plus digéreables. ;-) Je t'engage à utiliser le wiki pour documenter les différentes pistes qui t'intéressent (méthode de vote, etc.). > Au fait, il n'est pas exclu que je me mette à coder pour demexp un jour > ou l'autre. C'est juste que pour l'instant, je n'ai pas tellement le > temps. Dommage. :-) > Bon courage aux développeurs. Merci. ;-) Amicalement, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- Liste de discussion demexp-fr. Pour se désinscrire, cliquer sur le lien ci-après. mailto:[EMAIL PROTECTED]
