doc.spip : quel domaine, et contenu

Je vais répondre à quelques points donc.

Origine

Alors déjà cela fait suite à la discussion Doc migration 5.x et dépot spip/spip et notamment Doc migration 5.x et dépot spip/spip - #20 par marcimat : on a créé 2 domaines

L’objectif était double :

  • permettre d’avoir des Pages gitlab (et donc des sites statiques) à partir de doc en markdown dans un dépôt (et toujours à jour avec le dépôt) aux urls pages.spip.net/{org}/{depot} donc.
  • sur SPIP, migrer et scinder la doc d’Upgrade qui devenait impossible à gérer.

sur le nom doc.spip.net

Je ne suis pas figé sur doc.spip.net mais cela dit, au vu de la qualité de zensical utilisé derrière et de sa recherche, je pense qu’on peut y mettre un peu plus que de la doc de migration.

En tout cas je souhaite absolument conserver le fait que c’est le dépôt qui contient sa documentation technique : c’est vraiment beaucoup plus facile à gérer que de devoir aller éditer un site éditorial SPIP en préparant et modifiant des articles non publiés. Par ailleurs peu de monde maintient la doc publique des plugins à jour sur Contrib lorsqu’un plugin évolue par exemple.

D’autant plus qu’on (nous en développant) peut chercher directement dans notre IDE ce qui est déjà documenté ou pas, et aussi demander aux agents IA qu’on utilise de synchroniser les modifications apportées en même temps : c’est un gain en temps considérable qui nous permet de nous concentrer sur les problèmes techniques à résoudre avant tout, et sans omettre la doc.

Il faudra de vrais articles sur spip.net évidemment au moment de la release, mais ils pourront être des résumés ou détailler des points différents, mettre des illustrations images (dans la doc markdown, il y a des graphiques en mermaid, ce qui me semble bien suffisant déjà). Éventuellement faire des liens vers la doc statique.

sur les docs programmer.spip.net vs spip.net

Je suis très partagé sur ces documentations et sur où quoi devrait aller : ce que je sais c’est que je n’ai absolument plus d’énergie, volonté à y consacrer : je trouve cela trop lourd de préparer des articles sur un nouveau site programmer5 (mais je ne suis pas contre faire cette copie du site sur demande de qqn au besoin), de gérer des migrations d’articles de spip.net dedans ou autre : je préfères consacrer du temps à autre chose pour SPIP 5 sur le code, ce qui est déjà très énergivore (sans compter la maintenance de la 4.4 et ses releases).

Je présume que depuis toutes ces années, si des personnes avaient eu l’énergie, le temps et beaucoup de volonté pour créér des différents sites qui avaient été imaginés un jour pour découper spip.net (integrer.spip.net notamment de mémoire), cela aurait été fait. Comme beaucoup de chose, ce n’est pas aussi simple que de simplement le dire : c’est aussi un gros chantier avec toute l’histoire de spip.net que de s’occuper de ça, et c’est compréhensible que ça soit resté en status-quo.

La relation avec ce doc.spip.net (on a eu quelques difficultés à se mettre d’accord sur un nom — note que ça existait déjà et était redirigé avant sur https://code.spip.net/ — site qui pour le coup je trouve n’a guère d’intérêt) complexifie peut être encore, mais je ne serais pas choqué si une partie de Programmer entrait dedans : notamment je pense qu’il est sain d’y avoir associé un début de doc sur la nouvelle architecture et de continuer à faire évoluer cela. J’aimerais bien que ce doc.spip.net soit une sorte de référence relativement 1:1 avec le code, sur des sujets techniques effectivement, sans pour autant que ça soit le seul site ; il me semble qu’il y a de la place pour d’autres styles d’écriture (les articles de présentation de versions sur spip.net notamment)

Dans certains sites de doc, tu as une souvent des parties Recettes de cuisines, ou Études de cas qui montrent des développement plus complets, exemples de A à Z, qui seraient possiblement pertinent d’avoir, et qui a priori ne seraient pas sur ce doc.spip.net, plus éditorialisés, plus descriptifs : c’est aussi des choses qui pourraient être intéressantes d’avoir.

Bref le sujet est vaste effectivement.