[spip-dev] [SPIP Zone] SPIP et la représentation graphique des classes dominantes

Dev
1

Cédric a écrit :
« Quand à l'aspect fade et consensuel de FatCow c'est un autre
débat.
Le fait est que tant que personne ne se sera collé au long travail
de création/compilation/recherche d'un jeu d'icône complet dans les
tailles 16/24/32 il n'y aura pas d'alternative, et tout débat est
absolument stérile. »

Mais tout ce « long travail de création/compilation/recherche d'un jeu d'icône complet » est-il vraiment nécessaire ?
Pourquoi est-il plus important de trouver une solution, de « travailler » et « produire » que de réfléchir à sa pertinence et aux représentions véhiculées ? La stérilité n'est pas tant dans le débat, que dans son absence ou son éviction.

Non ce n'est pas plus important. Ce travail de production inclue bien évidemment la reflexion sur la pertinence et les représentations. Là ça fait 3 jours qu'on discute d'une icône, il sans doute multiplier par 100 pour avoir une idée de là où ça peut mener de constituer un jeu complet.
Je n'évite rien, je dis juste que on va pas attendre le résultat de ce travail forcément long pour sortir la prochaine version, et que ça ne permet donc pas de résoudre la question qui se pose là maintenant.
Mais ce serais très bien que des volontaires se saisissent de ce chantier !

Eh ben, tout ça pour un (ou une) icone… que chacun(e) peut changer
en fonction de ses goûts, culture, habitudes, envies, etc.

Se décharger sur l'hypothétique facilité de personnalisation est, encore une fois, une façon d'éviter de réfléchir l'interface, au rapport utilisateur et à ce qu'est SPIP. Ceci dit sans critique, juste pour mémo.

oui je suis d'accord. En pratique plein d'utilisateurs garderont les icones par défaut.

Et désolé de le dire aussi crûment : +1 quand Rasta dit « En
attendant... On sort SPIP 3. »

A ce sujet, où puis-je trouver la liste des apports de SPIP 3 pour les webmestres et utilisateurs, afin de rédiger mon traditionnel billet d'annonce ?

Il y a un billet en attente dans spip.net

Cédric

2

Cédric a écrit :
« Quand à l'aspect fade et consensuel de FatCow c'est un autre
débat.
Le fait est que tant que personne ne se sera collé au long travail
de création/compilation/recherche d'un jeu d'icône complet dans les
tailles 16/24/32 il n'y aura pas d'alternative, et tout débat est
absolument stérile. »

Mais tout ce « long travail de création/compilation/recherche d'un jeu d'icône complet » est-il vraiment nécessaire ?
Pourquoi est-il plus important de trouver une solution, de « travailler » et « produire » que de réfléchir à sa pertinence et aux représentions véhiculées ? La stérilité n'est pas tant dans le débat, que dans son absence ou son éviction.

Non ce n'est pas plus important. Ce travail de production inclue bien
évidemment la reflexion sur la pertinence et les représentations. Là
ça fait 3 jours qu'on discute d'une icône, il sans doute multiplier
par 100 pour avoir une idée de là où ça peut mener de constituer un
jeu complet.
Je n'évite rien, je dis juste que on va pas attendre le résultat de
ce travail forcément long pour sortir la prochaine version, et que ça
ne permet donc pas de résoudre la question qui se pose là maintenant.
Mais ce serais très bien que des volontaires se saisissent de ce chantier !

Pardon, ce n'était pas une attaque personnelle !

J'étais et reste volontaire et me suis déjà investie sur l'espace privé, à plusieurs reprises.

