[spip-dev] Contributions ? SPIP

Bonjour à toutes et à tous,

je découvre SPIP de mes propres mains en ce moment, et c'est un réel
plaisir.
Je dirige une association d'Education Scientifique et nous montons très
régulièrement des stages intensifs savament préparés à l'avance pour des
gens de toutes tranches d'âge.

Durant un ou plusieurs de ces stages nous pourrions développer des éléments
pour SPIP, dont j'ai déjà une petite liste en tête.

Plutôt que de les garder pour nous je serai intéressé de les mettre à
disposition de tous.
Est-ce que cela vous intéresse ?

La question sera surtout technique :
avant : Pour être utile et dans le sens des développements en cours, est-ce
que tel élément doit être de telle ou telle forme.
après : est-ce que tel élément doit entrer dans le noyau ou dans des modules
à ajouter, selon la difficulté de les intégrer soi-même, etc

Qu'en pensez-vous ?

Les prochains stages auiront lieu l'été prochain donc nous avons le temps de
faire les bons choix et de préparer convenablement les projets.

Bien cordialement
Thomas EGLI
Objectif Sciences
tél. : +33 6 33 62 62 11
http://www.objectif-sciences.com

Thomas EGLI wrote:

Je dirige une association d'Education Scientifique et nous montons très
régulièrement des stages intensifs savament préparés à l'avance pour des
gens de toutes tranches d'âge.

Personnellement, traumatisé par des années d'études supérieures,
je me méfie énormément des personnes qui se revandiquent de
l'Education Scientifique, qui montent de l'intesif,
et qui se prétendent savament préparer.

Vous auriez pas quelquechose d'un peu plus cool et moins péteux ?

JL

JLuc wrote:
...

PS : Cette demande (ou réponse) "n'engage" que moi ...
JL

Deux pages à lire de toute urgence :
Comment contribuer au développement de SPIP : http://www.spip.net/fr_article825.html
Spip-contrib : http://www.spip-contrib.net/

Minh

Je vois que tu es de très bonne humeur ce matin.

Je peux te dire très calmement que tu n'as STRICTEMENT rien compris, et tant
pis pour toi donc.

t'aurais au moins pu aller regarder le sit www.objectif-sciences.com pour
piger un peu de quoi il s'agit. Ne fais pas retomber sur des inconus tes
revendications contre d'anciens profs.

Finalement, je me demande si j'ai vraiment envie de contribuer

JLuc <jluc@no-log.org> a écrit dans le message :
clqa8d$8sf$1@sea.gmane.org...
Thomas EGLI wrote:

Je dirige une association d'Education Scientifique et nous montons très
régulièrement des stages intensifs savament préparés à l'avance pour des
gens de toutes tranches d'âge.

Personnellement, traumatisé par des années d'études supérieures,
je me méfie énormément des personnes qui se revandiquent de
l'Education Scientifique, qui montent de l'intesif,
et qui se prétendent savament préparer.

Vous auriez pas quelquechose d'un peu plus cool et moins péteux ?

JL

Salut,

Quels sont ces fameux éléments ?

/lex

Alexandre Hélias [LNG] a écrit :

Thomas EGLI a écrit :

Finalement, je me demande si j'ai vraiment envie de contribuer

Je me permets de rebondir là dessus pour troller :slight_smile:

Si tu contribues ca ne doit pas être pour nous faire plaisir ou parce que tu es bon prince : non, la on se retrouverait vite avec un Spip de bisounours.

Il se trouve que Spip est un logiciel libre : c'est à dire du bien public. A partir de là, il est utilisé par qui en à besoin, et notament par des gens qui se feraient envoyer bouler s'ils postaient sur cette liste, même des gens qui ne pourraient pas se tenir dans la même piece au même moment sans se tirer les cheveux les uns des autres.

Les contributeurs contribuent en réalité parce qu'ils utilisent eux même leurs contributions, et que ca les arrangerait bien qu'elles soient intégrées dans le noyau :

