[spip-dev] Contrib noyau de Spip

Bonjour !

Je veux exprimer une question que j'ai depuis un certain temps:

Est-ce que le développeurs pourraient dire plus sur leurs intentions à
propos de la contribution de "Déesse" sur le site contrib? Si je ne me
trompe pas, il s'agit d'une décision importante pour Spip - et non seulement
sur le plan technique.

Il s'agit d'une "contribution" qui change le noyau de Spip, faite (autant
que j'en puisse juger!) par quelqu'un de très compétent. (Quelle est sa
motivation pour avoir fait tant de travail?) Intégrer son travail voudrait
pratiquement dire (j'imagine) l'intégrer dans l'équipe de développeurs -
délicat!

Je vois certaines remarques positives dans les forums "j'aimerais intégrer
cela.", mais aussi des échanges sur un ton qui fait penser que le travail
ensemble ne va pas de soi.

merci, Paolo

Est-ce que le développeurs pourraient dire plus sur leurs intentions à
propos de la contribution de "Déesse" sur le site contrib? Si je ne me
trompe pas, il s'agit d'une décision importante pour Spip - et non
seulement sur le plan technique.

J'ai l'intention de l'intégrer très prochainement :slight_smile:

Mais effectivement c'est assez flippant car relativement "gros".

(Quelle est sa motivation pour avoir fait tant de travail?)

Une piste :
http://spipage.levillage.org/breve.php3?id_breve=58
et notamment
http://www.infop6.jussieu.fr/licence/annales/retic/sol2003sep10.pdf

le travail ensemble ne va pas de soi.

C'est la beauté de cette communauté : on ne se cache pas les difficultés,
mais en gros on avance quand même plus ou moins ensemble.

-- Fil

Fil wrote:

Est-ce que le développeurs pourraient dire plus sur leurs intentions à
propos de la contribution de "Déesse" sur le site contrib? Si je ne me
trompe pas, il s'agit d'une décision importante pour Spip - et non
seulement sur le plan technique.
   
J'ai l'intention de l'intégrer très prochainement :slight_smile:

Superbe !

Avez vous discuter de l'intégration de cette petite chose également : http://www.spip-contrib.net/breve41.html

Olivier

"Fil" wrote:

J'ai l'intention de l'intégrer très prochainement :slight_smile:

Je m'en réjouis beaucoup.

Paolo

J'ai l'intention de l'intégrer très prochainement :slight_smile:

En voila une bonne nouvelle !
cette integration est-elle déjà planifiée ?
pour la version 1.8 ?
2.0 ?
juste à l'etat d'intention ?

D'une manière générale, c'est vrai qu'on manque un peu de visibilité sur
Spip (ce qui est en partie responsable de toutes les conneries qui se disent
sur les developpeurs historiques ....).
La 1.8 par exemple nous est un peu tombé dessus sans qu'on la voit venir
(voila le choc !).
Il a été question recement des date de fin de vie d'un article, on ne sait
plus trop comment positionner spip par rapport à l'approche "base
documentaire", on sait juste que pour le moment ca n'est pas prévu, mais
sans vraiment avoir des points précis la dessus (sauf à plonger dans les
archives de la mailing list), alors comment savoir si on peut s'appuyer sur
une contrib ou non ?
idem pour les newsletter, interessant pour spip ou non ? et si oui, plutot
laquelle ? selon quelle approche de gestion des utilisateurs ?
...
Y a-t-il ou ne faudrait-il pas, un endroit ou les core-dev nous disent un
peu les axes de developpement à court et moyen terme ?
ce que spip fera demain et ce qu'il ne fera jamais (le café, dommage !)
Pas des grands discours, juste des news qui restent à un endroit (genre
wiki) et soient mises à jour de temps en temps.
Entre Spip, spip-contrib, le forum de spip-contrib, le labo et les autres
initiatives(bloog, eva, bio-spip ...), on s'y perd un peu et il est risqué
de se lancer dans un grand développement sans cette visibilité (Encore bravo
à ESJ !!!).
Aujourd'hui, on a plutot des annonce de spip-core sur l'arrivée des
nouvelles fonctionnalité, mais en amont, c'est un peu flou.
Je n'ai pas de solution miracle à proposer, je pense que le passage par la
phase contrib avant integration est une bonne chose.
Il nous faudrait peut etre à ce niveau (sur chaque contrib) un avis de
spip-core qui dise si sur le principe la fonctionnalité interesse et s'il
est prevu de l'integrer ou de la recoder, quels sont les points bloquant à
l'integration ...
Ca ne regle pas tous les problemes (sauf si les devs se mettent à faire des
contribs avant de modifier spip mais ca ne parait pas tres réaliste) mais ca
donnera au moins un peu de lisibilité, enfin, si tout le monde suit le meme
process.

En tous cas, moi qui suit ce projet depuis quelques mois deja, j'ai un peu
de mal à positionner tout ca, il serait peut etre bon que spip-core nous
fasse un petit topo sur ce qu'on peut faire, comment et ou pour faire
avancer les choses efficacement, non ?

Je me permets de m'exprimer malgré ma nouveauté sur le forum, déoslé si c'est inopportun

qu'est ce que vous penseriez d'utilisez un outil permettant de gérer efficacement les features,
bugs demandes et livraisons tel que jira ou bugzilla, ça permet d'avoir un suivi propre et simple
de tout ça en quelques clics ?

Julien

Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

D'une manière générale, c'est vrai qu'on manque un peu de visibilité sur
Spip

Nous aussi :slight_smile:

On essaie d'avoir un maximum de lieux de discussion, de points d'échange,
pour qu'il y ait des idées, qu'elles se développent, se confrontent,
s'améliorent etc. De tout ce magma sortent parfois des choses qui s'imposent
d'elles-mêmes, des choses attendues, des choses inattendues, etc.

Sur un plan plus théorique, on cherche à promouvoir l'autonomie de chacun ;
si on est sur le dos de tout le monde à donner notre avis, ça n'aide pas :slight_smile:
L'idéal c'est que chacun fasse ce qu'il croit être bon, en discutant de
manière ouverte avec les autres, et sans se soucier d'être "validé" par des
"historiques". Ca donne les projets les plus autonomes, dotés d'une
personnalité propre (exemples : EVA, biospip, forums phpBB, Dashboard).

Parfois il faudrait peut-être dire "stop" (sur les "nouveaux raccourcis" ou
les délires sur la création automatique de champs extra : recette pour se
planter), mais en même temps c'est assez pédagogique, ça montre comment
utiliser les ressources et points d'entrée qui existent ... et puis chacun
est assez grand pour savoir ce qu'il a envie de faire avec SPIP !

Par contre, le projet de SPIP Mag' pourrait servir à établir ce genre de
"perspectives", en essayant de façon journalistique de prédire l'avenir...
dans la rubrique horoscope ? -- http://mag.spip.net/

Par exemple, une piste intéressante vers laquelle on va très vite, c'est
un fonctionnement de certaines parties de SPIP en mode client/serveur. On en
trouve des morceaux sur http://wiki.rezo.net/test/TeX, d'autres sur le
correcteur d'orthographe ; si on se lance là-dedans, peut-être passera-t-on
d'autres éléments en client/serveur (chargement des langues, aide en
ligne, gestion des flux RSS, etc.). Autour de ça une réflexion et un peu de
journalisme permettrait de faire avancer les réflexions et remonter des
remarques. Mais ça ne va pas se faire non plus "tout seul" par la bonne
volonté des "core-dev" (un concept à élucider, d'ailleurs).

-- Fil

qu'est ce que vous penseriez d'utilisez un outil permettant de gérer
efficacement les features, bugs demandes et livraisons tel que jira ou
bugzilla, ça permet d'avoir un suivi propre et simple de tout ça en
quelques clics ?

Oui, en théorie... Mais on a essayé d'utiliser Mantis, et ça ne faisait
qu'ajouter un lieu de discussion à d'autres lieux existants -> on s'en est
quasiment totalement détournés.

A partir du moment où très peu de membres de la liste spip-dev essaient de
débugguer par eux-mêmes et de contribuer du code "ingrat" (les bug fixes),
ce type d'outil n'a guère d'intérêt.

-- Fil

Olivier Mansour wrote:

Avez vous discuter de l'intégration de cette petite chose également : http://www.spip-contrib.net/breve41.html

Je serais assez ennuyé que les développeurs l'intègrent telle quelle, car j'y lis:

"La combinaison de raccourci : [{{toto}}->http://perdu.com] N’est plus bonne ; il faut écrire : {{[toto->http://perdu.com]}} (grrrr de regexp [2] à la noix)"

La première combinaison se retrouve dans beaucoup d'articles de notre site. Et la deuxième n'est pas une solution car elle exclut la combinaison suivante: {[{{toto}}->http://perdu.com]} qui devrait alors être remplacée par:
{ {{[toto->http://perdu.com]}} }
ce qui rajoute des espaces supplémentaires peu élégants.

Yves Grenier

pour moi la partie la plus interessante se situe au niveau des tableaux, des
liens internes, du title sur les liens et des acronymes (à quand les abbr).
Cependant sur les tableaux j'utiliserai l'attribut scope="raws" ou
scope="cols" plus tot que headers et id car c'est tout aussi accessible pour
les lecteurs d'écran et synthese vocale et pose moins de problème (id
normalement limité à 15 charactere).
Sur le tableau de données à noter surtout qu'il y a bien des th au lieu des
td un summary et un caption

pour moi la partie la plus interessante se situe au niveau des tableaux, des
liens internes, du title sur les liens et des acronymes (à quand les abbr).

Abbr n'est pas compatible IE. Mais la sémantique de abbr est plus logique ...
http://www.blog-and-blues.com/2004/janvier/04/abbr_et_acronym_Dupon-t_et_dupon-d.asp

Cependant sur les tableaux j'utiliserai l'attribut scope="raws" ou
scope="cols" plus tot que headers et id car c'est tout aussi accessible pour
les lecteurs d'écran et synthese vocale et pose moins de problème (id
normalement limité à 15 charactere).

Je crois que c'est les recommandations de braillenet.org qui ont été suivie pour ce choix.

Olivier

Abbr n'est pas compatible IE. Mais la sémantique de abbr est plus
logique ...
http://www.blog-and-blues.com/2004/janvier/04/abbr_et_acronym_Dupon-
t_et_dupon-d.asp

oui mais ce n'est pas parcque cela ne marche pas sur ie qu'il ne faut pas
l'employer d'ailleurs ça marche sur ie avec cela:
http://dean.edwards.name/IE7/compatibility/abbr.html
ou cela
http://dean.edwards.name/my/abbr-cadabra.html

Je crois que c'est les recommandations de braillenet.org qui ont été
suivie pour ce choix.

Etant moi meme expert accessiweb nous en avons discuté et fait des tests au
sein du GTA, cette attribut et il fonctionne tous aussi bien, le désavantage
de headers et id c'est qu'un id doit etre unique donc si une personne met
dans la page deux tableaux ayant les même valeur de th cela entrainera des
problemes alors qu'avec scope non.
Headers et id sont mieux lorsque l'on a des tableaux très complexes mais les
possibilités de création de tableau que laisse spip étant limités scope me
parait mieux convenir.

Abbr n'est pas compatible IE. Mais la sémantique de abbr est plus
logique ...
http://www.blog-and-blues.com/2004/janvier/04/abbr_et_acronym_Dupon-
t_et_dupon-d.asp

oui mais ce n'est pas parcque cela ne marche pas sur ie qu'il ne faut pas
l'employer d'ailleurs ça marche sur ie avec cela:
http://dean.edwards.name/IE7/compatibility/abbr.html
ou cela
http://dean.edwards.name/my/abbr-cadabra.html

Je suis d'accord avec toi

Je crois que c'est les recommandations de braillenet.org qui ont été
suivie pour ce choix.

Etant moi meme expert accessiweb nous en avons discuté et fait des tests au
sein du GTA, cette attribut et il fonctionne tous aussi bien, le désavantage
de headers et id c'est qu'un id doit etre unique donc si une personne met
dans la page deux tableaux ayant les même valeur de th cela entrainera des
problemes alors qu'avec scope non.
Headers et id sont mieux lorsque l'on a des tableaux très complexes mais les
possibilités de création de tableau que laisse spip étant limités scope me
parait mieux convenir.

Merci pour l'info (pour ma part je n'y connais pas grand chose)
Je fais remonter cela

Si j'ai bien compris, toute les colonnes aurait scope="cols" ....
Je ne connais pas ces attributs. Pourrais tu nous donner un exemple d'utilisation.

Merci

Olivier

Si j'ai bien compris, toute les colonnes aurait scope="cols" ....
Je ne connais pas ces attributs. Pourrais tu nous donner un exemple
d'utilisation.

http://www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns
voilà les sources issus des WCAG il y a les deux exemples d'utilisation un
avec headers et id l'autre avec scope il dise clairement comme moi ou plutot
je dis clairement comme eux que les deux fonctionne aussi bien mais que
scope est plus adapté pour des tableaux simple ce qui est le cas des
tableaux produits par spip