J'ai dernièrement fait une proposition, prototypale, que chacun peut critiquer et améliorer :
GitHub - tetue/lucidasimple: Rustine CSS expérimentale pour simplifier l'usage de l'espace privé de SPIP3
(ne pas tenir compte des mochetées que j'ai mises dans la barre de nav principale)

J'ai une approche pragmatique, qui repose sur un minimum d'icônes, puisque *nous n'avons pas* les ressources graphiques internes adéquates. Mais ma motivation première était la lisibilité de l'interface, que cet allégement graphique améliore.

Et désolé de le dire aussi crûment : +1 quand Rasta dit « En
attendant... On sort SPIP 3. »

A ce sujet, où puis-je trouver la liste des apports de SPIP 3 pour les webmestres et utilisateurs, afin de rédiger mon traditionnel billet d'annonce ?

Il y a un billet en attente dans spip.net

SPIP
Ok, j'étudie ça. C'est sensé être complet ou reste à compléter ?

-- romy

3

Hu hu !

4

Coucou,

J’étais et reste volontaire et me suis déjà investie sur l’espace privé, à plusieurs reprises.

J’ai dernièrement fait une proposition, prototypale, que chacun peut critiquer et améliorer :
https://github.com/tetue/lucidasimple
(ne pas tenir compte des mochetées que j’ai mises dans la barre de nav principale)

J’ai une approche pragmatique, qui repose sur un minimum d’icônes, puisque nous n’avons pas les ressources graphiques internes adéquates. Mais ma motivation première était la lisibilité de l’interface, que cet allégement graphique améliore.

Oui oui oui.
Il faut prototyper et on te fait confiance sur le sujet.
Et le plus on aura de prototypes au mieux on pourra rapidement mettre en place cela dans l’espace privé. Je suis partant pour coder mais pas pour prototyper car je ne pense pas être représentatif de l’utilisateur SPIP.

Maintenant, à mon avis il faut replacer les chantiers à venir dans une logique de roadmap suite à la sortie de SPIP 3.0.
Je serais d’ailleurs d’avis que cela apparaisse en filigrane dans l’annonce SPIP 3.0.

http://www.spip.net/ecrire/?exec=articles&id_article=5427
Ok, j’étudie ça. C’est sensé être complet ou reste à compléter ?

Possible qu’il reste des choses à préciser, comme les sites mis à jour, tradlang… je ferais aussi un tour en reprenant la roadmap de la taverne. En outre, je rajouterais la projection sur les 3.x à venir comme proposé ci-dessus.

5

Non, définitivement non.
Pourquoi vouloir absolument transformer ce débat en troll ?
Pourquoi instiller le doute quant à l'utilité de ce débat, emminemment plus large qu'une seule icone.
ça vous arrangerait tant que ça de croire qu'il ne faut pas se questionner sur ce que NOUS faisons ensemble ?
Vous pensez que vous prendre le choux pour des sauts de ligne est primordial par rapport aux représentations que vous véhiculez dans le choix des images ?
Et ça ne vous questionne pas plus que ça qu'il n'y ait que 2 ou 3 femmes pour coder dans SPIP, et encore, que sur les plugins ?
Quelqu'un réfléchit-il à y remédier?
Mais il va falloir le dire clairement s'il vous plait, parce que sinon je saurais pourquoi je quitte SPIP en colère.
touti

6

Bonjour,

J'interviens transversalement pour être abonné à la liste et trouver ce fil très très intéressant à plusieurs égards : je me permet de remettre le titre du fil qui m'y paraissait central pour des raisons que je vais expliquer.

Ce n'est pas la première fois que je rencontre ce type de débat sur un projet à vocation collaborative et j'y retrouve beaucoup d'éléments déjà rencontrés en d'autres "lieux" et "occasions".

- la réception négligante voire abrupte des remarques sur le caractère genré et racial dominant des graphismes et parfois même du langage
- la considération d'autant diminuée que les intervenantes et au-delà les personnes appartenant à des "minorités" s'expriment forcément "en minorité"
- des choses qui mine de rien s'expriment et qui ne peuvent qu'être très blessantes à l'égard de personnes posant ce problème qui relève - excusez le rappel - du concret puisque participant de notre vie de tous les jours : le codage oui c'est du travail, mais qu'en est-il du travail de chacun à essayer d'être un type un peu moins con, tâche beaucoup moins aisée et de plus longue haleine ?

Le travail technicien me parait souvent ruiné par cette désinvolture qu'on peut écouter ou lire s'exprimer parfois à l'égard du contexte - je dirais - planétaire dans lequel il s'applique. Le projet SPIP m'a toujours plu parce qu'il donnait leur place aux utilisatrices et utilisateurs non-techniciens et par là même suggérait une forme de conscience de la domination par la technique, voire de la domination par le surinvestissement, et pour finir de la domaination en général. Pour ma part si je suis viscéralement attaché aux pratique collaboratives, les promeut et les encourage c'est parce que précisément elles constituent une véritable alternative au rapport de domanant à dominé.

Voir projeté de temps à autre le principe vicié du rapport des uns et des unes aux autres des sociétés contemporaines : la mesure du poids de l'avis de la personne à l'aune de sa contribution. Si je parle ici de rapport vicié c'est que je considère comme une négation de l'être humain, dont l'énergie, la capacité, l'intruction et le contexte personnel varient à l'extrême. En d'autres termes je tiens la capacité à l'écoute comme une qualité ne pouvant se mesurer qu'à l'égard de n'importe qui, quelle que soit la part d'effort que soi même en tant que bénévole on est capable de déployer.

J'apprécie tout le travail que vous faites et je reconnais sur les années la place des contributions de certains.

Mais lire "Ouf" ici n'est pas neutre. C'est peut-être même le pire lu jusqu'ici en dépit des échanges vifs lus sur ce fil. Parce que ce "Ouf" à lui seul revient à cracher à gueule de celles qui posé le problème au départ, celà avec négligeance mais de manière tout à fait claire. Il suggère que les échanges vifs qui précédaient faisaient s'opposer des considérations "non-constructives", "pas concrètes" à des propositions qui elles seraient d'un ordre clairement "supérieur", en d'autres termes "puisqu'émanant de "gens / de mecs / qui bossent, / eux / qui sont dans le conret /eux /", bien plus prioritaires.

Excusez-moi mais on ne saurait plus exprimer la dimension désespérante du fonctionnement de la société aujourd'hui et qui systématiquement balaie les problèmes d'un revers de manche sans s'y atteler vraiment, et s'attelant chaque fois qu'un problème important se pose, à en poser d'autres et à s'y consacrer. Et qui ne manquent pas d'occasion de lâcher un mot de trop sans y réfléchir avant.

Donc si effectivement je suis séduit par l'hypothèse que spip 3 puisse adopter une charte en noir sur blanc pour ses icônes quitte à mélanger des reports des icônes actuelles qui vont bien dans cette gamme et les emprunts au projet noun, et éventuellement prêt à contribuer puisque je peux faire des graphismes, je voulais juste marquer le coup sur ce "Ouf" insultant dans le contexte.
L'attention à ce que véhiculents les images et en particulier leur signifié pour les personnes est un point important. Je dirais bravo à qui l'a rappelé fort opportunément avant que le projet SPIP reprenne par négligeance dans sa forme des archétypes à l'antithèse de ses prémices.

Excusez-moi pour cette interruption : une critique sur le fond est toujours quelque chose de concret dans un projet qui se voudrait autre chose qu'un travail de robot.

Merci.

@+

Philippe

7

C'est bizarre mais en SPIP c'est juste. "Aussi peu que ce soit" à l'échelle du projet, j'en suis, à ma manière. Pour ce qui est du core et des plugins, je tente de suivre, observer, comprendre. Je me reproche (un peu) de ne pas assez considérer être dans ce NOUS. Voilà pourquoi je finis par moi aussi écrire mon expérience de la chose. Même si je sais/crains que je ne ferai rien pour la réalisation. Cela m'entraîne par contre à réfléchir à l'économie de moyens.

Tout d'abord, j'ai dû réactiver les icônes dans mon spip3 de test pour voir de quoi on parlait. En fait dans les écrans larges et pas très hauts, les icônes (belles) du bandeau prennent trop de hauteur et augmentent le "taux de scroll". Reste cette icôné genrée, dans la fine barre de raccourcis.

Ma proposition serait d'utiliser l'icone "informations perso" pour les auteurs. Elle me parait suffisamment stylisée pour échapper aux reproches justement émis (mais si ce n'est pas le cas, je me tais).

http://core.spip.org/projects/spip/repository/changes/spip/prive/themes/spip/images/information-perso-32.png

Au surplus, Pourquoi ne livrerait-on pas spip3 avec les icônes désactivées par défaut ? On pourrait proposer de les remettre via le compagnon ? Mettre un message expliquant le pourquoi du choix de la série sélectionnée et appelant aux contributions ? Ou proposer une variété via un sélecteur de thèmes ?

Voilà, voilà.

Paix, amour, tendresse, bisouxxxxxx.

8

Je découvre grace à ce mail sur spip-dev ce thread dont on se demande ce qu'il fait sur spip-zone vu son contenu.
Car le fond du problème est l'organisation du travail dans SPIP.
La version 1.9.2 a été la dernière à sortir à distance raisonnable de la précédente.
Les versions suivantes sont sorties tardivement et dans la douleur,
et j'ai le droit de dire que si je n'avais pesé de tout mon poids pour qu'elles sortent,
on peut se demander si elles seraient jamais sorties.
En témoigne le fait que depuis que j'ai annoncé qu'il ne fallait plus compter sur moi pour sortir une version majeure,
aucune n'est sortie depuis 20 mois, le triste record de 22 mois séparant la 1.9.2 de la 2.0 va être battu.

Un développement normal consiste à sortir régulièrement une version ne comprenant que ce qui fait consensus,
en laissant le reste dans une branche de développement en attendant un futur consensus.
Au lieu de ça on pratique la fuite en avant: frustré que son idée ne fasse pas consensus,
chacun développe une nouvelle idée dans la branche principale pour se consoler,
semant la graine d'un nouveau dissensus et ainsi de suite.
Le comble est atteint lorsqu'un consensus se fait sur une vieille idée sans que ça débouche sur la sortie d'une version.
Eric et moi avons longuement exposé comment remplacer les mal fichus plugin.xml, puis avons commencé l'implémentation lorsque tous les avis ont été débattus.
Un désaccord est intervenu sur une broutille, savoir le contenu de la balise "description".
Une branche à part a été créée, par un acte d'autorité désagréable mais pas forcément grave.
Depuis environ un an la broutille a trouvé sa solution, on aurait pu sortir la 2.2 initialement prévue,
notamment pour la date anniversaire des 10 ans de SPIP, mais non, on préfère s'empailler sur des idées apparues entretemps.

Le constat est donc clair: SPIP n'est plus un logiciel fait dans la tendresse par une équipe à l'écoute des besoins du milieu associatif désirant un outil clé en mains, c'est devenu une plateforme technologique utilisable seulement par des geeks ayant un accès SVN, et développé par des individualités qui n'écoutent plus le milieu associatif, et ne s'écoute même plus elle-même. Tant qu'il n'y aura pas une réflexion profonde sur pourquoi on en est arrivé là, inutile d'espérer la sortie d'une nouvelle version. A moins d'un nouvel acte d'autorité qui enterrinerait la disparition de l'esprit initial du projet, ce qui n'est pas à exclure: les pratiques collectives anti-autoritaires génèrent bien souvent un didacteur se présentant comme héritier du mouvement. Rien de neuf sous le soleil (d'Austerlitz et de Moscou) hélas.

Emmanuel

9

J'aimerais bien retrouver le message de Marcel mais je n'y arrive pas, tellement il est perdu dans cet écheveau de 110+ messages... Alors tant pis je répond ici, sans pouvoir me référer au message, et donc de mémoire.

Je suis content que ce Ouf t'ait permis de t'exprimer et d'apporter cet éclairage sur le débat et sur la réclamation faite par tutti.

Je regrette toutefois que cette expression soit si tardive : cela fait 2 ans que SPI3 est lancé, et 10 mois, je crois, que fatcow a été mis en place. Or SPIP n'est pas une icone immaculée et immuable dans l'espace virtuel : SPIP est le fruit de l'action de ceux qui s'en donnent le temps, au quotidien.
SPIP c'est le reflet de nos non-interventions autant que de nos interventions.
Or depuis 2 ans, sans même parler de code ou de contribution graphiques, ta voix et d'autres ne se sont pas fait beaucoup entendre dans la galaxie SPIP sur ce sujet, et sur d'autres comme le non sexisme, le web indépendant, la non domination...
C'est pourtant la *seule* manière possible pour que les causes défendues soient prise en compte dans SPIP.

Et cet échange va dans les 2 sens. Ce n'est pas juste SPIP qui donne un outil aux alternatives, mais les alternatives qui donnent du sens à SPIP. Car sinon quel sens donner au développement de SPIP, à l'heure de wordpress, joomla, drupal et autres CMS mondialement écrasants ?
SPIP, gaulois et non marchand, n'est pas une initative conforme aux valeurs dominantes. Ce n'est pas facile souvent de continuer ce travail. Pour les devs, c'est un effort aussi. Un gros effort parfois. Sisyphe un peu.
Aussi, *défendre une alternative est un besoin vital pour SPIP*.

Les discussions informelles se font beaucoup sur IRC notamment.

Des voix comme la tienne, et comme celles qui avant la tienne se sont élevées dans ce thread, sont donc bienvenues, et ce d'autant plus qu'elles s'expriment tôt, en phase avec le développement, non dans le vitriol mais dans la coopération et dans la recherche partagée de solutions. Elles apporteraient alors un sens pour la finalisaiton de SPIP3, ou pour le développement futur de SPIP4. Bienvenue aux intelligences non dupes des valeurs dominantes, aux bonnes volontés... et aux infographiste-s aussi ! (l'un n'empêchant pas l'autre).

