Proposition d'un dépôt documentation

Équipes documentation
#1

Bonjour à tous et toutes,

Suite à ma proposition de contributions à la documentation et à son avancement, aux sujets que cela soulève (voir ici et ici) et aux avis de @nicod, @rastapopoulos, etc :
Je vous propose la création d’un dépôt, dans la forge git, dédié à la documentation. Cela nous permettrait :

  1. De lister et discuter de l’évolution des pages de documentations (Et du coup cela permettra de signaler des pages obsolètes, même si sur le moment, je/tu/nous, n’avons pas le temps de corriger ou écrire).
  2. De facilité de potentielles contributions avec une liste des besoins publiquement disponible.

Il faut peut-être travailler à un modèle de template pour qu’un⋅e contributeur⋅ice lambda sache ce qu’il y a besoin de faire. Qu’en dite vous l’équipe @documentation ?

#2

Ça me semble une bonne idée, même si on a déjà la possibilité de le faire ici sur le forum, mais ça n’est pas du tout le même outil. À voir ce qu’en pensent les autres membres de l’équipe.

#3

Je me demande à quel point ça peut disperser les manières de suivre le travail de documentation. Il faudrait réfléchir à quel endroit est le « centre » de tout ça, sachant qu’on ne pourra jamais supprimer tous les éparpillements.

En effet, il y a :

  • déjà la doc de chaque plugin sur Contrib avec un forum interne privé qui permet de commenter et proposer des changements dedans (notifiées alors aux auteurices et aux admins)

  • de même sur spip.net où chaque article a un forum interne

  • de même sur programmer.spip où chaque article a un forum interne + en plus un système de tickets internes (pas vraiment utilisés ni maintenus : ça pourrait peut-être virer pour moins éparpiller)

  • déjà un projet de la forge par plugin (dist ou pas) + core, avec un système de tickets où on peut parfaitement faire des tickets tagués « documentation » : ce qui est déjà fait pour le core et les plugins-dist (mais pourrait parfaitement s’ajouter sur chaque plugin)

  • le nouveau groupe dédié à la Documentation dans le forum Discuter, où on peut déjà centraliser et classer (et épingler, et mettre en résolu)

Alors si en plus on crée un projet dédié « Documentation » sur la forge avec ses propres tickets aussi… Ça commence à faire beaucoup en tout non ?

Je ne dis pas qu’il ne faut pas, mais faut réfléchir à c’est quoi la priorité, le suivi central, plutôt la forge, plutôt Discuter, plutôt dans chaque projet ou plutôt dans un unique endroit central ? etc ya plein de manières possibles

Exemple de suivi possible déjà existant quand on pense à bien taguer « documentation » (et ce quelque soit le projet) : Connexion · GitLab

–
RastaPopoulos

#4

Je plussoie l’anti-dispersement, je cherche surtout où et comment centraliser, recenser les besoins.

En ce qui concerne les forums internes, je suis un peu envieux de leurs utilisations (même si je comprends l’usage historique) car ils ne sont pas publics, ne donnent pas à voir/constater les contributions réalisées. Du coup, les forums ne permettent que les contributions de personnes disposant d’un accès, cela représente beaucoup de barrières à la contribution.

J’avais peu trainé dans SPIP, mais plutôt dans les extensions. Et je n’avais pas fait attention à l’utilisation des étiquettes/tags. Ça me semble être une bonne solution sans rajouter d’outils, de dépôt ou de lieux de dispersement. Cela est-il compliqué à mettre en place ?

plugin Menus - evolution du contenu
#5

Dans une réflexion un peu plus large j’avais cette question qui trainait de mes contributions (qui n’est d’ailleurs pas rédigé comme une question…)

#6

On peut avoir des labels globaux pour le groupe git spip-contrib-extensions, oui.

a priori, ces 5 là pourraient suffire dans un premier temps :

  • amélioration
  • bug
  • sécurité
  • documentation
  • question

