[spip-dev] Documenta(c)tion

Bonjour,

Une enquête interne (officieuse, mensongère et irréelle) de la DGSE (Direction Générale des Spipeurs Étourdis signale, dans son rapport «d0cAFer2.0», à propos de la documentation relative à SPIP que :
- certains utilisateurs la trouvent bien,
- d'autres la trouvent,
- d'autres encore ne la trouveront jamais !

et que les réponses apportées à ces derniers sont :
- la documentation est là,
- la documentation est là... en partie,
- la documentation est en partie là,
- la documentation est partie là-bas (et repassera par ici),
- cette partie-là de la documentation est là-bas (mais l'autre est ici),
- on est las de dire que la doc est là.

Bref, il plane un doute dans la salle.

Las de tout ça, de ces rigolos rongeurs à dents de lait, persiffleurs rigolards à pas d'heure, qui aiment postillonner sur la doc, je leur pose une question (valable pour tous les autres aussi !) :

* «S'il existait une documentation complète et idéale traitant du _développement_ avec SPIP (2.0), quelle serait sa table des matières ?» *

_Retour des copies au plus tard dans 7 jours._

Notes:
1) La question attend réellement des réponses
2) Toute tentative de concertation sera bienvenue !
3) Cette question n'est pas anodine, n'hésitez pas à y contribuer,
4) Bien qu'il soit écrit "dans 7 jours", vous pouvez répondre maintenant !
5) Si si ! Maintenant !!!

En attendant vos précieuses réponses,
Bon SPIP à tous !

Matthieu Marcillaud a écrit :

* «S'il existait une documentation complète et idéale traitant du _développement_ avec SPIP (2.0), quelle serait sa table des matières ?» *

Preums !