A propos du jeu d'icone, il est possible qu'un spipeur s'y colle bientôt. Il sera utile que les personnes les plus concernées s'expriment aussi parfois pour confirmer le sens des travaux lorsqu'ils vont dans le bon sens.

A part ça, dans un des points, tu évoques le fait que les classes non dominantes ont nécessairement une expression dérangeante. Je ne sais plus exactement comment tu l'exprimes, c'est peu développé (ça mériterait plus). C'est un encouragement à accepter ces formes d'expressions chargées, à les comprendre.
Pour ma part, nombre de messages dans ce thread m'ont fait souffrir par la violence/souffrance qu'ils expriment et provoquent.
Or, je crois que SPIP peut intégrer les demandes alternatives, et rester porteur des associations, des utilisateurs de base, du web indépendant, des classes et des valeurs non dominantes... C'est avec soulagement que j'ai accueilli une proposition qui m'apparaissait pouvoir aller dans ce sens : ouf.

JLuc

10

Je suis aussi d'avis que décider d'une nouvelle organisation de la doc est un chantier beaucoup plus prioritaire que tout ce qui a été entrepris depuis que SPIP3 a été annoncé. Il y a déjà une réflexion d'engagée pour l'aide en ligne ici:

http://blog.smellup.net/spip.php?article43

