compte rendu de réunion

Eric Daspet <[email protected]> Thu, 20 May 2004 16:58:46 +0200
Newsgroups gmane.comp.web.blogv2.devel
Message-ID <[email protected]>
Bon, j'ai eu un peu de mal à rédiger et ça sera probablement coloré avec 
mes opinions. Que chacun n'hésite pas à commenter brièvement si besoin est.


Tout d'abord le constat :

On a fait pas mal de discussions mais globalement en plusieurs mois on 
n'a toujours pas réellement de code, et rien qui marche. Pire, 
visiblement aucun de nous n'est bien certains de ce que comprend les 
autres ou de la vision globale de l'ensemble.

Quelques points qui ont été soulevés :

Il n'est pas envisageable de continuer ainsi si on veut quelque chose 
avant 2020. Personnellement si on n'arrive pas à rétablir un 
fonctionnement efficace je juge qu'il vaudra mieux arrêter les frais que 
de perdre du temps pour rien.

Étant donné la base de code qu'on a, si on se rend compte que pour 
redresser la barre il faut jeter le code existant ou partir sur d'autres 
bases c'est envisageable facilement


Les raisons :

Globalement je crois que c'est Loic/bballizlife qui a soulevé le point 
important : il faut faire un schéma global et une documentation efficace 
pour avoir les lignes directrice et ne pas partir n'importe où.

Le deuxième point est un peu lié, il s'agit de ne pas s'engager dans 
trop de fonctionnalités et d'idées avant d'avoir déjà quelques chose qui 
marche.

Après il y a le manque de temps, de motivation, mais ça ça va et ça 
vient régulièrement.


Ce qu'il y a a faire et solutions proposées :

Déjà il serait bien que quelqu'un qui veut participer se charge de faire 
une doc succinte sur le fonctionnement général de l'appli. Je parle là 
de quelqu'un autre que nous trois. Lui ça lui permettrait de comprendre 
ce qu'on fait et de s'impliquer, nous ça nous permettrait d'avoir 
quelqu'un avec une vision claire. Nous sommes chacun trop impliqués avec 
nos idées à nous pour pouvoir le faire efficacement.

Il serait bien aussi de restructurer le projet. définir des objectifs 
sérés et précis pour chaque étape. Définir les documentations pour tout 
ce qu'on veut faire pour chaque étape *avant* de le commencer. Bref, pas 
de code qui ne soit pas directement déjà discuté et commenté *en détail* 
et prévu sur la prochaine étape.

Éventuellement j'ai proposé de quitter le serveur actuel pour regrouper 
subversion et wiki sur une même plateforme avec l'utilisation de "trac". 
Si on est d'accord ça peut imposer d'utiliser les possibilités de 
création de timeline et tickets pour savoir ce qui est documenté, à 
faire ou pas à chaque fois. En gros ne coder quelque chose que en 
réponse à un ticket documenté et approuvé. Il s'agit alors de forcer le 
point précédent (documentation et codage uniquement des parties 
nécessaires et prévues). La plateforme est installée 
(blogv2.survol.net), reste à décider si on l'utilise ou pas en se 
contraingnant à ça.

Réunion dimanche à 14h (Paris) sur IRC (#blogv2 réseau freeenode.org) 
pour faire le point et prendre les décisions.



Les commentaires sur ces propositions ou les autres idées sont les 
bienvenues, de tout le monde

-- 
Eric Daspet