Salut,
Comme le disait Booz, chacun a ses motivations propres pour participer à un
projet libre, mais tout le monde y trouve un interet.
Une collaboration où l'echange est unilateral n'a aucune chance de durer.
Les contre-parties peuvent etre déséquilibrées mais il faut qu'il y en ait
(à minima, un "contributeur" profite d'une communauté de testeurs si les
fonctionnalités sont interessantes).
Et quoi qu'il arrive, si tu contribues, il y aura toujours qqun pour
critiquer (tant mieux quand c'est contructif) et tout le monde ne dira pas
merci (<troll>certains piqueront meme le code, l'allourdiront, y ajouteront
3 conneries irrecupérables, et se feliciteront de la naissance d'un nouveau
projet libre</troll>).
j'ai egalement un projet dans les tuyaux où la traduction automatique est à
étudier.
L'idée était de s'appuyer sur la mécanique du correcteur et de generer un
"brouillon" de traduction, juste pour accelerer un peu le boulot, sans trop
d'espoir sur la qualité du resultat.
Le projet doit s'appuyer sur un traducteur en ligne payant mais l'idée
générale est de mettre en place la mécanique via un serveur de traduction
qui pourra lui etre decliné selon la communication à mettre en place avec
l'outil de traduction proprement dit.
Le timing du projet est assez flou, mais cette fonctionnalité ne devrait
etre etudiée que l'été prochain.
Je suis donc très interessé.
Si tu veux ouvrir une page wiki, c'est encore la meilleure solution pour
debroussailler le besoin fonctionnel et les contraintes techniques.
S'agissant de traitements relativement lourd, il faut etre vigilant à
pouvoir les "distribuer" et garder en tete que l'immense majorité des
utilisateurs n'utilise qu'une toute petite partie des fonctionnalités
offertes.
Spip n'a donc pas vocation à "integrer" trop de fonctionnalités, il couvre
deja plus que largement son perimetre fonctionnel (c'est un outil de WCM à
la base, sa force est la simplicité d'utilisation et de mise en oeuvre, il
ne doit pas devenir une uzine à gaz)
Vu les dernieres evolutions et l'orientation modulaire que prend Spip, je
crois qu'il faut revoir un peu l'optique de certaines contribs.
Jusqu'à aujourd'hui, chacun esperait voir sa contribution integrée pour
eviter de suivre les versions de Spip.
Le but des contrib etait donc de ne pas perturber le fonctionnement par
defaut et d'ajouter sa fonctionnalité.
Le resultat etait souvent couteux en performence (chacun y allant de son
petit test, de son petit fichier de config, son petit ajout au cron ...)
Avec le nouveau systeme de plugin (et au besoin un petit coup de spipem en
attendant des points d'entrée simples à utiliser dans l'espace rédaction),
il y a moyen maintenant de faire du bon boulot, facile à maintenir, sans
pour autant integrer du code supplementaire à Spip.
Les traitements "supplementaires" entrent dans un fonctionnement "normal" de
Spip et les traitements sont fait au bon moment et uniquement pour ceux qui
ont installé la fonctionnalité.
C'etait deja plus ou moins le cas lorsque les contributions etaient
integrées, mais la(es) page(s) d'administration s'alonge à chaque version et
ce mode de fonctionnement n'est pas viable à long terme.
Pour prendre un exemple concret : la gestion des mots clés.
Ajourd'hui, on a déja dans Spip la possibilité ou non d'utiliser les groupes
de mots clés.
La question se pose d'integrer une gestion arborescente des groupes et un
mode rhyzome.
Ne faudrait il pas plutot envisager 4 modules exclusifs (ou 3 modules
possibles pour etendre le premier) ?
Je pense que cette approche peut etre appliquée à d'autres fonctionnalités.
Après, que les fonctionnalités soient directement dans la distribution
officielle ou non ...
je dirai que sa regarde plus les "copyrightés" (tiens, j'ai oublié de
felicité Emmanuel !) et qu'au moins, Spip pourra plus facilement resister à
la pression des utilisateur et garder son esprit d'origine.
Les derniers retours que j'ai eu en presentant Spip vont egalement dans ce
sens.
La demande est claire : pouvoir faire disparaitre ce qui n'est pas utilisé.
Pour les uns l'agenda, pour d'autres les mots clés, j'ai meme fait une
proposition n'utilsant pas du tout les articles (!!!).
C'est pas très compliqué de commenter des bouts de inc_presentation, mais je
reviens sur mon idée d'il y a quelques jours : je pense que le Spip-dist ne
devrait etre qu'une configuration préconisée pour Spip mais ouvrir la porte
à d'autre utilisations.
Des distributions avec des buts fonctionnels differents pourraient alors
voir le jour (blogue, collaboratif, ...) mais ne seraient finalement que des
bundles de contribs préconfigurées.
Oups, j'ai encore fait un peu long, désolé, mais comme des choses
importantes se decident actuellement, j'insiste un peu sur l'importance
l'API de Spip en cours d'élaboration.
C'était mes 2 cents ...
@++