Ce site est de facto celui où se font les discussions qu'il y avait auparavant sur spip-dev qui est de moins en moins utilisé:

http://dir.gmane.org/gmane.comp.web.spip.devel

tout le monde peut y participer.

Committo,Ergo:Sum

11

Hello,

Quelques précisions :

12

SPIP-Dev est ouvert à tout le monde c'est exact mais pas le blog cité plus haut, en dehors des forums.

justement, ceux-ci suffisent à remplir la fonctionnalité délaissée de spip-dev.
Et son caractère graphiquement plus élaboré qu'un liste de discussion fait que le contenu des messages est plus élaboré.

Sinon pour une refonte de la doc globalement, Romy a déposé un billet sur le Blog de SPIP : http://www.spip-blog.net/Typologie-des-utilisateurs-pour-reconquete.html

Ce billet aborde beaucoup de problèmes à la fois. Je pense d'abord qu'il faut se mettre d'accord sur la manière d'accéder à la doc, étant pour ma part convaincu que celle utilisée jusqu'à présent, savoir un serveur central, n'est plus la bonne depuis que l'essentiel du développement se fait par plugins avançant chacun à leur rythme, et que beaucoup de site sont mis à jour par svn quasi quotidiennement. Maintenant que le fichier de description d'un plugin indique les modules de langue, et que le nouveau site de traduction va permettre de prendre en compte plus rapidement le travail des traducteurs, je pense que la doc doit être incluse sous forme de fichier de langues dans le répertoire "lang" du noyau de SPIP et des plugins. On peut espérer aussi que ça encourage les développeurs à rédiger un peu de doc au moment d'un Commit. Ils le font souvent dans le message de log, qui est difficile à retrouver qq temps plus tard, là il leur suffirait de le mettre dans un certain fichier, et le message de log se contenterait de le citer.
Committo,Ergo:Sum

