Gestion des tickets sur GitHub et organisation générale

Gaaaaaarde à vous ! :D

a marqué ce sujet comme résolu.

J'ai une question sur la fermeture des tickets.

Un ticket peut/doit etre ferme apres la phase de QA + merge ou apres un dernier test en prod' ?

Eskimon

Si j'en crois ceci :

En cours / Validation : État du ticket une fois qu'il a été pris en charge. Une fois le dev terminé, il passe de "en cours" à "validation" pour être testé. À l'issue du test, soit il repasse "en cours", soit il est fermé.

nohar

On peut fermer directement quand c'est mergé.

Exact. La QA déclenche le merge, le merge déclenche la fermeture de l'issue. Pas besoin de "test en prod" (fondamentalement le test est censé être fait avant la prod, et en prod il est trop tard pour tester).

Si une issue est QA-isée, validée, fermée, et qu'elle déclenche quand même une erreur en prod (parce que l'erreur est humaine et que la QA peut avoir zappé un cas particulier), alors l'issue est réouverte.

+0 -0

Yep.

Ça me fait penser que je proposerais bien un système de branches pour coller avec ce process, j'ai une idée dont on pourrait discuter. Mais ça attendra après la V1. Je voudrais pas tout chambouler en une semaine non plus ! :D

+0 -0

Hello,

Je sais bien qu'on est en rush beta et tout, mais je tiens tout de même à parler de nos démarches de bug fix. Le projet a un bug plutôt délicat concernant les fichiers de tutos, ce qui a entrainé certaines situations de conflits un peu partout avec une myriade de d'issue toutes liées au même problème source. Ce qui m'a fait tilté c'est principalement le fait que certaines PRs ont tentée de résoudre les PRs de manière individuelles, ce qui avait pour conséquence immédiate de créer une ambiguité dans les fichiers des tutos.

Autant le front-end est un truc qu'on peut réparer facilement, autant certaines parties du back (tout ce qui touche la bd) aussi on peut réparer facilement, autant, tout ce qui concerne les fichiers physiques stockés, il faut faire très très attentions.

Je proprose donc, de revoir un peu le processus de QA. Actuellement les PR sont testées par les QA de manière fonctionnelle (ont vérifie que le bug en question est fixé et qu'il y'a pas d'impact négatif). Cependant, les PR qui touchent à des fichiers sont très délicates, parce que c'est le genre de chose qu'on ne peut pas rattraper plus tard. Et on ne va pas lancer une V1 et dire 6 mois plus tard, "Coucou les mecs, on a repensé notre structure de stockage et du coup, l'historique de vos tuto est irrécupérable".

En résumé, je penses qu'il faudrait obligatoirement une review technique coté back pour chaque PR qui touche au stockage (fichiers tutos, articles, images). Je pense même qu'il faudrait le rajouter dans le contributing.md pour que les contributeurs signale une PR qui touche aux fichiers sensibles.

Je suis d'accord avec firm1.

Puisque je vais bientôt merger les post-its de ce forum, je vais en profiter pour essayer de rendre cette info bien visible pour que les contributeurs en tiennent compte lorsqu'ils interviennent sur une issue (que ce soit du point de vue dev ou QA).

Pour ce qui est du front, c'est différent. Il suffit de préciser dans le process qu'un test de QA front doit être fait sur un panel représentatif de browsers : une erreur qui passe au travers est de toute façon beaucoup moins critique que le cassage irréversible de la rétro-compatibilité sur la structure des tutos, puisque c'est réparable a posteriori, donc ça ne justifie pas une code review systématique.

+0 -0

Le seul truc un peu con c'est que ca apparait pas dans la page PR (mais ca apparait dans la page issues). Donc faut les ouvrir une à une pour vérifier si c'est simple ou pas…

Du coup je pense qu'il faudrait remettre en avant le "Notes pour QA" comme certains avait commencé. Quelqu'un qui ne connectait pas trop l'architecture peut facilement passer à côté de chose. Par contre il faut volontairement balayer large pour être sur de sur-couvrir la PR en termes de use case.

+0 -0

Bon… Cet aprem' j'ai tenté un truc. J'ai "formé" deux jeunes gens à la QA en leur montrant pas a pas la procédure a suivre pour faire les choses…

Ca m'a permis de découvrir une chose : Les "Notes pour la QA" sont indispensables…

Reprenons mon cas d'exemple.

J'ai montré sur la PR "Gravatar". Cette dernière corrigeait un souci simple, l'email utilisé pour appeler gravatar doit etre en minuscule, sinon le hash est mauvais. C'est tout con et vraiment simple à QA. Seulement une personne ne connaissant pas Gravatar ne peut pas faire la QA. Et pour cause, pour ce "bug", si on le test sans modif pour le constater, on voit juste que le gravatar est différent selon l'email (avec ou sans majuscules). En soit on constate visuellement pas de réelle problème.

Je pense donc qu'il faut aller au dela de ce qui nous parait évident en tant qu'habitué et parce qu'on sait d'avance quoi attendre. Il faut reussir a se mettre a la place de la personne pour vulgariser a minima dans les cas moins classique meme s'ils sont triviaux. Je sais que c'est un exercice chiant (rédiger une PR) mais c'est la garanti d'une prise d'initiative de la part des validateurs de PR.

Si qqun voit le truc, fait un test et voit pas de bug évident il va juste se dire "comprend pas ca bug pas". S'il est pro actif il posera une question sur GH, sinon il passera son chemin…

Dans mon "mini-training" j'ai essayé d'insister sur "Poser des questions !!" mais je sais que tout le monde n'est pas à l'aise avec ca…

Bref, il faut vraiment se mettre à la place des validateurs, sans pour autant etre trop cadré pour ne pas rater des cas… C'est difficile !

+6 -0

Ce topic est un peu outdated !

Il faudrait soit l'actualiser, soit ajouter un message pour dire qu'il n'est plus d'actualité et le dés-épingler.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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