:-)
Me suis mal fait comprendre.
Je précise : je suis plutôt anarchiste libertaire ... donc pas de procès d’intention. Je ne propose pas de mettre au pas quoi que ce soit ...
Je pars juste d’un constat :
le core s’amaigrit et passe une série de fonctions vers des plugs ... ok mais quand je vois les problèmes des plugs pour suivre l’évolution du core et rester compatibles avec lui et entre eux, je crois qu’il y a moyen d’être un peu plus efficace (c’est un gros mot ?). Pour bien me faire comprendre, je ne dis PAS que ces problèmes sont anormaux et révèlent une défaillance grave dans spip et son mode de fonctionnement collaboratif, je dis qu’à bien lire les posts des devs de plugins, ce qu’ils disent, les types de problèmes, etc. il m’apparaît assez clairement que cet effort d’externalisation mené par les dev. du core qui font ça pour leur plaisir et sans contrainte manque quand même un peu du minimum d’"exposition" méthodologique pour que tout le monde puisse suivre sur une base mutuelle ;
tout le monde fait ça pour son plaisir ... non c’est pas vrai : il y a là des gens dont c’est "en partie" le business et qui NOUS FONT le plaisir - partagé sûrement - de mettre en commun le fruit d’un labeur inscrit au moins pour une part dans le champ des échanges marchands ;
es-tu absolument sûr qu’un espace où chacun est libre d’entrer (liiiiiiibre) mais qui implique le respect de certaines règles complémentaires au joyeux bordel organisé ne peut pas être un dispositif où le plaisir se déploiera aussi intensément que dans un joyeux bordel ;
développer un plug pour des fonctions importantes, touchant au coeur du modèle d’un cms, demande un investissement temps important et des connaissances durement acquises (de spip notamment). Il y a des codeurs d’enfer ici. Et souvent, ils se lancent dans une aventure pour trouver une réponse à un besoin personnel et spécifique. OK. A partir de là, comment peux-tu préjuger qu’aucun d’entre eux ne serait intéressé par un espace avec une méthodologie de développement collaboratif un peu plus organisée,
1/ qui aiderait à une meilleure coordination au niveau d’une définition de chantier préalable ;
2/ qui pourrait être, même de très loin, suivie par un dev du core - ne fut-ce pour pour prévenir (par exemple d’une future évolution de tel fragment de code dans spip, ou d’un changement majeur etc.) ou aider (par exemple à trouver le bout de code spip sur lequel appuyer telle nouvelle fonction).
Ceci étant, moi ce que j’en dis ...
Maintenant, je vais t’avoquer deux petites choses :
1- j’ai développé des morceaux de code pour des sites spip ... à côté de spip, parce que c’était tout simplement plus rapide de squizzer le core de spip (pour ce que j’avais à faire) que de m’appuyer dessus. Aucun intérêt donc à mettre ça sur la zone. Je nai malheureusement pas le temps de plonger dans une doc "dev" éparpillée pour l’essentielle dans le code et dans les changeset et tenter de reconstituer le futur de spip à travers les bribes échangées à ce sujet sur la liste spip-dev. Un espace collaboratif (pas le seul, parmi d’autres, où chacun serait liiiiiiiiiiiibre d’entrer ou non) plus contraignant quant aux méthodes de travail aidera peut-être à constituer une base de conniassance orientée "dev", centralisée, cohérente, corrigée et à jour ... Peut-être seulement, je précise, c’est pas sûr.
2- J’ai imaginé que l’allègement du core de spip pourrait bien passer par
la pluginisation de l’espace privé (mis à part l’espace - les espaces - d’administration et de réglages). Je vais donc plus loin que la simple squelettisation des espaces d’édition (encore que la pluginisation a besoin de la squelettisation),
et (encore plus fort) par la pluginisation des tables à "contenu éditorial" (articles, rubriques, etc.), ne gardant que le "moteur", susceptible de s’appliquer à tout contenu "tables d’une base de données". Un contenu structuré par rubriques, brèves et articles, avec mots clés, n’étant qu’un plugin à destination d’un usage particulier. Plugin "standard", pourquoi pas ...
Ce qui m’amène à penser par contre que la capacité à gérer un workflow (sa définition opérationnelle pouvant relever d’un plug) et la capacité à gérer un système un peu complet de droits (par exemple de type RBAC ou ORBAC) relèvent d’un ensemble de fonctions et d’une architecture qui ont, elles, plutôt place dans core, non ?
C’est un hommage que je rends à spip : arrivé à ce stade développement, au potentiel que son moteur lui donne, à la qualité des dév. du core, ... est-ce "déplacé" de trouver que le joyeux bordel (dev de plugs) qui consiste quand même à 70-80% à fabriquer, coller et remplacer des rustines, même avec beaucoup de talent, d’ingéniosité et d’esprit convivial et partageur, n’est peut être pas le seul modèle, exclusif, à envisager.
In fine, personnellement, je n’arrive pas à m’investir dans spip - alors que j’aimerais beaucoup, parce que je n’ai pas le cadre "collaboratif" pour le faire. Au contraire de toi.
Spip contrib n’est PAS un cadre collaboratif, il est un dispositif de mutalisation et de partage. C’est pas la même chose. Le wiki pouvait être un espace collaboratif, mais j’apprends qu’il est prévu de l’euthanasier pour le ramener vers spip-contrib (ou alors j’ai encore une fois rien compris).
et donc ...
Répondre à ce message
« acces_restreint » qui gere les zones d’acces, mais pas les profils, obligeant a définir auteur par auteur ses autorisations ou non
RSS 2.0