13

Bonjour,
je te rejoins sur le fait qu’il y a un vrai travail de réorganisation et refonte de la doc. Reste à trouver / penser une réorganisation fonctionnelle et simple à prendre en main à la fois pour les dev / rédacteurs de doc / traducteurs / utilisateurs.

L’article de Romy mets bien en évidence qu’il y a différents types de docs à destination des utilisateurs. De la doc technique, de la doc d’utilisation d’un plugin, de la doc utile pour un rédacteur ou seulement pour un admin, de la doc à lire avant d’installer et de la doc qu’on a besoin d’avoir sous la main (aide en ligne par exemple).

Je n’ai pas encore vu la nouvelle interface de traduction en ligne (pas encore ouverte). Je suis certain qu’elle apportera un confort et une praticité accrue pour la traduction.

Concernant l’aide en ligne, j’ai déjà vu ton message sur http://blog.smellup.net/spip.php?article43#forum119 pronant le recours à des chaines de langue. Cela n’est pas sans poser un certain nombre de problèmes techniques qui ne sont d’ailleurs pas que les images (car il y a aussi tout le code HTML ou raccourcis SPIP utilisé dans les fichiers d’aide), les questions de fusion de l’aide en ligne, etc. Malgré cela, il me semble qu’une aide en ligne ou aide embarquée vise en tout premier lieu l’utilisation d’un plugin, notamment pour un rédacteur.La doc de configuration (à destination de l’admin général / webmaster) peut également y figurer mais il faudrait aussi éviter de trop “polluer” un simple rédacteur avec de l’info qui ne le concerne pas (trop d’info tue l’info). Il reste donc que la doc plus technique, d’installation, ou à destination des développeurs ne doit peut-être pas être directement dans les fichiers d’aide en ligne, ou alors il faudrait vraiment revoir tout l’affichage des fichiers d’aide pour “filtrer” l’info selon le type de lecteur. Et ça pose alors la place de Contrib. Quelle complémentarité avec ce site.

