Subject: Re: [Agora-generale] Avenir, avenir....
Newsgroups: gmane.comp.web.spip.devel
Date: 2004-12-09 11:07:39 GMT (3 years, 51 weeks, 2 days, 2 hours and 39 minutes ago)
Christian Lefebvre a écrit : Ça fait des semaines qu'on n'entend plus parler d'agora et d'un coup, > c'est la grande unification ! un résumé des épisodes précédents > s'impose je crois. Pour ce que j'en ai compris (je suis passé rapidement le matin à la réunion agora) on peut résumer grossièrement comme cà : - Il y a deux ans, le SIG initie le projet AGORA dont le but est de proposer aux administrations un logiciel libre de gestion de contenu commun, de manière que les établissements publics ne payent pas n-fois le même genre de développements pour leurs différents sites. - Le SIG s'appercoit que SPIP est presque bon tel quel pour être ce moteur de site, mais qu'il manque quelques possibilités pour les usages administratifs de gros sites, notamment le fait d'avoir un processus de validation en 4 étapes et non 3, et le fait que les admins restreints et les auteurs restreints n'aient pas accès aux autres secteurs (un site national, dont les secteurs sont régionnaux) - Avec spip 1.7 c'était inenvisageable tel quel, donc il à été décidé qu'une société de service produirait un logiciel dérivé de SPIP qui répondrait au cahier des charges. - Un an plus tard, plusieurs gros sites tournent avec spip-agora, et le procéssus imaginé par le SIG fonctionne : différents ministères contribuent et échangent leur optimisations du code de spip-agora. Mais ce code est bien loin de spip (pear, trucs objets en anglais). On arrive aujourd'hui, l'heure du bilan d'étape, et on s'apercoit que : - Spip-agora est une usine à gaz - Il est carrement incompatible avec spip, qui lui est arrivé en version 1.8, une sorte de révolution qui permet l'ajout d fonctions spécifiques - La communauté spip-agora se limite elle même en nombre de participant et en ressources de programmation car elle oblige les gens à choisir entre spip et spip-agora. - Même pour disposer des fonctions qui permettent les usages spécifiques des administrations (le work flow en 4 étapes, les secteurs de l'espace privé restreints à des groupes de personnes) on commence à se demander si on ne ferait pas moins de gachis en travaillant sur spip 1.8. - Un ministère prend les devants et contracte une societé de service (une autre) pour réaliser un spip 1.8 avec des fonctions d'agora. - On se demande alors chez SIG, si on a interret à garder le code hétéorodoxe de spip-agora qui limite les contributions à un cercle restreint de ssii, ou bien si apres tout, dès lors que le nouveau spip le permet, pourquoi ne pas envisager AGORA comme un ensemble d'options, de plugs-ins et autres modules, compatibles avec spip 1.8 : une sorte de super-EVA. - Là les ssii et conseillers conseillent : les uns : "il faut continuer l'usine a gaz, ca fait une bonne rente de situation" les autres (les concurrents) : "mais non, il faut revenir vers spip, d'ailleurs on commence à le faire pour machin, mais il faut aussi garder la version agora qui nous fait quelques clients malgré tout" On comprend alors que les ssii sont interressées par n'importe quoi, pourvu qu'elles gagnent des commandes. Les personnes non interressées par les stratégies marchandes : "au lieu de faire du gachi comme ca, vous feriez mieux de regarder comment est codé spip 1.8 et ce qu'il permet, ca clôturerait le débat ; Il est tout à fait envisageable, pour qui veut, de réaliser une palette de fichiers compatibles spip 1.8, qui rendrait disponible les fonctions d'agora dans le cadre de spip" Enfin, chat échaudé craint l'eau froide, chez SIG on s'interroge : mais si on revient vers spip, est-ce qu'on va se faire jetter comme la dernière fois ? Les spipeurs ont-ils du coeur ? vont-ils nous aiguiller sur la démarche à suivre ? On se rassure un peu car l'un des mousquetaire à aidé une société de service à ne pas faire n'importe quoi pour un projet d'administration fondé sur spip 1.8, mais on se rend compte aussi (enfin me semble t'il) que les devs de spip n'ont pas que ca à faire que de corriger les squelettes d'agora... mais alors qui va le faire dès lors que les ssii ont interret à produire des trucs qu'elles seules maitrisent... Bref, on en est là, le projet AGORA semble prometteur au sein des administrations mais l'ideal pour la pérénité serait de sortir du fork, et de revenir à un système plus constructif, ou spip et sa version spip-agora profiteraient de développements mutuels, sans que les travaux des uns n'exercent de pression sur celui des autres (approche agora 1, qui s'est révélée catastrophique). Il ne faudrait pas non plus que les gens d'agora essayent à nouveau de faire coder leurs scripts par les devs de spip : ils ne sont pas là pour ca, et ce, étant entendu qu'agora est un projet très très important et tout et tout :). Bref... Je trouve que ca serait sympa de coder les deux trois fonctions agora en contrib spip 1.8, pour oir si ca le fait, et qu'on en finisse un peu avec tout ca ; je ne sais pas si c'est facile, mais ca ne devrait pas représenter autant d'efforts que ceux qui ont permi de faire l'agora actuel. Ca ferait, en sus, un bon exemple d'utilisation des nouvelles fonctions de spip 1.8, des exemples de super-contribs à tables ajoutées :) Alors, l'enfant maudit rentre au berquail ? BoOz