Centraliser la gestion des bugs dans un outil unique

Nettoyage à la bombe thermonucléaire !

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

Salut les agrumes,

On en a déjà plus ou moins parlé, mais je préfère refaire un sujet propre à partir d'une idée de Kje, qui me paraît de plus en plus intéressante au fur et à mesure que j'y réfléchis.

Il s'agirait de centraliser toute la gestion de bugs et améliorations dans un outil unique

Postulats de base :

  • On a des bugs et suggestions à divers endroits : Github, le forum "bugs et suggestions", le forum "Dev zone", parfois d'autres biais (IRC, mails, etc).
  • Le système de workflow de Github est vraiment trop simpliste pour notre utilisation1

Problèmes que ça pose :

  • Doublons en tous genres
  • Tickets oubliés
  • On est jamais certains du périmètre exact d'une release

Proposition de solution : dégainer l'arme thermonucléaire, ce qui reviendrait à :

  • Avoir une instance d'un outil de gestion de bug tiers. Lequel ? À définir. Ci-après il est appelé "l'Outil".
  • Développement minimal pour lier les comptes ZdS avec ceux de l'Outil (si j'ai un compte sur ZdS, j'en ai automatiquement un sur l'Outil). Connexions liées si c'est facile à faire. But : éviter que les gens doivent s'inscrire à un outil spécifique pour rapporter un bug.
  • Pas d'import automatique de bugs sur l'Outil.
  • Import manuel de l'important : ZEP, hotfix
  • Arrêt du système d'issues Github
  • Mise en lecture seule du forum de bugs et suggestions, interdiction d'utiliser le forum de dev pour poster des bugs et suggestions
  • Lien bien visible sur le forum bugs et suggestions pour renvoyer vers l'Outil
  • On incite la communauté à faire de la migration de tickets qui lui paraissent utiles
  • Au bout de trois mois, tout ticket non migré est considéré comme sans importance (puisque personne ne l'a trouvé assez important pour le migrer) : le forum "bugs et suggestions" passe en privé, et on supprime le module de tickets de Gitub

Deux questions :

  1. Est-ce que ça vous paraît être une bonne idée ? Est-ce que ça vous paraît jouable ?
  1. Voyez-vous un outil qui serait pratique pour ce faire ? (Il doit être relativement grand public, permettre des conversations et plus efficace que Github sur les workflows).

  1. T'as vu firm1 ? Je l'ai écrit ! 

Staff

Personnellement je suis pour. On est encore au stade assez jeune a partir duquel on peut se permettre ce genre de chose. Surtout c'est indispensable. Actuellement il y a des bug, suggestions et zep un peu partout. Plus compliqué, il y a des tickets sur le GH qui datent "d'avant le workflow". En particulier il y a des tickets existant qui mériteraient une zep, qui n'existaient pas à cette époque.

Pour moi c'est la bonne solution a notre problème actuel : on passe de 3 lieux à un seul et on en profite pour faire le grand ménage. Le point le plus critique étant probablement le choix de l'outil.

+0 -0

J'aimerais tellement pouvoir vous proposer Projuice, … Si seulement je pouvais bosser dessus à plein temps… Mais ce ne serait tout de même pas réaliste, il vous faut une solution mûre.

J'espère vraiment que vous trouverez la solution parfaite alliant définition de workflows et multi-rapporteurs (visiteurs, développeurs) et surtout orientés "specs" ce qui est vraiment très complexe à trouver.

Bon courage, et bravo pour l'initiative, c'est maintenant qu'il faut se poser ce genre de questions.

Édité par Javier

Happiness is a warm puppy

+0 -0
Staff

Perso, je ne peux que plucentoyer (hyperbole du plussoiement) sur le fond.

Ceci dit, je tilte sur quelques points:

Développement minimal pour lier les comptes ZdS avec ceux de l'Outil (si j'ai un compte sur ZdS, j'en ai automatiquement un sur l'Outil). Connexions liées si c'est facile à faire. But : éviter que les gens doivent s'inscrire à un outil spécifique pour rapporter un bug.

SapceFox

Je dirais aussi, développement minimal pour adapter l'interface de l'"Outil" au visuel de ZdS (au moins dans les couleurs)

Pas d'import automatique de bugs sur l'Outil.

Je ne comprends pas ce ça veut dire. On pourrait l'interpréter de plusieurs façon :

  • on ne devrait pas pouvoir importer un nouveau bug du forum B&S vers l'Outil ?
  • on ne devrait pas pouvoir importer la pile de bug existante du forum B&S vers l'Outil ?
  • on ne devrait pas pouvoir importer un nouveau bug Github vers l'Outil ?
  • on ne devrait pas pouvoir importer la pile de bug existante Github vers l'Outil ?
  • tout en même temps ?

Du coup, une précision serait pas de refus.

Arrêt du système d'issues Github

Je suis pour, et tout le monde sait pourquoi

  • Mise en lecture seule du forum de bugs et suggestions, interdiction d'utiliser le forum de dev pour poster des bugs et suggestions
  • Lien bien visible sur le forum bugs et suggestions pour renvoyer vers l'Outil

SpaceFox

J'aurai dit "Migration des tickets non résolu, puis suppression du forum B&S". Parce que :

  • c'est moins frustrant pour ceux qui lisent
  • ça n'aide pas à la centralisation
  • on évite de développer une fonctionnalité "forum en lecture seule"

Au bout de trois mois, tout ticket non migré est considéré comme sans importance