Tu évoques un passage par des chaines de langue plutôt que par des serveurs d’aide pour une question d’adéquation. Dans la proposition évoquée sur la taverne à tonton, les modules de langue seront versionnés, ce qui permet d’avoir différentes versions. Il suffit dès lors d’avoir une adéquation entre le numéro de version déclarée dans paquet.xml et sur le serveur. Le passage en chaines de langue ne résoud pas tous les problèmes de versionnage. Concernant les traductions, la version actuelle de tradlang (je sais pas pour la nouvelle version et peut-être ai-je tord) ne gère qu’une seule version d’un fichier de langue. Je ne peux donc pas avoir en même temps le fichier de langue de la branche 1 et de la branche 2 d’un même plugin. Par ailleurs, si on introduit des fichiers de langues distants comme tu l’évoquais, il y aurait les mêmes soucis d’écarts potentiels entre la version du serveur SVN et celle du plugin installé. Enfin, passer par des chaines de langue viendrait me semble-t-il compliquer la tâche de ceux qui ne développent pas mais consacrent du temps à rédiger de l’aide / de la doc car il faudrait alors rédiger la langue de référence en PHP sur le serveur avant que ce;a passe à la moulinette de trad_lang.

Désolé pour ce mail un peu long, d’autant plus que je ne réponds qu’à intervalles irréguliers en cette période de fêtes de fin d’années. Je n’ai pas d’a priori pour ou contre des serveurs de rédaction versus des fichiers de langue. C’est un début de réflexion et c’est collectivement que nous trouverons le meilleur compromis entre les avantages et inconvénients de chaque manière de faire.

Merci en tout cas de ta réaction sur la taverne. C’est effectivement le bon endroit pour en discuter (j’y reporterais une partie des remarques contenues dans ce mail quand j’aurai un poil plus de temps). Dans tous les cas, l’objectif n’est pas de se précipiter mais bien de trouver les outils permettant de rédiger et développer plus facilement de la doc.

Bien amicalement et cordialement

Joseph

14

Tu évoques un passage par des chaines de langue plutôt que par des serveurs d'aide pour une question d'adéquation. Dans la proposition évoquée sur la taverne à tonton, les modules de langue seront versionnés, ce qui permet d'avoir différentes versions. Il suffit dès lors d'avoir une adéquation entre le numéro de version déclarée dans paquet.xml et sur le serveur. Le passage en chaines de langue ne résoud pas tous les problèmes de versionnage. Concernant les traductions, la version actuelle de tradlang (je sais pas pour la nouvelle version et peut-être ai-je tord) ne gère qu'une seule version d'un fichier de langue. Je ne peux donc pas avoir en même temps le fichier de langue de la branche 1 et de la branche 2 d'un même plugin.
Par ailleurs, si on introduit des fichiers de langues distants comme tu l'évoquais, il y aurait les mêmes soucis d'écarts potentiels entre la version du serveur SVN et celle du plugin installé.

