Bonjour,
suite à une discussion datant d'un mois et demi sur la liste spip-rezo, j'ai repéré quelques nouveaux petits manques sur spip.net.
les critères suivants sont absents du glossaire :
- annee
- annee_redac
- mois
- mois_redac
Si j'en trouve d'autres, je ferai signe.
A bientôt
Simon
Bonjour,
C’est exact. Mais comment fais-tu pour comparer? Ce que j’entends par là, c’est est-ce que tu regardes s’il y a les critères que tu utilises? Ou est-ce que tu compares avec les critères présents dans le code de spip?
En somme, il faudrait que nous arrivions à lister tout les critères, filtres, balises qui sont présent dans SPIP et qui ne serait pas listés dans le glossaire. Ça ferait une ligne de conduite pour la doc bien qu’il y a pas mal à faire déjà.
Je vais continuer dans la journée à documenter les filtres.
A bientôt,
Teddy
Le 28 juillet 2009 09:21, Simon Camerlo <scamerlo.work@gmail.com> a écrit :
Bonjour,
suite à une discussion datant d’un mois et demi sur la liste spip-rezo, j’ai repéré quelques nouveaux petits manques sur spip.net.
les critères suivants sont absents du glossaire :
- annee
- annee_redac
- mois
- mois_redac
Si j’en trouve d’autres, je ferai signe.
A bientôt
Simon
spip-trad@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-trad
http://www.spip.net/
irc://irc.freenode.net/spip
S'lt
Le glossaire actuel se base *uniquement* sur les mots clefs. Par
conséquent si un filtre, balise, critere a son article mais qu'on a
oublié d'indiquer les bons mots clefs celui ci n'apparaitra pas.
A terme cette page devra évoluer. Pour le moment, on n'y touche pas
car nous avons moins d'éléments documentés au global que ce que
propose le glossaire actuel. Je considère que nous aurions une
regression trop forte pour
Pour faire une liste des filtres on peut s'appuyer sur doc.spip.org et
ses page pages API, que Teddy a bien fait évoluer dernierement.
Km
Salut,
(merci pour les compliments 
Pour doc.spip.org, les pages API sont faussées. Lorsque j’avais lancé ça grâce à memo_api, on m’avait dit que tout n’est pas API. Mais personne n’a pu me dire ce qui était API ou pas.
Si une âme charitable veut bien me dire quelles sont les API, je me propose de modifier les articles en conséquence.
Toutefois, je n’utiliserai plus le terme « API » dans ce qui n’est pas du domaine de l’API mais je ne l’effacerai pas car cela aide, je pense, de savoir les filtres/critères et cie de ce type.
Teddy
Le 28 juillet 2009 10:27, cam.lafit@azerttyu.net <cam.lafit@azerttyu.net> a écrit :
S’lt
Le glossaire actuel se base uniquement sur les mots clefs. Par
conséquent si un filtre, balise, critere a son article mais qu’on a
oublié d’indiquer les bons mots clefs celui ci n’apparaitra pas.A terme cette page devra évoluer. Pour le moment, on n’y touche pas
car nous avons moins d’éléments documentés au global que ce que
propose le glossaire actuel. Je considère que nous aurions une
regression trop forte pourPour faire une liste des filtres on peut s’appuyer sur doc.spip.org et
ses page pages API, que Teddy a bien fait évoluer dernierement.Km
Re,
Une question pour doc.spip.org (je ne sais pas si c’est le bon endroit), il y a sous les pages des articles un lien vers spip.net
Ne serait-il pas possible de faire cela « automatiquement » grâce à un modèle? Il chercherait ce dont il a besoin dans le glossaire…
Je ne sais pas si c’est réalisable tout cela…
Le 28 juillet 2009 10:42, Teddy Payet <teddy.payet@gmail.com> a écrit :
Salut,
(merci pour les complimentsPour doc.spip.org, les pages API sont faussées. Lorsque j’avais lancé ça grâce à memo_api, on m’avait dit que tout n’est pas API. Mais personne n’a pu me dire ce qui était API ou pas.
Si une âme charitable veut bien me dire quelles sont les API, je me propose de modifier les articles en conséquence.
Toutefois, je n’utiliserai plus le terme « API » dans ce qui n’est pas du domaine de l’API mais je ne l’effacerai pas car cela aide, je pense, de savoir les filtres/critères et cie de ce type.
Teddy
Le 28 juillet 2009 10:27, cam.lafit@azerttyu.net <cam.lafit@azerttyu.net> a écrit :
S’lt
Le glossaire actuel se base uniquement sur les mots clefs. Par
conséquent si un filtre, balise, critere a son article mais qu’on a
oublié d’indiquer les bons mots clefs celui ci n’apparaitra pas.A terme cette page devra évoluer. Pour le moment, on n’y touche pas
car nous avons moins d’éléments documentés au global que ce que
propose le glossaire actuel. Je considère que nous aurions une
regression trop forte pourPour faire une liste des filtres on peut s’appuyer sur doc.spip.org et
ses page pages API, que Teddy a bien fait évoluer dernierement.Km
Le 28 juil. 09 à 10:42, Teddy Payet a écrit :
Si une âme charitable veut bien me dire quelles sont les API, je me propose de modifier les articles en conséquence.
Toutefois, je n'utiliserai plus le terme "API"
La refonte de la syntaxe des squelettes que j'ai proposée à Avignon a comme deuxième étape une rationnalisation nécessaire des noms des filtres. Je ne sais pas trop quand je serai en mesure de proposer une méthode de nommage acceptable, mais c'est juste pour dire qu'il ne faut pas trop gaspiller de l'énergie dans des choses qui risquent de bouger, ou plus précisément de bien séparer le travail rédactionnel (qui sera toujours nécessaire) à la manière dont y accède (qui est susceptible de bouger).
Quant au terme API, c'est du jargon; "interface" est bien suffisant: puisque ce sont des fonctions PHP, c'est de la programmation de l'application.
Committo,Ergo:Sum
Je note les manques à chaque fois que j’en rencontre un dans la doc ou dans mes squelettes, donc méthode purement empirique.
(en l’occurrence, ces critères-ci sont documentés dans l’article « les critères communs à toutes les boucles » ) C’est moins exhaustif que ce que tu essaies de mettre en place pour les filtres, mais ça peut toujours aider aussi. Simon Teddy Payet a écrit :
S'lt
(en l'occurrence, ces critères-ci sont documentés dans l'article "les
critères communs à toutes les boucles"
Les critères communs à toutes les boucles - SPIP)
Bon cas d'école 
En pratique cet article ne devrait qu'une syndication des autres
articles référéncé dans la rubrique critéres.
C'est à dire nous devrions avoir pour chacun des ces critéres, un
article dont le titre est le nom du critere, un texte qui reprend
l'explication.
Les mots clefs sont alors les différentes boucles concernées ainsi
qu'un mot clef "communs aux boucles" (peut être à créer, trou de
mémoire)
Tu peux par exemple, créér tous les articles criteres manquant et
copier coller la description dans le texte. Cela se fait assez
rapidement, c'est ce qui a été fait pour l'ensemble des balises
utilisées dans la boucles ARTICLES.
On utilise ensuite un modele qui charge l'ensemble des balises,
criteres, qui sont en rapport avec un mot clef donné.
Je note les manques à chaque fois que j'en rencontre un dans la doc ou dans
mes squelettes, donc méthode purement empirique.
De meme si tu en rencontres un, non documenté, tu peux deja créer
l'article avec les informations de bases. Il faut penser à le proposer
à l'évaluation pour que les autres contributeurs puissent participer
et apporter leur connaissance.
Km
il ne faut pas trop gaspiller de l'énergie dans des choses qui risquent de bouger
Je ne pense pas que ce soit une bonne manière de développer un projet
que de demander aux gens qui veulent participer de s'abstenir, parce
que tu prévois, à une date indéterminée, de casser tout ce qu'ils
auront fait. Ils vont se détourner car tu leur dis en substance "ici,
c'est *mon* terrain de jeu, et il y a péril pour toi". A mon sens si
tu prévois de modifier des choses ce sera à toi de faire l'effort de
t'assurer que tout ce qui a été fait "suit". Pas l'inverse, sinon
c'est stérilisant.
Quant au terme API, c'est du jargon; "interface" est bien suffisant: puisque
ce sont des fonctions PHP, c'est de la programmation de l'application.
Pas d'accord là non plus "Interface" tout seul pouvant aussi bien
signifier "interface utilisateur", on emploie ce morceau de jargon
"API" pour décrire la manière (dans l'idéal, la manière "officielle" &
"stable") dont un script "externe" peut (et devrait) communiquer avec
le logiciel "cœur".
-- Fil
Le 28 juil. 09 à 12:29, Fil a écrit :
il ne faut pas trop gaspiller de l'énergie dans des choses qui risquent de bouger
Je ne pense pas que ce soit une bonne manière de développer un projet
que de demander aux gens qui veulent participer de s'abstenir,
J'ai l'impression que tu as lu un diagonale: j'ai bien précisé dans mon mail que l'aspect rédactionnel restait indispensable et je disais qu'il ne fallait pas se prendre le chou sur
la détection automatique de ce qui manque. Je suis prêt à faire la migration de ce qui aura été rédigé au besoin, en revanche je disais que vouloir automatiser sur l'état actuel du source serait du code qui partirait à la poubelle, et le fait que je proposerais du code pour le remplacer serait quand même une maigre consolation.
Ne rien dire et tout mettre à la poubelle dans quelques mois me semble une attitude qui aurait été beaucoup plus mal vécue que d'inviter les gens à se concentrer sur ce qui a le maximum de perennité.
Committo,Ergo:Sum
Par rapport à ce que tu dis « quelques mois », il me semble alors « mieux » de documenter les balises/critères/filtres maintenant car entre temps on reste sur la même base.
Une solution pourrait être de rajouter un groupe de mot-clés qui informe la validité de la fonction jusqu’à telle ou telle version.
On aurait par exemple le filtre |agenda_affiche valable depuis SPIP 1.8.2 jusqu’à SPIP 2.0.8.
Il suffirait ainsi de mettre cette information dans la page de l’article.
Sur plugins.spip.net on peut choisir les plugins compatibles pour SPIP 1.9.2 ou SPIP 2.0. Pourquoi ne pas adapter cette fonction sur spip.net?
En faisant cela, cela permettra aux personnes motivées de continuer la documentation de SPIP…
Vos avis?..
Teddy
Le 28 juillet 2009 12:40, Committo,Ergo:sum <esj@rezo.net> a écrit :
Le 28 juil. 09 à 12:29, Fil a écrit :
il ne faut pas trop gaspiller de l’énergie dans des choses qui risquent de bouger
Je ne pense pas que ce soit une bonne manière de développer un projet
que de demander aux gens qui veulent participer de s’abstenir,J’ai l’impression que tu as lu un diagonale: j’ai bien précisé dans mon mail que l’aspect rédactionnel restait indispensable et je disais qu’il ne fallait pas se prendre le chou sur
la détection automatique de ce qui manque. Je suis prêt à faire la migration de ce qui aura été rédigé au besoin, en revanche je disais que vouloir automatiser sur l’état actuel du source serait du code qui partirait à la poubelle, et le fait que je proposerais du code pour le remplacer serait quand même une maigre consolation.Ne rien dire et tout mettre à la poubelle dans quelques mois me semble une attitude qui aurait été beaucoup plus mal vécue que d’inviter les gens à se concentrer sur ce qui a le maximum de perennité.
Committo,Ergo:Sum
Le 28 juil. 09 à 13:36, Teddy Payet a écrit :
Par rapport à ce que tu dis "quelques mois", il me semble alors "mieux" de documenter les balises/critères/filtres maintenant car entre temps on reste sur la même base.
Une précision: on peut penser ce qu'on veut de la syntaxe des critères, mais leur position dans les squelettes fait qu'ils ne sont pas dans les parties de la syntaxe qui pose des problmes pour une migration XML. Commencer par eux me semblerait donc un bon plan.
Une solution pourrait être de rajouter un groupe de mot-clés qui informe la validité de la fonction jusqu'à telle ou telle version.
On aurait par exemple le filtre |agenda_affiche valable depuis SPIP 1.8.2 jusqu'à SPIP 2.0.8.
Il suffirait ainsi de mettre cette information dans la page de l'article.Sur plugins.spip.net on peut choisir les plugins compatibles pour SPIP 1.9.2 ou SPIP 2.0. Pourquoi ne pas adapter cette fonction sur spip.net?
Oui tout à fait, c'est un gros besoin.
Committo,Ergo:Sum
S'lt
Une solution pourrait être de rajouter un groupe de mot-clés qui informe
la validité de la fonction jusqu'à telle ou telle version.
On aurait par exemple le filtre |agenda_affiche valable depuis SPIP 1.8.2
jusqu'à SPIP 2.0.8.
Oui tout à fait, c'est un gros besoin.
Euh les mots clefs existent deja et je l'ai deja dis precédemment en
disant ce qu'on devait penser à documenter lors de l'ajout d'un
nouveau element.
Et j'ai dit aussi que je ne me prendrais pas le chou non plus sur la
mise en page tant qu'on aura pas atteind un seuil redactionnel du
niveau du glossaire actuel.
Km
Oui tout à fait d’accord…
Mais il faut établir des règles qu’on doit suivre pour ne pas avoir à tout refaire car on va changer/optimiser l’affichage du site pour tel ou tel besoin.
Le fait de savoir qu’il y a un groupe de mot-clés donnant la dernière version utilisant encore une fonction permettra de modifier sereinement la doc.
On a plus qu’à se retrousser les manches pour étayer ce qui est déjà présent ou encore à faire.
Le 28 juillet 2009 14:38, cam.lafit@azerttyu.net <cam.lafit@azerttyu.net> a écrit :
S’lt
Une solution pourrait être de rajouter un groupe de mot-clés qui informe
la validité de la fonction jusqu’à telle ou telle version.
On aurait par exemple le filtre |agenda_affiche valable depuis SPIP 1.8.2
jusqu’à SPIP 2.0.8.Oui tout à fait, c’est un gros besoin.
Euh les mots clefs existent deja et je l’ai deja dis precédemment en
disant ce qu’on devait penser à documenter lors de l’ajout d’un
nouveau element.Et j’ai dit aussi que je ne me prendrais pas le chou non plus sur la
mise en page tant qu’on aura pas atteind un seuil redactionnel du
niveau du glossaire actuel.Km
Le 28 juil. 09 à 14:38, cam.lafit@azerttyu.net a écrit :
Euh les mots clefs existent deja et je l'ai deja dis precédemment en
disant ce qu'on devait penser à documenter lors de l'ajout d'un
nouveau element.
J'ai l'impression qu'on ne parle pas de la même choe, Camille.
Je vais sur doc.spip.org et je regarde par exemple la fonction du jour, savoir:
http://doc.spip.org/@sql_error
et je ne vois d'information sur les versions où figurent cette fonction.
Ce que j'avais en tête en parlant de besoin, ce serait une analyse automatique du dépot de subversion pour savoir quand une fonction apparaît et, éventuellement, quand elle disparait,
et ça, je ne crois pas que ce soit fait.
A propos, il semble qu'amemo prenne plus de vacances que nous: il n'a pas indexé les dernières fonctions qu'on a rajoutées.
Committo,Ergo:Sum
S'lt
J'ai l'impression qu'on ne parle pas de la même choe, Camille.
Peut être
A l'origine le sujet concerne spip.net, et c'est bien dans ce cas que
j'ai repondu : Les groupes de mots clef existent déjà.
Une personne qui documente un critere, filtre, balise, concerne la
partie spip.net et on déjà une certaine logique qui s'affine encore,
avec l'apport des contributions qui permet de voir les zones d'ombres.
Je vais sur doc.spip.org et je regarde par exemple la fonction du jour,
savoir:
http://doc.spip.org/@sql_error
et je ne vois d'information sur les versions où figurent cette fonction.
Si on parle d'amemo, la reponse est simple on ne suit que la version
dite SVN, donc ça ne sert à rien de préciser quelle version est
concernée vu qu'on n'en suit qu'une seule. En mon sens c'est
clairement un gros manque mais le code actuel ne permet pas de suivre
les branches.
Ce que j'avais en tête en parlant de besoin, ce serait une analyse
automatique du dépot de subversion pour savoir quand une fonction apparaît
et, éventuellement, quand elle disparait,
et ça, je ne crois pas que ce soit fait.
Si, amemo lors d'une mise à jour dépublie tous les articles et ne fait
répparaitre que ceux qui sont encore valides vis à vis du dépot SVN.
Toutes fonctions obsolètes se voient passer en statut "en cours de rédaction".
Et si je me rappelle bien dès qu'une fonction apparait la date
d'article lui correspond (à 24h près).
A propos, il semble qu'amemo prenne plus de vacances que nous: il n'a pas
indexé les dernières fonctions qu'on a rajoutées.
Concernant les vacances d'amemo, suite aux évolutions du core entre
192 et 2 et autres pétouilles, ça plante allégrement sur la mise à
jour. Et je n'ai clairement pas eu le temps à accorder à ce "détail",
j'avais deja bien pleuré pour arriver à tourner sur la 192
Km
Le 28 juil. 09 à 16:14, cam.lafit@azerttyu.net a écrit :
S'lt
J'ai l'impression qu'on ne parle pas de la même choe, Camille.
A l'origine le sujet concerne spip.net,
Ah bon, alors c'est moi qui n'avait pas compris.
Si on parle d'amemo, la reponse est simple on ne suit que la version
dite SVN, donc ça ne sert à rien de préciser quelle version est
concernée vu qu'on n'en suit qu'une seule. En mon sens c'est
clairement un gros manque mais le code actuel ne permet pas de suivre
les branches.
Pour moi ce n'est pas un manque, on retombe sur la conversation d'hier:
une branche stable n'est plus censée recevoir que des interventions minimales
de correction de bug, qui la plupart du temps ne nécessite pas l'introduction
de nouvelles fonctions, et si oui quand même ne seront pas officialisées comme faisant
partie de l'interface.
Ce que j'avais en tête en parlant de besoin, ce serait une analyse
automatique du dépot de subversion pour savoir quand une fonction apparaît
et, éventuellement, quand elle disparait,
et ça, je ne crois pas que ce soit fait.Si, amemo lors d'une mise à jour dépublie tous les articles et ne fait
répparaitre que ceux qui sont encore valides vis à vis du dépot SVN.
Toutes fonctions obsolètes se voient passer en statut "en cours de rédaction".
Ah, la mécanique existe donc, très bien. Mais j'aurais plus vu une mécanique
qui associe des mots-cles de version à ces articles, et cesse de le faire lorsque la fonction
disparait: il n'y a pas de raison de faire disparaitre la doc d'une ancienne version.
Concernant les vacances d'amemo, suite aux évolutions du core entre
192 et 2 et autres pétouilles, ça plante allégrement sur la mise à
jour. Et je n'ai clairement pas eu le temps à accorder à ce "détail",
j'avais deja bien pleuré pour arriver à tourner sur la 192
Je ne vois pas où il y a une difficulté, mais tu es mieux placé que moi pour en voir.
Committo,Ergo:Sum
Je n’ai pas encore d’accès à l’espace privé de spip.net, et de toute manière je n’aurai pas le temps de documenter quoi que ce soit avant quelques semaines (en plein portage du site que j’administre de la 1.9.2 à la 2.0.8, y’a du boulot).
Mais dès que la charrette passe, je pense me pencher plus activement sur la rédaction de la doc pour aider.
Par contre, étant venu à spip avec la v1.9.2, je ne serai pas du tout le mieux placé pour indiquer les versions d’apparition / disparition de fonctions.
Simon
a écrit :
S'lt
Je n'ai pas encore d'accès à l'espace privé de spip.net,
Ça c'est une fause excuse
je n'aurai pas le temps de documenter quoi que ce soit avant quelques
semaines (en plein portage du site que j'administre de la 1.9.2 à la 2.0.8,
y'a du boulot).
Celle ci est meilleure.
Mais dès que la charrette passe, je pense me pencher plus activement sur la
rédaction de la doc pour aider.
Bonne nouvelle
Par contre, étant venu à spip avec la v1.9.2, je ne serai pas du tout le
mieux placé pour indiquer les versions d'apparition / disparition de
fonctions.
Mais grâce à la participaton de spip-trad et des forums de spip.net,
ceci n'est pas un gros problème non plus.
Km