Rafraîchir le backlog

Certains d’entre vous ont peut-être remarqué une forte diminution du backlog concernant Mobilizon sur Framagit – il est passé de plus de 500 issues ouvertes à moins de 300 cette semaine.
Disclaimer : il n’y a pas eu des centaines de développements.
Mais il est ingérable d’avoir un backlog de 500 issues. Imaginez qu’en passant seulement 5 minutes sur chaque, il faudrait plus de 40h simplement pour s’en imprégner. Forcément, il y avait des doublons, et dans les meilleurs cas des problèmes déjà résolus.
Pour « rafraîchir » le backlog, je mène une action radicale en fermant presque systématiquement les issues antérieures à la dernière version (novembre 2023). Je garde ouvertes seulement les demandes d’évolution appuyées par plusieurs personnes et celles qui font écho à l’actualité du moment (financement NLNet notamment).
Par défaut, vous devriez recevoir une notification lorsqu’une issue que vous avez créée ou avez commentée est close*. Dans ce cas, n’ayez aucun scrupule à la rouvrir si vous le regrettez et qu’elle n’a pas été rendue obsolète par la toute dernière version.
J’ai fermé de très bonnes idées bien documentées et des bug reports de grande qualité. Le fait qu’une issue soit close n’est pas du tout une remise en cause de sa pertinence, de sa faisabilité ou de sa validité – seulement un moyen de rafraîchir le backlog pour y voir plus clair.
Le backlog représente un énorme travail collaboratif qui mérite la reconnaissance de toute la communauté et rien n’est perdu: les personnes travaillant sur le backlog peuvent facilement faire des recherches étendues aux issues fermées.

Enfin, sachez que de valeureux développeurs sont à l’œuvre actuellement grâce au financement de NLNet. A suivre…

*liste des auteurs d’issues closes à ce jour:
Albatroz Jeremias
allilengyi @allilengyi
Alysson (Alyve) @Alyve
André Menrath
Antoine Rousseau @antoine129
anubister
Benedikt Wildenhain
Benjamin Bouvier
bikepunk @bikepunk
Booteille @Booteille
Cédric Van Rompay
davidak
Elvith @Elvith
FabriqueDuBocage
Florian Sesser
fluxx
Forte
fouine
Francescopog
Francois Audirac
FrancoisA @FrancoisA
Gaëtan Blond
suite au prochain message

2 Likes

Gavy @Gavy
Geno
Ghost User
Guillaume Gomez
Guillaume Lacasa @glacasa
hfte
Hippolyte Signargout
Hugo @Hugo
Hukadan @Hukadan
Ivan Boothe
J B
jinxxproof
Joel Takvorian
joenepraat
Julian-Samuel Gebühr
Kerstin Humm
Khrys
Kinetix
l-vincent-l
Lahax
lom
Luc Didry
Luca Eichler
luke21923
Malik
Manuel Viens @manuelviens
Marc-AntoineA @Marc-AntoineA
Mariano Mollo
Mark Monteiro
MC
Meldane @Meldane
Michael Marx
Milo Ivir
mohican
Monsieur X
Mostafa Ahangarha
na bla
Networking Guy
Nils Van Zuijlen
Norwin
numahell @numahell
Popi @popi

Raphael Megzari
RebelCode
Riccardo Sacchetto
S1m
setop @setop
Setto Sakrecoer
Shlee
Siltaar
spf @spf
Squeeek GPS
Stéphane Bortzmeyer @bortzmeyer
Stephen Paul Weber
taziden
Tealk @Tealk
Thomas @tcit
Thomas Clavier
ty kayn @tykayn
VA
Vegard Fjeldberg @vegafjord
Victor @Victor
xundeenergie

Je précise avant toute chose que j’ai conscience du peu de temps dont dispose la ou les personnes qui contribuent au logiciel Mobilizon, et que je remercie toutes les personnes qui travaillent ou ont travaillé sur le projet.

Comme signalé sur ce ticket, seul l’auteur du ticket (et les membres du dépôt) peuvent rouvrir un ticket fermé. C’est problématique car, au-delà de leurs auteurs, toutes les personnes utilisant Mobilizon sont potentiellement concernées par les bugs, et elles ne pourront pas rouvrir les tickets qui les décrivent.

Un backlog massif n’est pas problématique en soi. Le problème pour une personne qui veut contribuer au logiciel, que le backlog contienne 10, 100 ou 1000 tickets, c’est de savoir par quoi commencer, ce qui est le plus important pour le plus de personnes utilisatrices, non ?

A mon sens, plutôt que de fermer massivement les tickets, il faudrait donc qu’ils soient priorisés.

Idées « quick wins » :

  • utiliser les labels (« bug », « feature ») pour simplifier le tri
  • utiliser les templates pour que les tickets soient mieux décris par les personnes
  • inciter les personnes (notamment dans le template de ticket) à chercher dans le backlog avant d’ouvrir un ticket, à voter :+1: sur les bugs et features dans Gitlab
  • faire des sondages sur le forum pour décider les tâches (bugs, features) à faire

Notes :

Le template de ticket existe pour les bugs mais pas pour les features.

Il y a déjà pas mal de votes sur certains tickets, ce qui donne déjà une idée des priorités mais je ne sais pas si c’est représentatif. :thinking:

Hello Johan,
Je suis tout à fait d’accord avec toi dans les grandes lignes.
Mais j’aimerai aussi le feedback de ceux qui traitent les issues. Je ne suis pas sûre que le backlog tel qu’il est aujourd’hui, avec des doublons et des issues plus du tout en phase avec la nouvelle version, leur soit vraiment utile.
Pour ce qui est de la réouverture d’issues, cela ne pose pas de problème, il suffit de mettre un commentaire et je les réouvre. Certains l’ont fait - merci à eux!

Et merci beaucoup à toi pour le lien vers les issues « populaires », c’est très pertinant pour orienter les contributions. J’ai même envie de dire qu’il n’y a pas mieux.

1 Like