Non, parce que SPIP peut demander à SVN de lui ramener le fichier lang/truc.php à la date du commit NNN.
Je ne vois fondamentalement pas l'intérêt du gros travail de développement que serait un serveur d'aide versionnée, car ces versions existent déjà sous Subversion. Comme tu le dis ce qu'il faut c'est la correspondance entre le numéro de version du code (dans plugin.xml) et le numéro correspondant de la doc.
Si le code et la doc sont sur le même serveur (ce qui se passe avec les fichiers de langue), on peut postuler que la doc correspondante est l'état des fichiers de langue à l'époque du commit qui a modifié la numéro de version du code dans plugin.xml (ce qu'on retrouve par "svn praise", mais "svn info", moins couteuse, fournit aussi une bonne approximation). C'est postuler que les développeurs écrivent la doc en même temps qu'ils changent le numéro de version, ce qui est aujourd'hui loin d'être la règle, mais si on l'énonce clairement elle pourrait être adoptée facilement.

Il y a évidemment du boulot à faire, mais il me paraît moindre que de développer un service d'aide versionnée à partir de zéro, et l'essentiel du code (l'assemblage en une page HTML unique de bouts de doc provenant de plusieurs fichiers distants) est déjà écrit dans l'aide en ligne actuelle: il ne manque que l'interface à Subversion, un peu plus compliquée que celle à un serveur Http (i.e. spipnet).

Enfin, passer par des chaines de langue viendrait me semble-t-il compliquer la tâche de ceux qui ne développent pas mais consacrent du temps à rédiger de l'aide / de la doc car il faudrait alors rédiger la langue de référence en PHP sur le serveur avant que ce;a passe à la moulinette de trad_lang.

Mais non: c'est au développeur de mettre ses chaînes de langues dans un fichier de langue, et ensuite de les référencer dans ses squelettes explicitement (par la syntaxe <:....:>) ou implicitement (la balise AIDER). Ensuite, il déclare ce fichier de langue, si ce n'est déjà fait, dans le fichier

et c'est ce qui fait que trad_lang:
http://trad.spip.org/
propose au traducteur la liste des fichiers à traduire.

Avec la proposition d'Eric faite ici:

le fichier traductions.txt est même maintenant produit automatiquement.

Committo,Ergo:Sum

15

Hello,

16

Mais non: c'est au développeur de mettre ses chaînes de langues dans un fichier de langue, et ensuite de les référencer dans ses squelettes explicitement

...

Je vais répondre sur la taverne.

Vu, et j'ai répondu:

Committo,Ergo:Sum

17

Autant je suis d'accord avec vous sur la nécessité de travailler la doc, autant je suis perplexe à la lecture de cet article, dont je ne comprends pas grand chose, dès les premières phrases. Est-il nécessaire que ce soit si compliqué ? Si je veux juste participer à la rédaction de l'aide, que puis-je faire ? Ne peut-on pas juste utiliser un nouveau site SPIP pour ce faire ?

-- romy

18

Coucou,

19

Qu'il y ait du bruit dans la discussion, ça n'a rien d'extraordinaire.
En l'occurrence cela concernait la masse de travail et le temps à envisager avant de disposer d'un nouveau jeu d'icône si on repart de zéro, ce qui ne veut pas dire que ça soit inutile.

Pour le débat qui concerne le thread, je fais quand même remarquer qu'on essaye d'avancer, en écoutant les remarques de chacun, et en proposant un certain nombre d'évolutions qui vont dans le bon sens il me semble.
Je n'arrive pas vraiment à savoir ce que tu en penses, si ce n'est que je crois avoir compris que tu n'envisages pas autre chose qu'une silhouette monochrome ou un animal.

Si je résume, la question primordiale qui est à l'origine de la discussion est :
est-ce que la dernière proposition te semble véhiculer encore l'image d'une caste dominante au détriment de toutes les autres ?
ou est-elle assez transversale pour être acceptable ?

Cédric

Le 13 déc. 2011 à 14:40, touti a écrit :

Non, définitivement non.
Pourquoi vouloir absolument transformer ce débat en troll ?
Pourquoi instiller le doute quant à l'utilité de ce débat, emminemment plus large qu'une seule icone.
ça vous arrangerait tant que ça de croire qu'il ne faut pas se questionner sur ce que NOUS faisons ensemble ?
Vous pensez que vous prendre le choux pour des sauts de ligne est primordial par rapport aux représentations que vous véhiculez dans le choix des images ?
Et ça ne vous questionne pas plus que ça qu'il n'y ait que 2 ou 3 femmes pour coder dans SPIP, et encore, que sur les plugins ?
Quelqu'un réfléchit-il à y remédier?
Mais il va falloir le dire clairement s'il vous plait, parce que sinon je saurais pourquoi je quitte SPIP en colère.
touti

Le 12/12/11 14:23, Eric a écrit :

Hu hu !

Le 12 décembre 2011 11:55, cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com> <cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com>> a écrit :

   Non ce n'est pas plus important. Ce travail de production inclue
   bien évidemment la reflexion sur la pertinence et les
   représentations. Là ça fait 3 jours qu'on discute d'une icône, il
   sans doute multiplier par 100 pour avoir une idée de là où ça peut
   mener de constituer un jeu complet.

80 mails pour un icone et 3 jours de débat voire 4.
Pour 100 icones, 8000 mails et 400 jours.... de débat :stuck_out_tongue:
Aller en vant pourle chantier de SPIP 4 :wink:

++
Eric

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

20

Bonjour,

Je suis les discussions sur ce sujet depuis un moment, et forcément au bout d'un moment on a envie de donner son avis...
Je ne crois pas qu'on peut répondre au problème de fond en gommant les indices visuels de l'appartenance à un groupe. Si on prend une image comportant des cheveux et un vêtement, la personne qui regarde est habituée à décoder ces indices, donc elle cherchera tout à fait inconsciemment à associer la figurine à un groupe. Si les indices sont flous, chacun se fera sa propre idée, mais tout le monde s'en fera une.
Si on ne veut pas véhiculer de notion de groupe, il vaut mieux partir d'une silhouette complètement stylisée, sans aucun des indices de la vraie vie (donc sans cheveux, sans vêtements et d'une couleur qui ne peut évoquer une couleur de peau), comme le logo actuel de SPIP, les figurines de MSN ou de Skype. Ce ne sont pas forcément des silhouettes monochromes.
Une figurine d'animal facilite aussi les choses, mais il y a des significations culturelles : un cochon ou un serpent véhiculent des stéréotypes. Par contre un écureil ça fait plus "communauté SPIP", c'est plutôt pas mal.

Bon, ceci dit je ne suis pas graphiste alors je n'ai rien à proposer. Et je ne trouve rien dans Fatcow...

Fabrice

Le 13/12/2011 15:30, cedric.morin@yterium.com a écrit :

Qu'il y ait du bruit dans la discussion, ça n'a rien d'extraordinaire.
En l'occurrence cela concernait la masse de travail et le temps à envisager avant de disposer d'un nouveau jeu d'icône si on repart de zéro, ce qui ne veut pas dire que ça soit inutile.

Pour le débat qui concerne le thread, je fais quand même remarquer qu'on essaye d'avancer, en écoutant les remarques de chacun, et en proposant un certain nombre d'évolutions qui vont dans le bon sens il me semble.
Je n'arrive pas vraiment à savoir ce que tu en penses, si ce n'est que je crois avoir compris que tu n'envisages pas autre chose qu'une silhouette monochrome ou un animal.

Si je résume, la question primordiale qui est à l'origine de la discussion est :
est-ce que la dernière proposition te semble véhiculer encore l'image d'une caste dominante au détriment de toutes les autres ?
ou est-elle assez transversale pour être acceptable ?

Cédric

Le 13 déc. 2011 à 14:40, touti a écrit :

Non, définitivement non.
Pourquoi vouloir absolument transformer ce débat en troll ?
Pourquoi instiller le doute quant à l'utilité de ce débat, emminemment plus large qu'une seule icone.
ça vous arrangerait tant que ça de croire qu'il ne faut pas se questionner sur ce que NOUS faisons ensemble ?
Vous pensez que vous prendre le choux pour des sauts de ligne est primordial par rapport aux représentations que vous véhiculez dans le choix des images ?
Et ça ne vous questionne pas plus que ça qu'il n'y ait que 2 ou 3 femmes pour coder dans SPIP, et encore, que sur les plugins ?
Quelqu'un réfléchit-il à y remédier?
Mais il va falloir le dire clairement s'il vous plait, parce que sinon je saurais pourquoi je quitte SPIP en colère.
touti

Le 12/12/11 14:23, Eric a écrit :

Hu hu !

Le 12 décembre 2011 11:55, cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com> <cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com>> a écrit :

    Non ce n'est pas plus important. Ce travail de production inclue
    bien évidemment la reflexion sur la pertinence et les
    représentations. Là ça fait 3 jours qu'on discute d'une icône, il
    sans doute multiplier par 100 pour avoir une idée de là où ça peut
    mener de constituer un jeu complet.

80 mails pour un icone et 3 jours de débat voire 4.
Pour 100 icones, 8000 mails et 400 jours.... de débat :stuck_out_tongue:
Aller en vant pourle chantier de SPIP 4 :wink:

++
Eric

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

-----
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2012.0.1873 / Base de données virale: 2108/4677 - Date: 12/12/2011