labels de groupe pour `spip/*`

[JamesRezo]

Situation actuelle des labels pour spip/*

• 41 dépôts git
• 0 labels de groupe.

labels des projets:

   1 APIs
   1 En cours
   1 Inscription
   1 LDAP
   1 PostgreSQL
   1 accessibilité
  33 amélioration
   1 apache-only
   2 authentification
   2 base de données
  36 bug
   1 cache
   1 code généré
   1 compilo
   2 css
   1 dépréciation
   1 distant
   2 divers
  33 documentation
  33 doublon
   3 duplicate
   3 enhancement
   3 ergonomie
   3 espace privé
   2 filtres et balises
   1 formulaires
   5 help wanted
   1 http
   1 installation
   3 invalid
  33 invalide
   1 javascript
   1 langues
   1 plugin
   6 question
  33 refusé
   1 sécurité
   1 sqlite
   1 team-nomenclature
   1 traduction
   3 wontfix

Je propose, pour un premier temps, de passer la liste suivante en labels de groupe, et on verra la suite pour plus tard :

accessibilité
amélioration
bug
documentation
ergonomie
question
sécurité

[b_b]

@JamesRezo

question

Je doute sur « question », ça veut souvent dire que ça n’a rien à faire dans un ticket mais plutôt dans un post sur le forum.

• doublon & duplicate pourraient être supprimé maintenant qu’on pet bien gérer ça sur gitlab.
• divers aussi à supprimer.
• ehancement à fusionner avec amélioration
• help wanted, je doute sur l’utilité

On fait quoi de wontfix, invalide et refusé ?

[JamesRezo]

• wontfix, j’aime bien… mais c’est tout, « j’aime bien »
• invalide/refusé, pour moi, ça sert à rien…
• OK pour doublon, duplicate et divers
• ehancement à fusionner avec amélioration : hi hi … c’est un chouïa plus compliqué mais oui, of course !

question: pour moi, c’est assez pratique d’avoir ça pour les cas où la personne ne sait pas trop ce qu’il en est : est-ce un manque de documentation ? un bug ? un truc qui pourrait améliorer le composant ?.

C’est @tcharlss qui m’a donné l’idée avec 2 de ses tickets : https://git.spip.net/spip/spip/-/issues/5420 et <INCLURE> : parties conditionnelles et application de filtres (#5028) · Tickets · spip / spip · GitLab

à noter que les plugins-dist ne sont pas documentés en-soi ni sur spipnet, ni sur contrib… et donc, pas de forum… y a discourse, certes, mais, bon, voilà, à un niveau « dev » ou « power user », je trouve ça pratique…

EDIT: help wanted: Ailleurs que dans SPIP, je l’ai vu et ça sert aux membres du groupe en charge du projet de dire « Si quelqu’un peut faire, PR bienvenue ! » en gros. Mais bof, je préférerais d’autres méthodes pour les tickets qui n’avancent pas ou plus … (autre sujet…) OK pour le supprimer en ce qui me concerne. Pour info, ce label existe mais n’est pas utilisé …

[nicod]

Ça correspond à quoi le nombre devant chaque label ?

En tout cas, accessibilité et ergonomie me paraissent aussi importants et transversaux que les autres, plus en tout cas que help wanted sur les projets du core.

[JamesRezo]

@nicod

Ça correspond à quoi le nombre devant chaque label ?

le nombre d’occurences du label pour tous projets dans le groupe spip

J’ajoute accessibilité et ergonomie dans la liste des labels susceptibles de devenir communs.

[marcimat (Matthieu Marcillaud)]

Je trouve bien de mettre les labels sur les groupes, de sorte qu’ils soient partagés sur tous les projets de groupes

[nicod]

Je trouve ça très bien aussi, ça évitera la dispersion, et ça permettra de remonter tous les tickets du core + plugins liés à tel sujet par exemple.
Par contre il ne faudrait pas qu’on perde des affectations de tags actuels en les « remontant » au niveau des groupes (orgas en terminologie gitea).
Je ne sais pas s’il y a un truc comme ça prévu dans l’UI Gitlab, sinon ça implique de coder ça sur l’API.

[JamesRezo]

Et c’est ce qui a été fait sur spip-contrib-extensions (cf. Proposition d'un dépôt documentation - #12 par JamesRezo) mais il y a des remplacements à faire (ex: enhancement → amélioration), des suppressions et un cas que je n’avais pas rencontré sur spip-contrib-extensions, à savoir quand il y a plusieurs labels pour une issue, il ne faut pas retirer tous les labels. Bref, ça demande des retouches au script, des tests un peu « virtuel » (parce que je vais pas lancer des curl DELETE ou PUT au pif, …)

Ça demande un peu de temps mais ça vient

[nicod]

Ah voilà, il me semblait bien que tu avais parlé d’une moulinette mais je ne savais plus où.
Merci en tout cas.

[JamesRezo]

Information anecdotique:

À l’instant t:

• Sur la plate-forme gitlab, il y a 1383 projets publics et non-archivés.
• Le label help wanted existe pour 52 de ces projets.
• Ce label n’est associé qu’à une seule issue : sur spip-cli
• Issue à laquelle est aussi associé le label question
• Label qui existe pour 12 projets sur les 1383.

Information peu utile, mais qui confirme que help wanted peut être supprimé, au moins pour spip/*.

[JamesRezo]

Le renommage « enhancement → amélioration » a été effectué.

Pour la suppression des labels, on est, a priori sur la liste :

• divers
• help wanted
• wontfix
• invalid/invalide
• refusé/refus
• doublon/duplicate

La suppression de ces labels ne posera pas de soucis apparent.
Concernant les labels doublon/duplicate, j’ai « linké » la trentaine de tickets « doublons », donc ces labels sont prêts à étre supprimés.

J’aurais bien supprimé le label En cours.
Il y a 10 issues en tout dont 7 fermées avec ce label
Mais il reste 3 issues ouvertes
Je pense malgré tout qu’il est supprimable. Des objections ?

Une fois décidé du sort de « En cours », je fais les suppressions de label en masse et je passe à la promotion des labels listés plus haut et à leur réaffectation pour les PRs et les issues

[b_b]

@JamesRezo

Le renommage « enhancement → amélioration » a été effectué.

Top, merci !

@JamesRezo

Pour la suppression des labels, on est, a priori sur la liste :

Je doute sur la suppression de wontfix, invalide, et refusé, d’autres avis ?

@JamesRezo

Concernant les labels doublon/duplicate, j’ai « linké » la trentaine de tickets « doublons », donc ces labels sont prêts à étre supprimés.

Topito !

@JamesRezo

J’aurais bien supprimé le label En cours.

gogogo, vu qu’on a les dasboards de gitlab qui indiquent qu’un ticket ou une pr sont en cours si une personne se l’est assignée.

[JamesRezo]

@b_b

Je doute sur la suppression de wontfix, invalide, et refusé, d’autres avis ?

Moi pas

Quand une issue est fermée c’est soit :

• parce qu’une ou plusieurs PR sont mergées (ça fixe, ça améliore, c’était une demande « valide » qui n’a pas été refusée)
• parce que pas de PRs ou pour tout un tas de raisons sur lesquelles aucune statistique n’est tenue.

Sur les 8341 issues (ouvertes ou fermées) de tout git.spip.net (1383 projets ) en date d’hier soir :

label	nombre d’issues associées
wontfix	1
refus	94
invalide	61
bug	3839
amélioration	1175

Sur les 2810 PRs (mergées ou pas) :

label	nombre de PRs associées
wontfix	0
refus	0
invalide	0
bug	14
amélioration	15

[JamesRezo]

Un petit tableau récap’ par espace sur la plate-forme.

espace	nb projets	issues	bug	amélioration	wontfix	refusé	invalide	prs	bug	amélioration
*	1383	8341	3839	1175	1	94	61	2810	14	15
spip/*	40	5398	3786	1067	0	90	56	1426	14	13
spip/spip	1	4326	3253	771	0	76	37	765	9	8

Pourcentage par rapport au total d’issues (8341)

espace	% projet	% issues	bug	amélioration	wontfix/refusé/invalide	% PRs
*	-	-	46.0%	14.1%	1.9%	-
spip/*	2.9%	64.7%	45.4%	12.8%	1.8%	50.7%
spip/spip		51.9%	39.0%	9.2%	1.4%	27.2%