1) C'est une forme de reconnaissance de qualité
2) C'est une manière participer à l'élaboration de ce fameux bien public, dont ont peut se prévaloir ensuite pour toutes sortes de raisons.

Il peut donc théoriquement exister des contributeurs qui soient sur des approches radicalement différentes de celles qui motivent les devs historiques, mais la production fonctionne bien quand même : c'est la force du libre.

Ce qui nous meut c'est le respect d'une ligne unitaire : l'intéret général qui est la diffusion de spip en tant que bien public au plus grand nombre.

Après si spip est le logiciel sous GPL le plus distribué en France, chacun y retrouvera ses petits, et fera sa propre salade.

La différence avec le libre : c'est que une contrib n'est pas de bonne qualité ou qu'elle risque de nuire à la qualité de Spip, il n'y a aucun patron ou financier qui nous la fera intégrer à Spip, car Spip est indépendant : tout simplement.

Donc des contribs de n'importe qui oui : mais des bonnes contribs et comme ca ca marchera bien.

Salut,

Il y a divers types d'éléments que je développerai durant ces stages afin de
développer un web ring géré par les participants eux-mêmes. Ce web-ring sera
constitué d'autant de sites que de "laboratoires" constitués par les équipes
de participants (jeunes adultes, ados, enfants...). Certains sites
permettront de télécommander un téléscope à distance par exemple. Dans un
tel cas, si on développe un outil d'interface robotique avec SPIP à un
moment donné, il est à peu près clair que cet outil sera mis à disposition
en plus de SPIP, à ceux qui veulent en bénéficier.

Par contre, il y a plusieurs outils "commun" au web ring que nosu allons
développer, tel par exemple un système de traduction simultanée,
collaboratif et surtout, apprenant. Nos partenariats avec des centres de
recherches bien placés dans ce domaine, et l'utilisation des meilleurs
logiciels de traduction comme noyeau, nous permettra d'avoir de très bons
résultats de traduction simultanée, permettant aux auteurs ou relecteurs de
modifier la traduction, le logiciel en prennant bonne note.
Dans ce cas, c'est typiquement un outil qui pourrait intégrer l'offre SPIP
générale, parce que ça rendrait de fameux services à bien du monde et
boosterait encore plus SPIP.
Il y a plusieurs points techniques qui devraient être analysés,mais à ce
stade, c'est encore trop tôt.

Ce que je cherche pour le moment c'est surtotu de vori qui parmis vous est
intéressé de suivre le dossier de près pour voir dans quelle direction je me
lance sur ces développements.
S'ils y en a parmi vous qui désirent s'y associer d'une manière ou d'une
autre, via un travail en ligne ou via un monitorat des stagiaires, ça
permettrait d'avoir un beau résultat correspondant le plus vite qu'il serait
possible à ce qu'il faudrait faire pour entrer dans le moule de SPIP.

Merci pour votre intérêt,
Thomas

Durant un ou plusieurs de ces stages nous pourrions développer des

éléments

pour SPIP, dont j'ai déjà une petite liste en tête.

Salut,

Quels sont ces fameux éléments ?

/lex

Hello,

Je sais que spip ne se veut pas piramidale, mais on ne pourrait pas avoir une "procedure standart" pour avoir un espece de revue des elements et decider de ceux qui vont ou ne vont pas dans le noyau, qq chose du genre:
- chacun cuisine sa soupe,
- poste la recette sur spip-contrib, comme une contrib,
- ca test, incube, etc..
- si y'a un doute enorme à l'integration au noyau, les contribs importantes sont rediscutés sur la liste et dnas les contibs-nights

parce qu'on evalue difficielement la qualité d'une contrib à son intitulé :wink:

Mais je pense que la reponse à Thomas EGLI serait:
Toute contrib est toujours la bienvenue

Pierre

BoOz wrote:

Donc des contribs de n'importe qui oui : mais des bonnes contribs et
comme ca ca marchera bien.

C'est bien pour ça que sa réponse était 100% déplacée

non c'est GNU/Emacs :wink:

il existe un bon draft papier sur ces thèmatiques au sein du projet
GNU/Trans. L'idée de ce projet est de mettre en place un système de P2P
avec un pourcentage global de qualité à chaque fichier traduit au sein
du système. Cette approche me semble très bonne. Ca semble intéressant
je pense aussi que, si tu n'as jamais eu vent de gnu/trans (projet qui
pourtant ne décole pas) que tu regardes un peu de ce coté la également,
leur draft à le mérite d'apporter des cas d'utilisations qui me semblent
très bien pensés.

Quels sont ces "meilleurs logiciels" de traductions ?

pour ma part j'avais deja commencé a coder un petit quelque chose à
l'aide de Yacc, j'essayais ainsi de décrire une grammaire dans une langue
et une grammaire dans une autre langue, de trouver sur des cas simples une
matrice de transformation permettant de passer d'une grammaire à l'autre
et par la transposée, de faire l'inverse. Ensuite il suffisait de mettre
en rapport des vecteurs lexicaux afin de passer d'un vocable à l'autre.
Cependant, la langue française est un trés bon exemple de cas
particulier et je suis rapidement tombé sur des cas particuliers.

IMHO cela me semble d'interret au sens général ce que tu essayes de
commencer la.

++a.lex

pour ma part j'avais deja commencé a coder un petit quelque chose à
l'aide de Yacc, j'essayais ainsi de décrire une grammaire dans une langue
et une grammaire dans une autre langue, de trouver sur des cas simples une
matrice de transformation permettant de passer d'une grammaire à l'autre
et par la transposée, de faire l'inverse. Ensuite il suffisait de mettre
en rapport des vecteurs lexicaux afin de passer d'un vocable à l'autre.
Cependant, la langue française est un trés bon exemple de cas
particulier et je suis rapidement tombé sur des cas particuliers.

Les langues naturelles sont de très bons exemples de cas particuliers :wink:
Des millions de dollars ont été engloutis dans cette approche à l'époque
de la guerre froide (l'enjeu était notamment de traduire le russe en
anglais à la volée) et ça n'a pas donné grand'chose...

(anecdote-cliché :
vodka spirit flesh rotten - Recherche Google)

Amicalement

Antoine.

Après si spip est le logiciel sous GPL le plus distribué en France, chacun y retrouvera ses petits, et fera sa propre salade.

wouaaaaaah, quel prestige.
Tu as des chiffres?

M.

Oui, ça je les ai lues, et les donneri à lire aux animateurs informatiques
qui animeront les stages.

Mais les questions techniques iront plus loin... c'est déjà un premier pas
certes.

Minh Ha Duong <haduong@centre-cired.fr> a écrit dans le message :
200410281125.38373.haduong@centre-cired.fr...
Deux pages à lire de toute urgence :
Comment contribuer au développement de SPIP :
http://www.spip.net/fr_article825.html
Spip-contrib : http://www.spip-contrib.net/

Minh

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 ...
@++

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) ?

j'espère que cela est une blague de prendre comme exemple la gestion des
mots-clés comme un gouffre à perform*A*nces.

Ce qui n'est pas viable pour toi à long terme n'a trait qu'a ton opinion
je crois. Je me permets de te demander ce que tu utilises comme
traitement de texte et ton avis dessus ?

et si oui, Est ce que les 5% que tu en utilises te convienent suffisament,
t'apportent satisfaction ? Est ce que ca t'affecte de savoir que les 95%
restant que tu n'utilises pas peuvent servir à d'autres, à hauteur de
30% par exemple ?

mued

j'espère que cela est une blague de prendre comme exemple la gestion des
mots-clés comme un gouffre à perform*A*nces.

