milestone 4.2

Équipes maintenance
#1

Re,

à l’instant (presque) t, on constate que la version 4.2 ne serait complète qu’à 34% :

Milestones
Milestones2568×896 216 KB

Autant les 100% de la 4.1 me semblent conformes, étant donné qu’elle est en security-fix et qu’on ne traite pas les tickets de sécu dans le dépôt spip/spip, et que les 28% de la 5.0, ça me va aussi parce qu’elle est en développement, autant je pense qu’il faudrait désormais concentrer (« rejoindre » @b_b dans ^^) notre réflexion sur d’éventuels « traitements de masse » …

4.2 est sortie il y a plus d’un an, son 11e patch est sorti récement … dans mon esprit, ça a sonne plus complet que 34% …

à l’instant t:

milestone 4.2
milestone 4.22272×1514 465 KB

Je sais pas vous, mais moi, j’aime bien les 3 colonnes de ce tableau. C’est automatique :

  • ticket créé = non démarré
  • assigné = en cours (du coup, le label du même nom fait peut-être doublon ?)
  • clos = complet. (éventuellement, fermé automatiquement lors du merge d’une PRs associée)

Et donc, 284 tickets « non-démarré » qu’on retrouve ici : Tickets · spip / spip · GitLab

Si on enlève les bugs qu’on peut a priori traiter et livrer dans un patch 4.2, il reste 211 tickets : Tickets · spip / spip · GitLab

Je propose qu’on enlève la milestone de ces 211 tickets dans un premier temps,

puis qu’en fonction de leur âge, des commentaires, on leur assigne une autre milestone :

Des avis ?

#2

Hop,

Ça pourrait nous permettre de retirer un label, mais je ne pense pas que c’est la même chose. Perso, lors de ma revue des tickets des semaines précédentes, je me suis assigné certain ticket pour les ajouter à ma todo, mais je ne sais pas du tout quand j’aurai le temps de m’y pencher (faudrait déjà que je vois le bout de la revue des tickets ^^). Si on considère qu’un truc assigné est en cours, alors certaines personnes motivées pourraient passer à côté de ticket en attente de traitement puisque quelqu’un se l’est assigné, alors bon laissons couler.

Ou alors, si on valide cette méthode (ce qui serait malin puisque ça suit ce que propose la forge sur la page que tu cites), il faudrait bien indiquer aux membres de l’équipe que même si un ticket ets assigné on peut s’y atteler (en se l’assignant).

Pourquoi pas, perso j’ai pour habitude de poser une version cible dès qu’un ticket est créé, ça nous permet de savoir si on doit le reporter dans la branche stable par la suite. En retirant cette info, on risque de déporter dans la discussion de la PR liée le choix du report en branche stable ou non, mais peut-être que c’est pas plus mal.

#3

Alternativement, je voyais le fait d’assigner quelqu’un·e à un ticket, non pas comme en charge de produire le code éventuel, mais plutôt comme chargé d’animer la réalisation. L’un n’empêchant pas l’autre, hein …

ça permettrait aussi de répartir la masse de tickets entre plusieurs personnes pour les faire avancer. Histoire d’alléger ta charge mentale :wink:

Mais j’entends. Ça se discute…

Je comprends bien. mais peut-être que ce serait possible une fois assigné

Et puis, d’un temps à l’autre, on peut se repasser des tickets, les désassigner s’ils sont « abandonnés » ou "postponed’ …

#4

Ha mais si ça permet de réduire ma charge mentale, je ne discute pas, je VALIDE ! ^^

Oui, de toute façon la proposition est bonne, car au final, c’est bien plus facile de dire qu’une PR peut-être reportée en branche stable par rapport à un ticket. En voyant le code proposé on sait plus facilement si c’est reportable ou pas.

Claro, ça nous changera des revues de tickets qui sentent le grenier :stuck_out_tongue:

#5

Sur le milestone 4.2, tous les tickets d’améliorations ne devraient probablement pas avoir ce jalon, assez logiquement: Tickets · spip / spip · GitLab

Je suis assez d’accord pour faire du ménage là dedans.

1 « J'aime »
#6

On peut faire ça …

bulk edit
bulk edit1920×1024 122 KB

1 « J'aime »
#7

Oh j’avais pas vu ce Update All… top dis donc.

#8
#9

Sujet clos, donc.