Parenthèse sur le carnet/wiki : d’un point de vue sémantique, le mot « carnet » me faisant penser à « carnet de notes », y trouver des contributions « brouillons » (dans le sens de pas encore abouties) me paraît très cohérent… et utile aussi, mais peut-être pas pour le « grand public », sauf si c’est très clairement mentionné/affiché.
J’ai pas encore précisé mais ma première (tentative d’)installation remonte à SPIP1.
Mes premières installation/utilisation remonte à SPIP2 mais étant (involontairement) hermétique à la syntaxe SPIP, j’étais assez rapidement aller voir ailleurs.
C’est à partir de SPIP3 que j’ai vraiment commencé à m’intéresser/utiliser SPIP ponctuellement pour répondre à différent.e.s besoins/demandes.
Puis est arrivé SPIP4 ! A partir de là, même si c’était en pointillés, j’ai vraiment accroché 
Et quand je suis récemment repassé pour savoir ce qui se tramait dans les tuyaux (avec SPIP5 en vue)… je suis tombé sur la page : Des équipes pour SPIP 
Voilà pour la petite histoire.
Même si vous vous prenez un peu la tête entre vous, ce qui se passe en ce moment dans la communauté SPIP est juste magnifique.
Je tenais à vous en faire part.
NB : au cas où il y aurait besoin de préciser, quand je « like », comprendre +1
3 « J'aime »
Je vois bien ce que tu décris, je le fais sur spip.net et désolé si ça te semble chiant, mais amha tout ça c’est ce qu’on appelle « une ligne éditoriale » pour employer de grands mots. Le but étant de publier de la doc rédigée en commun afin de s’assurer qu’elle soit bien compréhensible par les personnes à qui elle s’adresse. Sans ça, je ne vois pas à quoi la doc en question peut servir.
1 « J'aime »
Il y a deux éléments absents de contrib.spip.net et qui trouveraient une place adéquate dans Vie de SPIP.
- Une présentation des contributions pour le multilinguisme et l’utilisation internationale de SPIP,
- les exemples d’utilisation de SPIP hors de France ou dans un contexte linguistique autre que français.
- A ceci pourraient s’ajouter des modes d’emploi style How To sur la création et le maintien de sites plurilingues ou dans les langues autres que le français.
Ce mini-projet dépasserait la simple documentation technique et ne trouverait donc pas sa place sur le site SPIP principal.
Si vous voulez bien m’indiquer une sélection d’articles et de personnes à contacter, je me propose de créer des secteurs en allemand et anglais sur sa vie dans le monde. Dans un deuxième temps il est possible de créer aussi une version française de cette rubrique. Avec les outils modernes j’avance très vite dans la traduction d’articles, alors ce projet m’a l’air faisable.
Depuis un bon moment SPIP ne se montre que comme un projet franco-français alors qu’il a une « vie » internationale dont personne ne s’occupe sauf, point fort de SPIP, qu’à travers les chaînes de langue et de trad.spip.net pour en produire le contenu.
Il serait sympa d’avoir enfin un espace pour faire comprendre aux potentiels utilisatrices et utilisateurs internationaux que SPIP est pour tout le monde, que c’est une communauté internationale, et que c’est toujours l’unique outil dans la catégorie des CMS « pro » vraiment indépendant et FLOSS, parce que SPIP n’a toujours pas de propriétaire sauf ses utilisatrices et utilisateurs qui sont en même temps ses contributeurs et développeurs. L’aisance avec laquelle on manipule SPIP serait alors tangible pour un public international.
D’ailleurs quand j’ai besoin d’une information j’utilise un moteur de recherche en limitant les résultats à l’origine « spip.net » parce que la multitude de sites et structures de présentations différents rend difficile une approche plus structurée. Un secteur plurilingue sur les questions et expériences des utilisatrices internationales pourrait alors contribuer à rendre SPIP plus accessible à travers la présentation des expériences qu’on a pu avoir. En s’y prenant comme çà on obtiendrait aussi une petite liste des solutions principales pour les « problèmes » les plus répandues de l’utilisation SPIP .
:-)k++
1 « J'aime »
Remettre en avant l’internationalisme est une très bonne idée si ya des motivés, tu as raison.
Cependant pour ce qui est du lieu, il me semble encore que la doc centrale spip.net serait plus appropriée. En effet :
- tout est déjà structuré pour le multilinguisme, avec des traductions de documentations entre langues
- il y avait déjà dès l’origine quasiment, des contenus de type « tutoriel pour un sujet » ou inversement « exemple complet transversal »
Si ces contenus ne sont plus à jour, il faut :
- soit les réécrire
- soit les archiver et en écrire d’autres
- dans tous les cas en écrire des nouveaux pour augmenter le nombre de tutoriels de ce type
Il y a donc un « déjà-là » qui me fait dire que ça serait mieux de continuer à faire ça dans spip.net et au contraire continuer à réduire au maximum les choses « non plugins » dans Contrib/Plugins, ce qui permettrait de rendre moins confus la recherche de contenus : dans Contrib on saurait qu’on y trouve vraiment quasiment que ce qui a trait aux plugins + le wiki de la commu.
Et l’ancien tutoriel archivé qui n’apparait PLUS en ligne : SPIP
+1
Merci @eric_tonton et @rastapopoulos ,
voici comment je vois les rôles des sites de ma perspective d’utilisateur :
- spip.net - tout ce qui est documentation technique des base + tutoriels + référence voire « Glossaire - SPIP »; pour néophytes + utilisateurs sans connaissance approfondie de PHP/SQL
- programmer.spip.net - manuels des fonctions internes + tutoriels; pour les « pros » et les « devs »
- plugins.spip.net - référence + repo des plugins; pour webmestres
- trad.spip.net - outil de coordination des traduction de tous les module et plugins de SPIP; pour les devs, webmestres et traducteurs
- blog.spip.net - annonces + texte de réflexion, gazette SPIP; pour toute la communauté SPIP
- contrib.spip.net - tout ce qui n’est pas dans les sites précédents cad. documentation + modes d’emplois des plugins, doc provisoire sous forme de wiki, documentation qui dépasse le cadre basique de spip.net et ne rentre pas dans programmer.
A partir de cette vue des sites j’ai proposé d’intégrer dans contrib / vie de SPIP un secteur plurilingue sur les expériences et les personnes de la communauté internationale.
Je ne veux surtout pas réérire la doc sur le multilinguisme mais je sais qu’il reste du boulot à faire: traductions, mises à jour etc. surtout dans spip.net
Ce que je propose c’est plutôt du journalisme ou du « marketing » auprès du monde qui s’intéresse sérieusement à SPIP pour des raisons diverses. Ma motivation personnelle pour la création d’un espace de ce genre est de mieux comprendre la relation entre l’expérience de SPIP, la mienne comme celle des autres, et les aspects techniques précis. La doc technique ne serait que référencée dans ce secteur de « vie » que sous forme de lien et de retour d’expérience. J’aimerais présenter les personnes et leurs projets qui ne sont pas issus d’un contexte français.
Je pense que je peux le faire si je ne dois pas tout écrire tous seul, mais je veux bien rédiger, traduire, structurer, faire le travail éditorial quoi. Mes propres textes dans ce contexte ne parleront que de moi et de mon expérience. J’essaierai donc de faire comprendre mes approches qu’on peut sans doute améliorer.
Voilà j’espère avoir été plus clair que dans mon premier message à propos de « Vie de SPIP ».
:-)k++
Totalement obsolète aussi, à ne pas garder (des articles de 10, 15 ou 20 ans).
Il y a plusieurs rubriques comme :
Communauté SPIP
SPIP Gazette
Iconographie de SPIP
Pistes d’évolution pour SPIP
qui paraissent un peu bordéliques mais qui sont des traces d’une histoire, ce serait bien de ne pas les perdre, de ne pas les reléguer au fin fond d’un blog non plus.
Quitte à les réorganiser un peu, les regrouper ensemble dans une rubrique.
Ça c’est un piège, c’est très vite obsolète en fonction des évolutions de SPIP et de celles des hébergeurs (tarifs, fonctionnalités…)
1 « J'aime »
+1, le carnet n’est pas une poubelle, merci pour lui.
La défense du carnet est hors sujet, mais pas sa critique ? Je me permet donc de répondre ici.
Hihi
J’ai mis :love: sur ta réponse car j’apprécie… mais la ligne éditoriale, c’est mon boulot pro depuis 20 ans, aussi, quand j’interviens, je suis assez certain d’améliorer les choses. Après on peut toujours arranger les choses autrement, voire améliorer encore ! Et de toute façon je ne suis pas propriétaire de la doc. Mais souvent il est difficile de me replonger dans un texte et de comprendre ce que tu demandes dans ton forum, et parfois quand je comprend ça me semble arbitraire et non justifié. Ce serait plus simple que tu corriges directement Tu aurais directement ce que tu veux, à chaud, tu n’y passerais pas plus de temps, et je suis également assez certain que j’apprécierai souvent le résultat !
Pour le reste, je suis désolé de voir que c’est comme si ma réponse détaillée précédente n’a pas été lue : il semble n’en rien rester.
La qualité de la collaboration est ce qu’elle est, et j’en suis frustré et déçu.
Mais ce n’est pas en supprimant un endroit de collaboration qu’elle s’améliorera.
En effet, le rubricage présent n’est pas adapté, mais il n’y a pas besoin d’être happy few pour se servir de la recherche.
Ah ?
Il faut se sortir les doigts de la généralité abstraite pour avancer.
Tu le sais pour le code, c’est pareil pour la doc !
Alors à quels articles penses tu précisément ?
C’est à dire « yakafaukon » ?
Comme ailleurs ça marche pas ici, sur des trucs complexes en tout cas comme je l’ai expliqué dans un autre point : « face à mon absence d’expérience d’un plugin ou d’une situation de codage » (et face à l’insuffisance de la documentation, dernière situation encore douloureuse : le plugin ticket) « je dois découvrir par essais et erreur, par exploration du code, et peu à peu ainsi je découvre des trucs utiles que je veux pouvoir ultérieurement retrouver sans devoir repasser par le même processus d’exploration, et que je veux par la même occasion partager… mais qui sont partiels et parfois incertains, et donc que je ne peux pas exposer avec l’altitude souhaitable pour prétendre être une vraie documentation »
Peux tu prendre cela en compte avant de répondre ?
Bon alors comment on fait ?
Ça semble la vraie question.
Faut il lancer des appels ?
Situation exemple réelle
Là par exemple je voudrais utiliser le plugin ticket. Je vois que ça marche pas clé en main dans ma situation. J’ai commencé à explorer la config et le code. Je vois que c’est assez complexe et qu’il y a plein de constantes non documentées qui complètent le form de config.
- Je peux facilement créer une page sur le wiki, ne serait-ce que pour lister les constantes non documentées et peu à peu documenter ce que je découvre et comprend. Mais je ne testerai pas toutes les situations et je n’aurai jamais l’évidence du fonctionnement que le codeur a ou avait quand il a codé (parce que ça prendrait trop de temps, je mettrais moins de temps à coder un plugin qui me va parfaitement from scratch). Je n’aurai donc jamais l’altitude pour produire quelque chose de publiable, ou alors sur quelque chose de très limité : par exemple l’existence de ces constantes de config et leurs noms.
- Alors qu’est ce qu’on fait ensuite pour que « ça » collabore sur cette doc ?
C’est malheureusement vrai, les cas d’enrichissement d’une doc ébauchée dans le Carnet sont très rares.
Ce n’est pas une raison pour critiquer cette démarche et cette manière de faire en l’état et avec ce qu’il y a.
Mais c’est une raison pour poser la question : comment améliorer ça ?
?? Si c’était le cas, il n’y aurait qu’à rendre le carnet public comme la partie principale.
Bien sûr ça serait plus simple aussi pour moi, ça me demanderait bien moins de temps de faire que d’expliquer pourquoi je fais. Mais amha cela ne va pas dans le sens de l’échange et du partage d’une « manière d’écrire les choses ».
Encore désolé si ça te lourde, et si tu préfères que j’amende direct sans discussion, dis le moi, ça nous fera du bien à tous les deux
Oui je préfère. C’est exactement ce que j’ai voulu dire.
C’est chiant de commencer un post par cette phrase ça crispe dès le début. Le rôle de Calimero c’est rigolo une fois, pénible à la longue surtout quand c’est totalement faux.
Personne n’est contre le carnet mais beaucoup sont pour une utilisation intelligible dudit carnet.
Oui et non. Comme je l’ai personne ne veut sa disparition mais on est plusieurs à penser que ce ne peut pas être un espace de documentation « finalisée » car par nature il n’est pas perçu ainsi.
Donc je propose de l’utiliser pour collaborer mais avec l’idée de transférer la documentation finalisée dans une rubrique adéquate de Contrib. J’avais prévu d’ailleurs des workflows pour le faire simplement.
Donc on ne fait rien pour l’améliorer ?
Je pense que c’est surtout le cas car aucune réflexion n’a eu lieu sur son objectif et c’est ce qu’on essaye de lancer dans ce chantier. Un fois défini, je pense que le rubricage sera facile.
Alors là mauvaise attaque ou bad move comme on dit dans le bouchonnois (et je reste poli).
En fait, j’ai passé des mois en 2019/2020 à revoir toutes les rubriques de plugins et je suis allé déterré des plugins finis dans le Carnet. Alors m’accuser de ne pas mettre les doigts ça me fait bien rire ou pleurer !
Et j’ai aussi extrait des articles du secteur « A trier » qui est encore une mine à gratter.
Et toi, combien d’articles du Carnet as-tu finalisé et transférer dans une rubrique de Contrib ?
Non parce que je pense qu’on a toujours les moyens de faire une doc finie même imparfaite qui une fois visible sera corrigée si besoin.
Donc non, je pense que tu parles de toi uniquement.
Il existe une rubrique du plugin ici : SPIP-Contrib avec un article de doc qui date et un autre article au statut prepa qui date aussi.
Pour moi, le mieux serait de créer un article de type conception et d’élaborer ce que tu veux dedans.
Si pour ça tu as besoin d’échanger dans le carnet pourquoi pas mais in fine la place de l’article est là où je te le dis.
Après, le carnet n’est pas la solution de collaboration : tu peux aussi voir avec ceux qui maintiennent le plugin si une aide est possible. Pourquoi se prendre plus la tête ?
On a une réflexion justement sur comment intégrer dans Contrib des articles transverses finis qui n’ont aucune vocation à être dans le carnet. C’est un vrai sujet où les idées sont les bienvenues : Arborescence des plugins sur contrib : regroupement ou pas regroupement - #12 par eric_tonton
Alors j’avais un doute, je me disais que peut-être quelqu’un voudrait repartir dessus, c’est pour a que j’avais proposé de le transférer dans le wiki, mais si on pense que c’est vraiment archi obsolète alors je crois qu’on peut le mettre à la poubelle complètement. Ce sera peut-être utile pour d’autres, mais pour ce type d’articles je ne vois pas l’intérêt de le conserver en archive dans le privé.
Le thème « installation de SPIP en local » est aussi un peu piège parce que l’install de SPIP évolue (et devrait encore évoluer avec la 5.0). Sur spip.net il y a cet article Utiliser SPIP « en local » - SPIP qui me semble incomplet, mais est-ce vraiment sa place sur spip.net ? (comme utiliser GIT etc…)
Désolé si je diverge trop du sujet initial.
Ce genre de contenu (comment héberger SPIP, que ce soit en local, ou chez un hébergeur) est par nature casse gueule : SPIP évolue, ses techniques d’installation et ses prérequis changent (Git, composer…), les environnements changent aussi, les hébergeurs encore plus (les offres techniques, les tarifs etc, cf Free ou Gandi au hasard)
Donc pour moi, soit il y a une équipe dédiée et motivée qui s’en occupe vraiment, qui connaît vraiment les différents environnements (MacOs, Windows, Linux, BSD etc…), qui teste, qui met à jour la doc régulièrement, soit on s’abstient, on évite d’y perdre du temps et on se consacre à autre chose.
je suis tout à fait d’accord : de meme que pour le code on essaie de s’appuyer sur ce qui existe, pour les hebergeurs on s’appuie sur ce qui existe : une doc general disant les prerequis et les processus d’installation, et ensuite charge à chaque personne de voir le jour où elle veut installer SPIP si les hebergeurs répondent à cela ou pas.
Ce qui n’empêche pas de créer des pages « vivantes » sur le carnet1, pour partager collectivement des retours d’expérience.
1 : histoire de remettre une thune dans le bastringue