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