SapceFox

Pour moi, si le bug a été signalé, il devrait être migré, sauf si on a décidé qu'il n'est pas important.

Voyez-vous un outil qui serait pratique pour ce faire ? (Il doit être relativement grand public, permettre des conversations et plus efficace que Github sur les workflows).

SpaceFox

Si on n'était pas encore dans le boxon actuel, j'aurai bien vu l'outil sur lequel Javier est train de plancher (Projuice), qui sur le papier correspond bien à ce qui nous serait utile.

Mais là, je vois surtout JIRA, mais quelque soit l'outil, il faudra clairement l'utiliser pendant un moment (~3 semaine pour moi) à coté pour valider son adoption et décider d'appliquer tout ça.

Staff
Auteur du sujet

Pas d'import automatique de bugs sur l'Outil.

= Pas d'import automatique de l'existant ou de nouveaux bugs sous quelque forme que ce soit.

J'aurai dit "Migration des tickets non résolu, puis suppression du forum B&S".

C'est pour faire cette migration que je propose de mettre le forum en lecture seule (migration que je propose de faire faire en partie par la communauté en ce qui concerne tout ce qui n'est pas super important).

on évite de développer une fonctionnalité "forum en lecture seule"

Je pensais que ça existait déjà ?!

Pour moi, si le bug a été signalé, il devrait être migré, sauf si on a décidé qu'il n'est pas important.

Dans tout projet on a des tas de bugs et surtout de suggestions faites, mais qui finalement n'intéressent réellement personne. C'est normal et fait partie de la vie d'un projet. Une bonne pratique est de périodiquement dégager tous les tickets sans aucune activité depuis X temps, en considérant que finalement ça n'intéresse pas et donc qu'on a pas à garder le ticket actif.

Là c'est une variante brutale de la chose : on ne conserve même plus le ticket dans le nouvel outil.

C'est valable avec les bugs : un bug présent que personne ne s'est donné la peine de corriger en 6 mois, c'est que tout le monde s'en fiche et donc que c'est pas vraiment un bug.

Staff

C'est valable avec les bugs : un bug présent que personne ne s'est donné la peine de corriger en 6 mois, c'est que tout le monde s'en fiche et donc que c'est pas vraiment un bug.

SpaceFox

Hmmm, pas trop pour. Un bug peu rester pendant 6 mois pour moi, sans être traité parce qu'il n'est pas prioritaire. Je trouve que supprimer une déclaration de bug (qui demande tout de même un effort) parce que personne ne s'en est occupé c'est pas cool. Après ce n'est que mon point de vue.

Staff

Il y a un outil de gestion de projet open source, complet et assez user-friendly (mais qui a évidemment un module pour la gestion des bugs) développé avec Django + AngularJS : Taiga.io

Je ne suis pas un expert Django, mais ça devrait être facilement jouable d'intégrer l'issue tracker au site et d'avoir un truc bien ficelé avec une connexion unique pour le site et l'outil voire d'étendre l'outil pour inclure une timeline pour les ZEPs, etc. Et comme c'est open source, on pourra aussi aider au développement de l'outil if needed. Seul hic : étant donné que c'est plus récent que des outils comme JIRA, c'est forcément moins connu (j'ai pas regardé la doc) et c'est en bêta mais ça me parait jouable.

Édité par Arius

Staff

Alors je trouve que c'es tune bonne idée car ça permetrait d'avoir un truc bien intégré à moindre coup. Ça a l'air bien fait et moderne. Le projet ce sépare en 2, l'un avec Django pour le back qui expose une api, et le front qui ne necessite rien coté serveur et utilise Angular pour le front. Du coup on pourrait très bien intégré la partie back dans notre code et faire un front qui utilise ces API, voir temporairement s'occuper uniquement de l'authentification et utiliser leur front. Le seul soucis est que le projet fonctionne uniquement sur Python 3.4+, ce qui n'est pas notre cas :(

+1 -0
Staff

Va falloir accélérer la migration à Python3 alors ! Plus que 2 libs qui font chier !

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff

C'est ce qui a été acté (zds-meeting 2 si mes souvenirs sont bons) mais faut que quelqu'un prenne le courage de faire ça. Perso je connais encore trop mal cette partie du code pour avoir le courage et le temps de me consacrer à ça :/

Pour la seconde je ne me rappelle plus laquelle c'est.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff

Si je me fit à https://caniusepython3.com , dans le requirements.txt principal :

  • django-munin

En non vérifié :

  • GitPython
  • python-zmarkdown (nos extensions seulement, assez rapide à faire, je crois qu'un membre l'a déjà fait)

dans le requierement de dev (requirements-dev.txt):

  • faker

edit:

A noter cependant que :

  • django-munin fait que quelques centaines de lignes, il serait ultra rapide à porter si il n'est pa déjà compatible (pas d'info)
  • faker est un faux positif, il est en réalité compatible.

Bref il ne semble y avoir que GitPython de problématique


edit2:

Le développement de GitPythons semble avoir repris. Du coup le support de python 3 est prévu dans une release proche. On aura peut être bientot nos dépendances de migrés sans avoir rien a faire.

Édité par Kje

+1 -0
Staff

Indeed. De toute façon le plus morceaux est et restera notre base de code à nous. Même avec toutes les dépendances de migrés, il nous faudra un peu de travail et pas mal de tests pour être sûrs que ça fonctionne…

+2 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte