Refonte de Contrib - Chantier - Nettoyage et revue du secteur Vie de SPIP et autour de SPIP

Équipes documentation
41

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

42

Totalement obsolète aussi, à ne pas garder (des articles de 10, 15 ou 20 ans).

43

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.

44

Ç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 »
45

+1, le carnet n’est pas une poubelle, merci pour lui.

46

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.

48

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 :slight_smile:

49

Oui je préfère. C’est exactement ce que j’ai voulu dire.

50

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

51

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.

52

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.

53

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.

54

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