- Documentation du code
   Dans cette rubrique il s'agit de décrire le plus précisément possible des points précis du code, en décrivant tous les arguments et utilisation de ces points.
   - Les fonctions (automatiquement parsées comme actuellement)
     TOUTES les fonctions de SPIP (c'est déjà le cas mis à part un bug)
   - Les pipelines (automatiquement parsés dans inc_version.php)
     TOUS les pipelines + récup des commentaires comme pour les fonctions

- Programmer avec SPIP
   Dans cette rubrique, il n'y a pas lieu de distinguer si on programme dans un plugin, ou dans un squelette ou autre. Donc la sous-rubrique "Les plugins" n'a aucun intérêt. En effet, on peut avoir besoin des pipelines aussi bien dans un plugin que dans son mes_options.php pour un site précis. Pareil pour le multilinguisme, pareil pour l'ajout d'une tâche au génie, pareil pour la structure des dossiers du PATH, etc. Ainsi le seul article actuel traitant explicitement des plugins c'est l'explication du "plugin.xml". On ne va pas créer une sous-rubrique pour un seul article, ou même pour deux ou trois seulement. Il faut aussi enlever le bazar venant de "sprint de doc", etc. Voici donc, non-exhaustivement, les *articles* de cette rubrique (avec des vraies propositions de titres), on pourra toujours faire une arborescence lorsque ça se remplira vraiment trop :

   - La structure des dossiers
     Explication des dossiers possibles : formulaires, balises, fonds...
   - La base de données
     Explication technique générale puis liste vers les articles précis
   - Les points d'entrée (pipelines)
     Explication générale sur comment en ajouter puis liste pareille
   - Déclarer un plugin (plugin.xml)
     Détail de chaque balise XML (et uniquement ça)
   - Créer une procédure d'installation d'un plugin
     Explication de prefixe_update() et prefixe_vider_tables()
   - Déclarer et ajouter de nouvelles tables
     Explication pas-à-pas mais pas besoin de trop de détails car ils seront écrits dans la doc précise des 3 pipelines adéquats (declarer_...). Il faut chasser les doublons. Cet article très demandé (et que crovvfoot a presque tout fait) décrira donc dans l'ordre la procédure mais en renvoyant des liens vers la doc du code (cf secteur précédent).
   - Les chaînes de langues
     Explication sur les fichiers à ajouter et sur _T(), etc
   - Ajouter une tâche au génie
     Actualisation de l'article actuel sur le cron
   - Modifier les URLs
     En vrac : s'insérer par pipeline dans les jeux d'URLs existants, fabriquer son propre jeu d'URLs, ajouter des URLs persos pour de nouveaux objets, etc
   - .....

Désormais, avec les nouvelles manières de programmer, quasiment tous ces articles vont faire appels à des pipelines. Puisque les pipelines ne sont pas l'apanage des plugins (cf les demandes régulière pour les URLs) il ne faudra donc pas donner à chaque fois un exemple de déclaration dans le XML, mais plutôt renvoyer un lien vers l'article "Les points d'entrée" et même vers un intertitre de celui-ci qui serait "Déclarer un pipeline".

Voilà, avec tout ça on a déjà une arborescence *plus simple* et pourtant plus complète.

Merci Mathieu et Rastapopoulos, ce sujet m’interpelle (ferais-je partie de la DGSE sans le savoir ? ^^ ).

Je commence à aborder le dev autour de spip, et c’est vrai que ce n’est pas toujours facile de s’y retrouver. Bon, bien suûr, je ne parle que pour moi, et je suis un peu nul en plus.

Ce que j’ai du mal à appréhender c’est la globalité du fonctionnement de spip (ça commence à venir, mais cela n’a pas été sans douleur). D’ailleurs les dernier articles de marcimat sont vraiement très bien, la « big picture » de spip est plus claire dans ma tête depuis.

Pour compléter de quelques postillons la réponse de Rastapopoulos,

  • Programmer avec SPIP
    Dans cette rubrique, il n’y a pas lieu de distinguer si on programme dans un plugin, ou dans un squelette ou autre.

Je suis ok là dessus, mais justement il faut aussi des articles (pas forcement dans la « doc » officielle hein) qui permettent à la personne qui a une idée de fonctionnalité à ajouter à SPIP (et/ou à son SPIP), de savoir par où commencer, par quel bout prendre la bête.
Dans quel cas il faut faire un plugin, dans quel cas utiliser mes_options.php. Un genre de « guide du programmeur spip débutant » croisé avec « les bonnes pratiques du dev spip ».

Bref, penser à des « trucs » pour éviter le choc frontal entre une grosse doc exhaustive (de référence, nécessaire) et le petit spipeur qui veut s’y mettre dans son coin. Je pourrais éventuellement faire du tuto (lorsque j’aurais progressé).

A bientôt.

Augustin

Gus ashaszin a écrit :

Merci Mathieu et Rastapopoulos, ce sujet m'interpelle (ferais-je partie de la DGSE sans le savoir ? ^^ ).

mes_options.php. Un genre de "guide du programmeur spip débutant" croisé avec "les bonnes pratiques du dev spip".

Oui, débutant ou non d'ailleurs...

Pour dire quelques fonds de ma pensée...

Je suis à un point où je ne sais tellement plus où mettre la documentation que je préfère faire des billets sur mon site.

* SPIP.net se veut (si je comprends bien) pour les utilisateurs et pour les intégrateurs. Il remplit à mon sens bien ce rôle.

* Contrib reçoit les documentations des contributions, et remplit très bien ce rôle.

* Doc.spip documente les *fonctions php* de SPIP et rempli très bien ce rôle (encore que le script est cassé depuis quelques temps)

Il reste la documentation technique sur le fonctionnement, l'extension, la vision globale de SPIP qui me semble très ambigue. On en trouve des bouts sur spip.net, contrib, le carnet, doc.spip et divers trucs sur certains blogs.

C'est sur ce point précis que je m'intéresse, au point que je me dis qu'un autre site serait peut être intéressant. Je m'explique avant de recevoir les foules braquées...

Je préfère qu'on identifie un site à une seule chose claire et précise, même s'il y a beaucoup de sites, chaque site de la galaxie rempli un rôle assez clair.

Il n'y a pour ma part que doc.spip qui me gène... à moitié. Je pensais qu'il se cantonnerait à expliciter les fonctions de SPIP, son code, et simplement cela. Il tend à recevoir aussi en ce moment des compléments de documentations, c'est tout à son honneur, mais je ne suis pas certain que ça soit le bon lieu.

Pour ma part, j'imaginerais bien un nouveau site (ou un espace identifié sur doc.spip) pour reçevoir de la documentation technique sur le fonctionnement de SPIP, son arborescence, le développement de squelettes et de plugins, comment l'étendre, documenter les fonctions importantes, donner des exemples. Et j'imaginerais bien, même, un site fait un peu comme un livre, que l'on feuillette en tournant les pages... Avoir donc une bonne structure, table des matières pour que l'on puisse apprendre SPIP en lisant ce livre, qui serait comme une courbe d'apprentissage. Dans ma grande imagination, tous les contenus fournis seraient en licence cc-by-sa permettant la création automatique d'un pdf redistribuable (on peut rêver hein ?!)... Enfin, je n'imaginais pas quelque chose d'exhaustif, mais plutot quelque chose de complet, faisant le tour d'un état de SPIP à un moment donné (2.0).

Par exemple, plutôt s'attarder à décrire ce qu'est un pipeline, comment ils fonctionnent, montrer comment en utiliser certains, comment en créer de nouveaux, mais pas forcément décrire exhaustivement (avec leurs paramètres je veux dire) et précisément tous les pipes existants dans SPIP , ce qui pourrait devenir rasoir...

Le plus dur dans cette histoire, c'est de trouver une table des matières correcte et assez précise. La remplir ne sera pas le plus difficile.

Tu viens pas de la donner ?

Il s'agit bien de développer des thématiques à partir d'exemple de fonctionnement exhaustif en profondeur mais pas forcément en largeur.
C'est pour moi une bonne façon de "rentrer" dans la logique de spip et, à terme, d'élargir la base de ceux qui contribuent aux dev de spip.

Vraiment je trouve ton idée et la façon de la présenter excellente. Le problème du sommaire en est-il vraiment un ?
Il me semble qu'il suffit de trouver deux ou trois thèmes pour commencer; comme disent certains "c'est en marchant qu'on fait la route"...

Marchons :slight_smile:

Matthieu Marcillaud a écrit :>

Pour ma part, j'imaginerais bien un nouveau site (ou un espace identifié sur doc.spip) pour reçevoir de la documentation technique sur le fonctionnement de SPIP, son arborescence, le développement de squelettes et de plugins, comment l'étendre, documenter les fonctions importantes, donner des exemples.

Bah ça c'est bon, c'est la partie "Documentation générale" (espace identifié) sur doc.spip.org. Qui est bien séparé de la partie technique et *exhaustive* nommée "Documentation du code".

Et j'imaginerais bien, même, un site fait un peu comme un livre, que l'on feuillette en tournant les pages... Avoir donc une bonne structure, table des matières pour que l'on puisse apprendre SPIP en lisant ce livre, qui serait comme une courbe d'apprentissage.

Il suffit alors de mettre des numéros aux rubriques et articles, puis {par num titre}+supprimer_numero() et hop on aura un ordre de lecture. Et quand on aura le temps on pourra alors faire un squelette dédié pour présenter ça comme tu le souhaites.

Dans ma grande imagination, tous les contenus fournis seraient en licence cc-by-sa permettant la création automatique d'un pdf redistribuable (on peut rêver hein ?!)... Enfin, je n'imaginais pas quelque chose d'exhaustif, mais plutot quelque chose de complet, faisant le tour d'un état de SPIP à un moment donné (2.0).

Par exemple, plutôt s'attarder à décrire ce qu'est un pipeline, comment ils fonctionnent, montrer comment en utiliser certains, comment en créer de nouveaux, mais pas forcément décrire exhaustivement (avec leurs paramètres je veux dire) et précisément tous les pipes existants dans SPIP , ce qui pourrait devenir rasoir...

Exactement. Regarde ma proposition précédente, c'est ce que je préconisais : dans la partie "Documentation du code" il y aurait une rubrique listant automatiquement TOUS les pipelines, en parsant "inc_version.php" et avec récupération des commentaires éventuels comme pour les fonctions PLUS doc wiki, toujours comme pour les fonctions. Vraiment exactement le même fonctionnement quoi, mais en parsant inc_version.

Et ensuite, à part, il y aurait la partie "Documentation générale", dans laquelle il y aura un ou des articles sur les pipelines, expliqués de manière pédagogique. Et c'est ce que fais l'article "Les points d'entrées" lorsqu'on lui enlève la liste rébarbative qu'il y a à la fin (et qui sera forcément enlevé une fois qu'on aura parsé inc_version).

Le plus dur dans cette histoire, c'est de trouver une table des matières correcte et assez précise. La remplir ne sera pas le plus difficile.

Hier j'ai aussi fait quelques propositions d'articles, de titre précis pour ces articles, et ensuite il faut leur donner un ordre.
Comme je l'ai déjà dit, à mon humble avis, il faut déjà que tous ces articles de base soient là, il n'y en a pas tant que ça. Dès que ça va se remplir un peu plus, il n'y aura plus qu'à classer en sous-rubrique plus précises.

Hier (avant même de lire ton mail !) j'ai commencé à ré-organiser et à faire le ménage dans les vieux trucs obsolètes :
- les articles avec presque rien dedans et/ou dont le contenu n'est plus d'actualité, je les ai viré complètement.
- les articles un peu gros où je me suis dit qu'on pouvait récupérer des morceaux, je les ai mis "en rédaction" ou "proposé à l'évaluation" pour ne plus les afficher sur le site.

J'ai ensuite réorganiser en deux grands axes :
- Comprendre SPIP
- Programmer avec SPIP

Pour l'instant il n'y a pas trop d'articles dans chacune, donc ça va. Lorsque ça va se remplir (essentiellement dans la partie "programmer"), il faudra alors classer en sous-rubriques :
- Créer un plugin
   - Déclarer son plugin
   - La structure des répertoires
   - etc
- Utiliser les pipelines
   - Les points d'entrées (pipelines)
     Présentation générale
   - Exemple du pipeline machin_truc
   - Créer un nouveau pipeline
   - etc

Et tout le monde il est content !
SPIP-Bisous !

Pierre Fiches a écrit :

Je préfère qu'on identifie un site à une seule chose claire et précise, même s'il y a beaucoup de sites, chaque site de la galaxie rempli un rôle assez clair.

Il n'y a pour ma part que doc.spip qui me gène... à moitié. Je pensais qu'il se cantonnerait à expliciter les fonctions de SPIP, son code, et simplement cela. Il tend à recevoir aussi en ce moment des compléments de documentations, c'est tout à son honneur, mais je ne suis pas certain que ça soit le bon lieu.

Pour ma part, j'imaginerais bien un nouveau site (ou un espace identifié sur doc.spip) pour reçevoir de la documentation technique sur le fonctionnement de SPIP, son arborescence, le développement de squelettes et de plugins, comment l'étendre, documenter les fonctions importantes, donner des exemples. Et j'imaginerais bien, même, un site fait un peu comme un livre, que l'on feuillette en tournant les pages... Avoir donc une bonne structure, table des matières pour que l'on puisse apprendre SPIP en lisant ce livre, qui serait comme une courbe d'apprentissage. Dans ma grande imagination, tous les contenus fournis seraient en licence cc-by-sa permettant la création automatique d'un pdf redistribuable (on peut rêver hein ?!)... Enfin, je n'imaginais pas quelque chose d'exhaustif, mais plutot quelque chose de complet, faisant le tour d'un état de SPIP à un moment donné (2.0).

Par exemple, plutôt s'attarder à décrire ce qu'est un pipeline, comment ils fonctionnent, montrer comment en utiliser certains, comment en créer de nouveaux, mais pas forcément décrire exhaustivement (avec leurs paramètres je veux dire) et précisément tous les pipes existants dans SPIP , ce qui pourrait devenir rasoir...

Le plus dur dans cette histoire, c'est de trouver une table des matières correcte et assez précise. La remplir ne sera pas le plus difficile.

Tu viens pas de la donner ?

Il s'agit bien de développer des thématiques à partir d'exemple de fonctionnement exhaustif en profondeur mais pas forcément en largeur.
C'est pour moi une bonne façon de "rentrer" dans la logique de spip et, à terme, d'élargir la base de ceux qui contribuent aux dev de spip.

Vraiment je trouve ton idée et la façon de la présenter excellente. Le problème du sommaire en est-il vraiment un ?
Il me semble qu'il suffit de trouver deux ou trois thèmes pour commencer; comme disent certains "c'est en marchant qu'on fait la route"...

Marchons :slight_smile:

Oui mais a marcher tête baissée ... on finira par rencontrer un mur ... et ca fait mal .
Je trouve la démarche de Mathieu TRES intéressante et constructive.

Un point sur lequel je ne te rejoins pas c'est créer un nouveau site ... Il vaut mieux a mon avis créer un espace dans doc.spip .
trop de sites tue les sites. Enfin moi je ne sais plus ou chercher a force :slight_smile: a tel point que google est ma porte d'entrée de recherche de doc et a mon avis je ne suis pas le seul. ( et j'en convient ce n'est pas la bonne démarche )

Cette idée de la table des matières est indispensable.

je reprends la tienne et j'ajoute quelques points:

J'ai ensuite réorganiser en deux grands axes :
- Comprendre SPIP
- Programmer avec SPIP

Je ne découperai pas de la sorte.

Plutôt un découpage par concept et un sous découpage en comprendre puis programmer ...
C'est amha un meilleur découpage dans l'utilisation d'un concept.

Viva cette démarche volontariste, Marcimat !

Un espace dédié sur doc.spip.org est préférable à mon sens à un nouveau site.

La doc "livre" projettée et la doc "fonction par fonction"
étant 2 faces d'une même référence.
Oui, la doc livre mérite bien
tous les développements spécifiques que tu envisages.

J'ajouterai pour la TOC :

Yoann Nogues a écrit :

J'ai ensuite réorganiser en deux grands axes :
- Comprendre SPIP
- Programmer avec SPIP

Je ne découperai pas de la sorte.

Effectivement, cette distinction me semble lourde et inadaptée.

Plutôt un découpage par concept

Oui

et un sous découpage en comprendre puis programmer ...
C'est amha un meilleur découpage dans l'utilisation d'un concept.

Ce serait un plus.
Actuellement, dans certains éléments de doc actuelle,
(cf les déclarations de tables etc par exemple)
il manque l'aspect "comprendre".
Dans ces cas, la doc se limite à des recettes
à réciter recopier "comme des ânes du bas clergé" !

Ceci dit, je ne suis pas sur que ces 2 aspects comprendre / coder
doivent induire systématiquement une structuration de la doc,
au niveau de chaque "concept".
Selon les cas, ça peut aussi se faire naturellement au sein d'un même article.

JL

Selon les cas, ça peut aussi se faire naturellement au sein d'un même article.

Tout a fait ca dépends de la somme d'information ...
Mais a mon avis on ne peut pas programmer sans comprendre ... (bien que certains ( qui ne programme pas d'ailleurs ) pensent le contraire : p )

a+

Pardonnez moi, y'a t'il une page de wiki sur spip-contrib ou l'on pourait batir de concert la table des matières ?

BoOz

Yoann Nogues wrote:

BoOz a écrit :

Pardonnez moi, y'a t'il une page de wiki sur spip-contrib ou l'on pourait batir de concert la table des matières ?

BoOz

Non, tu peux en créer une sur contrib.

RastaPopoulos wrote:

BoOz a écrit :

Pardonnez moi, y'a t'il une page de wiki sur spip-contrib ou l'on pourait batir de concert la table des matières ?

Non, tu peux en créer une sur contrib.

Ouais mais je l'appelle comment ?

"PEC des concepts clés pour la maturation induite d'une TOC pour la doc" ?

BoOz

BoOz a écrit :

Ouais mais je l'appelle comment ?

"PEC des concepts clés pour la maturation induite d'une TOC pour la doc" ?

ca me parait assez clair oué :slight_smile:

S'lt

Dans ton grand nettoyage tu as supprimé la page trucs en vrac :frowning:

Elle listait entre autre les api images_*, sql_* et je ne la retrouve pas.

Km

cam.lafit@azerttyu.net a écrit :

S'lt

Dans ton grand nettoyage tu as supprimé la page trucs en vrac :frowning:

Elle listait entre autre les api images_*, sql_* et je ne la retrouve pas.

Normalement elle est juste en "en cours de rédaction" ou en "proposé à la publication". L'un ou l'autre.

Pour les API, c'est juste des modèles prêts à l'emploi, c'est ça qui est pratique. Pour le SQL le modèle est utilisé dans la page "La base de donnée" il me semble. Et pour "image_*" ben il suffit d'utiliser le modèle dans une page de doc sur les images que tu vas créer ! :slight_smile:
Non ?
Héhé.

S'lt

Pour les API, c'est juste des modèles prêts à l'emploi, c'est ça qui est
pratique.

Je sais :stuck_out_tongue:

Pour le SQL le modèle est utilisé dans la page "La base de donnée"
il me semble. Et pour "image_*" ben il suffit d'utiliser le modèle dans une
page de doc sur les images que tu vas créer ! :slight_smile:

Je me dit qu'en fait faudrait faire une rubrique API et un article
par api qui appelle le modele qui va bien.

Non ?

Non ?

Km

cam.lafit@azerttyu.net a écrit :

S'lt

Pour les API, c'est juste des modèles prêts à l'emploi, c'est ça qui est
pratique.

Je sais :stuck_out_tongue:

Pour le SQL le modèle est utilisé dans la page "La base de donnée"
il me semble. Et pour "image_*" ben il suffit d'utiliser le modèle dans une
page de doc sur les images que tu vas créer ! :slight_smile:

Je me dit qu'en fait faudrait faire une rubrique API et un article
par api qui appelle le modele qui va bien.

Non ?

Non ?

Oui.
Dans ce cas, cela s'inscrirait dans le cadre des "chapitres" dont parlait Marcimat.

Par exemple, il y aurait un chapitre "La base de donnée", et à la fin de ce chapitre il y aurait un article "L'API complète de la base de donnée" et hop le modèle.

Pareil pour les images, il y aurait un chapitre consacré aux images dans SPIP et à la fin "L'API complète des images" avec le modèle.

Comme ça dans un chapitre on aurait à la fois les trucs pédagogiques, et à la fin, l'API complète qui est exhaustive et qui renvoie vers la doc complète et elle-même exhaustive de chaque fonction.

Oui.
Dans ce cas, cela s'inscrirait dans le cadre des "chapitres" dont parlait
Marcimat.

Par exemple, il y aurait un chapitre "La base de donnée", et à la fin de ce
chapitre il y aurait un article "L'API complète de la base de donnée" et hop
le modèle.

Je teste pour voir

PS ça serait bien de mettre la plan proposé dans un article dans la
racine de la documentation ? Comme ça on pourra tracer plus simplement
les mises à jours du plan non ?