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

Salut,

Ceux d'entre vous qui ont encore accès à la ML (moribonde) sont au courant, mais pas les autres. Depuis l'ouverture de la bêta privée, je suis venu vous rejoindre comme directeur technique^{1 2}. Pour résumer rapidement mon rôle : je suis là pour organiser le développement du site de manière à ce que tous les contributeurs techniques aient un cadre clair pour travailler (sachent quoi faire et comment le faire), et pour faciliter la prise de décisions. Mais je ne suis pas là pour vous montrer mes gallons donc fermons cette parenthèse.

Vous l'aurez peut-être remarqué, je suis passé faire un tour sur GH cette nuit pour y foutre un boxon monstrueux essayer de l'organiser de manière à ce qu'on puisse embrasser la globalité du projet en un coup d'oeil. Entre autres, j'ai :

• Fait le ménage dans les labels,
• Défini la milestone "Bêta publique" manquante,
• Commencé à classer les issues par milestone,
• Refusé une PR (je vais revenir sur cet incident parce que c'est important).

En fait, j'ai créé ce thread pour discuter de l'organisation que je vous propose pour le GH :

Les labels

Les labels doivent servir à qualifier rapidement un ticket au premier coup d'œil, et non de marque-page perso. Ils doivent donc constituer un ensemble limité de tags répartis en plusieurs catégories (une couleur par catégorie).

Voici l'ensemble qui me semble le plus pertinent à l'heure actuelle. Un ticket peut être labelisé par n'importe quelle combinaison entre :

• Bug / Régression / Évolution : S'il y a besoin d'un correctif, soit c'est un bug, soit c'est une régression (les deux en même temps sont redondants). Sinon, c'est une nouvelle feature.

• Front / Back / Pages statiques / Markdown : Sur quoi porte le ticket (compétences requises pour le régler) ?

• 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é.

• Facile / Difficile : Identifier la difficulté relative du ticket, pour les potentiels nouveaux contributeurs. J'ai supprimé le label "moyen" : c'est la difficulté par défaut.

• Bloquant bêta publique / Bloquant V1 : Quoique légèrement redondante avec les milestones, c'est une information dont on veut qu'elle nous saute au visage, parce que ces tickets sont prioritaires sur les autres.

Assignees

J'ai lu sur une issue que jusqu'à la bêta les tickets n'étaient jamais assignés. À partir de maintenant il faudrait que ce soit le cas : identifier tout de suite les issues bloquantes qui ne sont pas prises en charge, ça n'a pas de prix. Je me suis arrangé avec Talus pour créer un groupe spécial pour pouvoir assigner des contributeurs externes aux tickets (notamment pour artragis cette nuit).

Gestion des PR et QA

Revenons sur la PR fermée de cette nuit. En ce moment, je vous rappelle que nous sommes en freeze, donc que le but de chaque PR est de stabiliser le site. À cet effet, je vais sûrement me montrer chiant, mais à mes yeux : aucune PR ne doit être envoyée (ni acceptée) si le dev n'a pas au moins rapidement validé son code. Il est évident que tout commit envoyé sans avoir été un minimum testé par le dev représente une perte de temps potentielle que ce soit pour le dev, la personne qui testera la PR, ou pire, les utilisateurs qui tomberont dessus si le dev merge sa propre PR.

D'une façon générale en ce qui concerne le merge des PR, je n'ai pas l'impression qu'il y ait une phase de "QA" bien définie. Avons-nous des gens dédiés à la tâche de tester effectivement les PR avant de les merger (bref des gens pour faire de la QA) ?

Si ce n'est pas le cas, je pense que ça va être le moment de faire un appel à contributeurs. L'idéal serait que chaque PR soit prise en compte par une personne "QA" (à laquelle le ticket concerné par la PR est alors assigné lorsqu'il passe en Validation), chargée de tester celle-ci en détail et de donner son GO/NOGO sur la PR. Idéalement toujours, seuls les gens de ce groupe QA devraient avoir le pouvoir de merger.

Je pense avoir fait le tour des remarques que j'ai actuellement en tête.

Avez-vous des questions ou des remarques ? Que pensez-vous de cette organisation ? Est-ce qu'elle vous convient ?

On peut la faire évoluer si besoin.

Vu mon niveau python, je peux être utile pour du test de PR Back principalement (n'ayant pas envie de me retaper une install des outils front, désolé). Je n'ai pas de réellement experience dans le domaine de la QA, mais je sais lancer des tests auto (voire en ajouter dans certains cas) ou vérifier manuellement une modification.

Je peux le faire le soir en général.

J'aime bien corriger des bugs simples sur le back aussi…

De manière générale, je suis très pour une politique assez "chiante" pour avoir de la QA, quitte à avoir des process avec un peu plus de lag.

@Eskimon: Parfait ! Félicitations pour ta promotion.

Quelqu'un serait tenté par la QA Front ?

Est-ce que c'est possible de rajouter un groupe qui soit pas forcément collaborateur, mais qui puisse assigner, et mettre les labels sur GH ? Parce que perso, je peux pas le faire, et c'est un peu relou de pas pouvoir label ses propres issues… c:

Et je pense qu'on peux en profiter pour mettre (enfin) en place un BugTracker, comme dit sur cette issue (d’ailleurs, la dernière proposition du caribou me paraît pas mal…)

Idéalement toujours, seuls les gens de ce groupe QA devraient avoir le pouvoir de merger.

Il arrive que firm1 et moi-même validions mutuellement nos PR, du coup c'est un peu compliqué de ne pas nous donner le droit de merger.

PR et QA

Merci d'expliciter vos accronymes/condensés de lettres cher DT Autant PR c'est Pull Request, autant QA vu le contexte c'est une personne qui check la qualité ou un truc du genre, mais aucune idée précisément de ce que ça signifie

Le soucis d'une vérification un peu "chiante" Eskimon c'est qu'il faut quand même qu'on boost pour éviter d'avoir des choses pendant 5 jours en attente de merge et donc d'avoir des rapports de bugs qui sont en fait déjà résolus mais en cours de merge.

Sinon, globalement je fais les reviews front de Sandhose et lui reviews les miennes (ainsi qu'Eskimon).

@Sandhose : Pour le BT, je pense qu'il va falloir qu'on fasse un "vrai" comparatif, même rapide, des options qui s'offrent à nous, du coup ça risque de prendre un petit peu de temps avant qu'on se soit décidés. Mais sinon je suis complètement d'accord. J'avais jamais utilisé les issues GH avant, et c'est quand même un peu limité.

Pour ce qui est du groupe GH, j'ai posé la question à Talus, qui n'a pas encore accès à la devzone (mais ça ne va pas tarder) : ça lui semble "chaud".

Je viens de t'ajouter à la liste des contributeurs réguliers, comme ça tu disposes des droits dont tu as besoin.

@Alex-D : Quality Assurance

Le soucis d'une vérification un peu "chiante" Eskimon c'est qu'il faut quand même qu'on boost pour éviter d'avoir des choses pendant 5 jours en attente de merge et donc d'avoir des rapports de bugs qui sont en fait déjà résolus mais en cours de merge.

Ça c'est mon affaire. Je suis 100% d'accord avec Esquimon, et si jamais on doit être charrette sur les échéances parce qu'on a besoin de temps pour QA-iser proprement, j'en assume complètement la responsabilité.

Donc Alex, tu veux conserver le droit de merger tout en admettant que tester minutieusement avant une MEP te gave ? J'ai peur.

Le soucis d'une vérification un peu "chiante" Eskimon c'est qu'il faut quand même qu'on boost pour éviter d'avoir des choses pendant 5 jours en attente de merge et donc d'avoir des rapports de bugs qui sont en fait déjà résolus mais en cours de merge.

Ouai enfin jusque là j'ai toujours réussi à faire les tests de PR dans les 24h où elles étaient proposées. Je peux pas m'engager et signer avec mon sang, mais je pense pouvoir maintenir le rythme et je préviendrais si je peux pas (genre d'avance je peux vous dire que de jeudi soir à lundi matin j'aurais pas de PC)

Chaque soir quand je me met la dessus, je fais d'abord les issues "Validation" avant de commencer à bricoler une issue facile à faire.

EDIT qui n'a rien a voir. @Nohar, tu pourrais ptet prendre les infos de ce post-it et les mergé dans ton post pour faire un post-it de moins ?

Je mergerai celui-ci dans l'autre (et le dépostiterai) une fois qu'on se sera tous mis d'accord sur l'organisation.

Donc Alex, tu veux conserver le droit de merger tout en admettant que tester minutieusement avant une MEP te gave ? J'ai peur.

Non, je veux pouvoir tester les PR front des autres et les merger. Et laisser le soin à d'autres de merger mes modifs.

Et aussi, merger rapidement des choses comme des corrections de typo : ça n'implique pas de bugs possible, je ne vois pas trop l'intérêt dans ces cas là d'avoir une review.

Alex, le but c'est de paralléliser entre tests et développement, justement pour que les gens puissent se concentrer sur l'un ou l'autre. C'est beaucoup plus confortable quand tu développes de ne te soucier que des trucs à implémenter/corriger : au moins tu vois tout de suite là où ta compétence est requise, du coup ça rentabilise le temps que tu passes sur le projet.

Certes, mais typiquement pour le design, c'est quand même moi qui fait en sorte que tout soit cohérent, tant au niveau du code que visuellement.

Typiquement j'ai factorisé le code de Sandhose sur sa PR de la galerie. Je l'ai également aiguillé pour qu'il garde le même style graphique que tout le site et non réinventer un truc non-cohérent.

Autant le back je peux comprendre, les guidelines c'est Django. Pour le front c'est plus délicat que ça.

Un test n'est pas une review. Là on parle de tests fonctionnels : le code marche et ne casse rien, ou bien il ne marche pas. Pour les code reviews et les refactorisations, ce sera après la V1.

Dans ma boîte on a des devs frontend, leur façon de travailler est à la fois compatible avec la QA et tout aussi efficace, donc je ne vois pas où est le problème.

Dans ma boîte

Je n'ai jamais travaillé en entreprise avec tout ce système autour, je m'en excuse, mais du coup je ne peux pas trop savoir.

Pour les code reviews et les refactorisations, ce sera après la V1

J'ai parlé de factoriser pas de refactoriser ce qui est différent. J'ai retiré du code inutile puisque existant ailleurs : on update à un seul endroit. Ca me semble relativement logique à ce niveau là.

Je veux bien croire que ce soit déroutant au départ. Cela dit, le but c'est vraiment de permettre à tout le monde de gagner du temps tout en garantissant la qualité du site pour les utilisateurs : ce sont eux les grands juges, et ils veulent un truc qui marche avec des features stables qu'ils attendent le moins longtemps possible.

Je te propose d'essayer, je te promets que d'ici la sortie tu vas ressentir le confort que ça t'aura apporté.

Tout à fait à part, pourquoi pas échanger en MP ou sur un canal IRC "dev" avec Sandhose pour communiquer rapidement et l'aider sur ses issues front ? Ça l'aiderait sûrement à maîtriser plus vite le code.

pourquoi pas échanger en MP ou sur un canal IRC "dev" avec Sandhose

C'est déjà le cas via Skype depuis une semaine

Bah voilà, nickel. Du coup vous avez un moyen de vous arranger pour le front.

Exactement! Mais ça n'empêche pas Alex de repasser derrière moi, comme ça sera peut-être le cas pour la page de recherche qui viens d'être mergé

Tant que tout ce qui est poussé en prod est validé par le dev de la PR + un passage en QA, ça me va.

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' ?

Si j'en crois ceci :

On peut fermer directement quand c'est mergé.