demexp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Demexp-dev] Re: Diverses remarques sur le projet web de Jean-Marc Fauch


From: David MENTRE
Subject: [Demexp-dev] Re: Diverses remarques sur le projet web de Jean-Marc Fauché
Date: Sun, 10 May 2009 12:54:57 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Bonjour Jean-Marc,

Fauché Jean-Marc <address@hidden> writes:

> Concernant le fait de "tout reprendre à zéro" : En fait il m'a semblé
> plus simple de tout regrouper au sein du même outil (web2py) qui permet
> de gérer l'ensemble base de donnée + code + html + css + utilisateurs +
> groupes.

Justement, je pense (mais ce n'est que mon avis ;-) que tu es en train
de refaire la même erreur que moi : tout grouper dans un même logiciel
qui devient trop compliqué et incompréhensible pour les autres
contributeurs.

Quelqu'un un jour a fait la remarque que tous les gros logiciels libres
qui ont marché sont modulaires : Apache et ses modules, le noyau Linux
et ses drivers, etc. Je pense qu'il faudrait qu'on fasse la même chose
avec demexp.

Pour le logiciel demexp dans l'expérience démocratique il faut :

 - la *base des questions et des réponses*, avec des informations
   attachées (visibilité pour le spam et les atteintes au droit, qui a
   posé la question et la réponse, etc.) ;

 - la *base des participants* avec des attributs : authentification,
   droits d'administrateur ou de modérateur, veut être un délégué ou
   pas, etc. ;

 - un module *d'authentification* des participants qui utilise la base
   des participants ;

 - *l'enregistrement des votes* des participants qui utilise le module
   d'authentification tout en garantissant l'anonymat ;

 - un *module de vote Condorcet* qui parcourt les votes et calcule les
   résultats de chaque question ;

 - la *délégation* : telle question est déléguée par tel participant à
   tel autre (délégation transitive et gestion de la circularité) ;

 - un (ou plusieurs) module(s) de log qui enregistre ce que fait le
   système, pour la transparence et la gestion au quotidien (gestion
   d'une attaque par exemple) ;

 - un module *d'administration* : ajout/retrait de participants,
   modération des questions et réponses, gestion des logs, etc. ;

 - une interface web qui rend accessible sur le web :
    - base des questions et réponses,
    - authentification,
    - enregistrement des votes,
    - résultats des calculs Condorcet,
    - délégation,
    - logs (suivant degré d'authentification),
    - administration.

À mon humble avis, il serait plus judicieux de mettre toutes ces
fonctionnalités dans des modules distincts qui communiquent entre eux
par des interfaces standardisées (en SQL, en ONC-RPC ou autre) et bien
définies.

Après, chacun pourrait développer un module ou un autre, dans le langage
de son choix, avec ses propres contraintes et objectifs.

Un exemple : l'interface web doit déjà faire beaucoup de boulot. Ce
serait génial d'avoir une interface standard à la base de questions
comme ça quelqu'un pourrait développer un module web sophistiqué de
navigation anonyme dans les questions et réponses sans avoir à tout
comprendre tout un système monolithique.

Il faut prendre un peu de soin pour bien définir ces interfaces (pour
gérer correctement l'anonymat par exemple) mais une fois ceci fait, on
aura une architecture bien claire.

Qu'est-ce que tu en penses ?

Bon, dans tous les cas il faudra que je fasse une spécification de tout
ça. :-)

> Concernant le vote par condorcet :je me suis borné à mettre en place la
> méthodologie décrite dans la constitution Debian dont j'ai trouvé le
> lien dans "demexp-book".Mais je suis d'accord avec toi que son
> utilisation est un peu "redondante"...En tout état de cause on tombe sur
> le même résultat s'il n'y a pas d'ambiguïté , sinon effectivement on
> n'est pas obligé de la lever avec un algorithme et laisser le soin aux
> votants de le faire (sauf qu'en cas de date limite il faudra prévoir des
> prolongations...).

Ok. Je voulais juste souligner qu'en y réfléchissant je me demandais si
l'algo des ensembles de Schwartz est vraiment nécessaire. Je n'ai pas de
réponse définitive.

> Concernant l'enregistrement "ouvert" :Effectivement un utilisateur peut
> à priori s'enregistrer  sous  plusieurs  login  et  email  différents
> mais  je ne vois pas de solution  .Cependant  il est prévu que
> l'utilisateur reçoive un email de confirmation ce qui limite un peu le
> risque .

Il est facile de créer plusieurs emails. Mais pour l'authentification
nous n'avons pas de solution. On était parti sur l'utilisation d'un acte
de naissance, mais ce n'est probablement pas suffisant.

> Concernant le fait de "vouloir vérifier manuellement l'inscription ":je
> n'ai pas bien compris ce que tu entend par là ! pour pouvoir voter
> l'inscription est automatiquement vérifiée (pas à la main bien sur ...)
> et seul le mot de passe est codé , les administrateurs peuvent à tout
> moment examiner la liste des inscrits sur la base de donnée via
> l'interface d'administration de web2py .

Je me suis mal exprimé. Ce qu'on veut, c'est vérifier manuellement
l'ouverture des comptes. D'après ce que tu dis, on peut le faire a
posteriori. Ce serait bien, pour le demexp « officiel », d'avoir un mode
a priori, càd ouverture de compte en attente à vérifier.

Mais ce n'est que mon avis, Fred et Félix peuvent être satisfait du mode
de fonctionnement actuel (vérif' a posteriori).

> Concernant mon code : Il y aura forcément des choses à revoir mais c'est
> un "premier jet" ...merci d'avance pour votre indulgence .

Bien évidemment !

Le logiciel actuel n'est pas satisfaisant et je n'ai aucun soucis de le
remplacer par un autre qui marcherait (de toute façon ce n'est plus moi
qui décide :-D ). Mais comme j'ai quand même codé quelques années sur le
projet, j'essaye de te faire part de mon expérience. demexp c'est super
intéressant car il y a toute l'informatique. Mais il y a quand même
quelques subtilités dans les coins. ;-)

Amicalement,
d.
-- 
GPG/PGP key: A3AD7A2A David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A




reply via email to

[Prev in Thread] Current Thread [Next in Thread]