C’est commun avec spip/* et ce serait extensible dans le temps …

Je fais ça pour que vous puissiez tester.

par exemple : Rapatrier les css de l'édition de traitement dans le core de SPIP (#214) · Tickets · spip-contrib-extensions / formidable · GitLab j’ai ajouté arbitrairement documentation dessus

Si ça vous plaît, il n’y aura qu’à retirer les label de dépôts en doublons,
Si ça vous plaît pas, j’enlève les globaux.

à vous de décider :wink:

1 « J'aime »
#7

Est-ce que l’on a moyen ensuite de voir tous les tickets porteur du label « Documentation » de tous les dépôts de spip-contrib-extensions ? J’ai testé via la recherche globale et mes essais ne semblent pas concluants…

#8

Oui, en filtrant : Tickets · spip-contrib-extensions · GitLab

#9

Merci pour l’astuce, je n’arrivais pas à trouver la fonction recherche sur le groupe =)

#10

Si vous n’êtes pas membre du groupe spip-contrib-extensions : spip-contrib-extensions · GitLab

en haut à droite, on peut demander l’accès :

Screenshot 2024-04-25 at 10.07.18
Screenshot 2024-04-25 at 10.07.18998×328 18.5 KB

Un admin passera et aceptera … ou pas :wink:

#11

J’ai donné ce lien plus haut, qui est même sur tous les dépôts totaux, pas juste les plugins, donc pour la doc du core et plugins-dist aussi : Connexion · GitLab

#12

Petites stats :

  • Il y a 941 projets dans le groupe spip-contrib-extensions contenant le fichier paquet.xml à la racine de leur branche par défaut.
  • Il y a 51 de ces projets qui ont leur propre jeu de labels:

Ci dessous le nombre de fois où on rencontre un jeu de labels dans ces 51 projets:

   1 [{"name":"Bug"},{"name":"Documentation"},{"name":"Ergonomie"},{"name":"Évolution"}]
   1 [{"name":"UX"},{"name":"amélioration"},{"name":"bug"},{"name":"doublon"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refusé"}]
   1 [{"name":"amélioration"},{"name":"bug"},{"name":"documentation"},{"name":"doublon"},{"name":"good first issue"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refusé"}]
   1 [{"name":"amélioration"},{"name":"bug"},{"name":"documentation"},{"name":"doublon"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refusé"}]
   7 [{"name":"amélioration"},{"name":"bug"},{"name":"documentation"},{"name":"doublon"},{"name":"invalide"},{"name":"refusé"}]
   1 [{"name":"amélioration"},{"name":"bug"},{"name":"doublon"},{"name":"good first issue"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refusé"}]
  19 [{"name":"amélioration"},{"name":"bug"},{"name":"doublon"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refusé"}]
   1 [{"name":"amélioration"},{"name":"bug"}]
   1 [{"name":"amlioration"},{"name":"bug"},{"name":"doublon"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"refus"}]
   1 [{"name":"amlioration"},{"name":"bug"},{"name":"doublon"},{"name":"help wanted"},{"name":"invalide"},{"name":"question"},{"name":"wontfix"}]
  16 [{"name":"bug"},{"name":"duplicate"},{"name":"enhancement"},{"name":"help wanted"},{"name":"invalid"},{"name":"question"},{"name":"wontfix"}]
   1 [{"name":"bug"}]

J’ai l’impression que @Plumf a déjà adopté la solution des labels globaux… :slight_smile:

J’ai une moulinette qui peut remplacer les labels de projet par le label global homonyme.
C’est quand vous voulez :wink:

1 « J'aime »
labels de groupe pour `spip/*`
Fluidifier la création de releases
#13

I am pour !

#14

Me too !

#15

+1

#16

Merci @JamesRezo, désolé @rastapopoulos !

Et oui, je suis bien partisan de la proposition, merci pour tout !

#17

C’est fait.

Pour info, il reste des labels associés à quelques projets :

   1 Bug
   1 Documentation
   1 Ergonomie
   1 Évolution
   1 UX
  32 doublon
  16 duplicate
  16 enhancement
   2 good first issue
  41 help wanted
  16 invalid
  32 invalide
   1 refus
  30 refusé
  17 wontfix

Je vous laisse regarder ça entre vous :wink:

#18

Merci @JamesRezo, je vais jeter un coup d’oeil (de haut). Je n’ai pas de bouton/fonction disponible pour marquer ce poste comme résolue/fermé (si c’est nécessaire).

#19

je regarde ça …

#20

@Plumf dis-moi si quelque chose à changé pour toi ? vois-tu plus de boutons ?