Heu, non, on s'est mal compris mais c'etait ecrit un peu vite ...
Je dis qu'à la longue, le cumul de test fini par etre couteux.
Que nombre de fonctionnalités, non utilisées pour certains, generent des
tests, voire des appels en base de données.
Si certaines fonctionnalités ne sont pas utilisées, il suffirait de ne pas
les mettre.
Jusqu'à aujourd'hui, la logique était : ca ne pese que quelques kilos sur le
serveur, et pas grand chose en memoire alors ...
Mais vu la vitesse à laquelle les fonctionnalités defiles, le raisonnement
ne sera pas viable longtemps.
On commence à apercevoir des depassements de memoire (8Mo), il y a peut etre
quelques bugs, certains traitements à optimiser, mais on surf sur cette
limite.
Si chacun pouvait chosir ses composants, on redescendrait d'un cran et on
aurait encore un peu de marge pour integrer des contribs.
Quand je dis qu'à long terme, ce n'est pas viable d'integrer et de mettre
une option de config, c'est parcque j'ai vu l'evolution de la page d'admin
depuis la 1.6.
J'ai aujourd'hui une 1.8 avec les notifs et les formulaires ... c'est pas la
mort, mais ca commence à etre long.
Je ne veux pas jeter des chiffres que je n'ai pas, mais combien
d'utilisateurs de Spip veulent juste mettre 10 pages en ligne ?
Combien ne l'utilise que agregateur RSS ?
Combien utilisent toutes les fonctions sur un meme site ?
C'est tout ce que je dis, je n'attaque personne et je ne critique pas du
tout la methode d'implementation des contribs, jusqu'à maintenant, on avait
pas vraiment le choix.

Ce qui n'est pas viable pour toi à long terme n'a trait qu'a ton opinion
je crois. Je me permets de te demander ce que tu utilises comme
traitement de texte et ton avis dessus ?
et si oui, Est ce que les 5% que tu en utilises te convienent suffisament,
t'apportent satisfaction ? Est ce que ca t'affecte de savoir que les 95%
restant que tu n'utilises pas peuvent servir à d'autres, à hauteur de
30% par exemple ?

Oui j'utilise souvent Word, et ca m'em... de voir 40Mo de Ram bouffés par 3
pages de texte et 2 images !
Et je te signale qu'à l'installation, je décoche les trucs dont je n'ai pas
besoin et qu'ils n'encombrent ni mon disque dur, ni ma memoire.
Mais pour avoir un peu de respect envers les developpeurs de Spip, je me
garderai bien de faire la comparaison entre les m... commerciales et un beau
projet libre bien pensé.

Je pars du principe que pour prendre une bonne decision sur un aussi gros
projet, il faut reccueillir un maximum d'avis et de cas d'utilisation
differents.
Je donne mon avis, c'est tout, j'espere que d'autres, utilisant par exemple
l'ensemble de Spip, donneront le leur et que les devs auront un maximum de
cartes en main pour prendre leur decision.

@++

Mais vu la vitesse à laquelle les fonctionnalités defiles, le raisonnement
ne sera pas viable longtemps.
On commence à apercevoir des depassements de memoire (8Mo), il y a peut etre
quelques bugs, certains traitements à optimiser, mais on surf sur cette
limite.
Si chacun pouvait chosir ses composants, on redescendrait d'un cran et on
aurait encore un peu de marge pour integrer des contribs.

Le raisonnement est mauvais, là. Si une contrib n'est pas utilisée, elle
n'implique pas de surcharge. Si ce n'est pas le cas, c'est qu'il y a un
problème dans le code.

En pratique les enjeux de performances sont de quatre types depuis le
début de SPIP :
- fluidité de l'interface privée
- rapidité du calcul des pages de l'espace public
- rapidité de l'envoi des pages depuis le cache
- exécution sans heurt des tâches de fond

Par contre, l'interface privée s'est progressivement alourdie depuis le
début, tandis qu'au contraire le site public a tendance à
continuellement s'améliorer. Ainsi, aux alentours de la 1.0/1.2 les
calculs de l'espace public posaient problème sur certains hébergeurs et
le site privé était relativement rapide, alors qu'on a le problème
inverse aujourd'hui (voir l'espace privé de spip-contrib pour les
courageux).

Côté tâches de fond, le problème a été "résolu" dans spip-lab, mais je
n'ai pas l'impression que cela ait été repris ici.

a+

Antoine.