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% …
Ç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.
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
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’ …
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
