Réflexion et optimisation autour des tags de GH

parce qu'on a rien de mieux pour le moment

a marqué ce sujet comme résolu.

Salut tout le monde !

Après bientôt un an d'existence du dépôt de ZdS dans un état publique sur GitHub, je propose de faire un point sur l'utilisation de ce dernier et de voir comment les choses peuvent être améliorée (si c'est possible évidemment).

Tout d'abord, je pense qu'il faut se rendre à l'évidence, au vu des différentes discussions menées sur le forum concernant un outil de gestion : On est pas sorti de l'auberge. Des outils il en existent plein, avec chacun leurs atouts et inconvénients mais rien de parfait n'existe. Et le temps que des décisions avancent, autant faire avec ce que l'on a : GitHub.

Du coup, voici une proposition d'évolution sur la manière de traiter les issues (tickets) et les milestones (jalons), les deux grands moyens de catégorisations que l'on possède actuellement.

Concernant les milestones, voici ma proposition :

  • Par défaut, les ticket ne sont pas assigné à une milestone ;
  • Le fonctionnement des releases reste identiques. Un ticket corrigé est assigné à la release suivante ;
  • Lors d'une release, tout bug trouvé dans cette dernière se voit assigner le milestone de la release, afin de suivre la "propreté" de cette dernière ;
  • Idéalement, une release passant en prod' n'a alors plus de tickets ouvert ;
  • Les milestones "Futur proche 1.x" et "Futur lointain 2.x" sont supprimées (j'y reviens tout de suite).

À propos des tickets maintenant. Clairement, il faut faire un tri dans les labels/tags car là en plus d'en avoir qui non pas de sens, la sémantique n'est pas clair et certains sont carrément sans plus aucune raison d'existence.
Partons donc du principe qu'on les vire tous (désolé pour ceux utilisé par des outils externes dont personne ne parle).

Dans ma tête, j'imagine des tickets par catégorie. Chaque catégorie est représenté par une couleur et ses nuances. Voici la liste que j'imagine (les niveaux 2 serait les noms des tickets) :

  • Compétences/Domaine
    • Front
    • Back
    • API
    • Doc.
    • Infra
  • Priorité
    • Bloquant
    • Haut
    • Moyenne
    • Faible
  • Statut
    • Régression
    • Bug
    • Évolution
  • Difficulté
    • Facile
    • Difficile

Je suis conscient que cela fait plus de tag, mais la sémantique devrait aider à mieux les utiliser. En plus de ceux-ci, des tags "ZEP" pourraient éventuellement exister pour aider les contributeurs sur ces dernières.

Quelques règles de contraintes pourraient aussi être utilisé. Par exemple un bug/régression devrait toujours avoir une priorité, alors que pour une évolution cela semble facultatif.

Voili voilou pour mes idées.

@Spacefox, je sais que cela altère le mécanisme de release actuelle, mais c'est une proposition et vu que certains dev. arrivé en cours du projet semblent aussi avoir des avis là dessus autant en profiter pour en parler :)

A vous les studioz !

+7 -0

Alors mon point de vue :

A propos des milestones

  • Par défaut, les ticket ne sont pas assigné à une milestone ; OK avec les tickets de priorisation.
  • Le fonctionnement des releases reste identiques. Un ticket corrigé est assigné à la release suivante ; OK
  • Lors d'une release, tout bug trouvé dans cette dernière se voit assigner le milestone de la release, afin de suivre la "propreté" de cette dernière ; Non, et j'insiste. Pourquoi ? Parce que le seul moyen qu'on a pour connaître le contenu réel d'une release, c'est ces milestones. Donc, on ne doit avoir que des tickets fermés dans les milestones. Un ticket réouvert devrait même sortir d'une milestone, d'ailleurs, puisque par définition si le bug n'est pas corrigé le ticket n'a rien à faire dans la release donc dans la milestone.
  • Idéalement, une release passant en prod' n'a alors plus de tickets ouvert ; Cf la ligne précédente : je ne vois pas de raison de mettre du conditionnel.
  • Les milestones "Futur proche 1.x" et "Futur lointain 2.x" sont supprimées (j'y reviens tout de suite). OK avec les tickets de priorisation.

À propos des tickets

Le système proposé me va très bien. Je pense même que ça fait moins de tickets qu'aujourd'hui.

J'ai toutefois 3 remarques :

  1. Les priorités c'est bien. Sauf qu'aujourd'hui tout le monde se fout des priorités. Du coup je ne sais pas si c'est vraiment utile (mais ce serait bien que ça le soit).
  2. Le ticket infra, c'est "il y a une action à faire sur les serveurs" (donc qui ne peut pas être du code pur), et rien d'autre. Aujourd'hui il est utilisé n'importe comment. L'idée, c'était de permettre de vérifier la cohérence avec le fichier update.md.
  3. Qui se charge de ticketter ?
+0 -0

Merci du retour ! (et j'invite les 6 +1 a donner un avis histoire qu'on sache si "tout vous va" ou si c'est juste "j'aime l’idée de révision du fonctionnement" ;) )

C'est bien, je vois qu'on est d'accord avec le fait qu'une milestone n'a pas une aussi belle sémantique qu'une priorité :)

Pour tes 3 remarques. Le fait que l'on ai peu de nouveaux tickets/jour (sauf les 48h suivants les releases en général) ca me fait pas vraiment peur de se dire qu'on sera en mesure de ticketter correctement dans des temps réalistes (on = les gens ayant le pouvoir de mettre les labels). A l'heure actuelle "tout le monde se fout des priorités" car on en a peu/elles sont pas claires. A part le label "bloquant" il n'y a rien de clair sur comment voir rapidement quels tickets (bug surtout) sont prioritaires sur d'autres, c'est dommage je trouve.

Pour cette histoire de bug en release, ca veut dire qu'on accepte de faire des releases avec des nouveaux bugs. En soi pourquoi pas mais je trouve ca un peu sale. Je sais que certains dev' aimerait avoir un moyen de voir rapidement les bugs de release. Du coup faudrait trouver un moyen de l'indiquer (on les met tous en regression ?)

+0 -0

Ben pour moi, ce genre de cas, c'est juste des bugs. Ca veut dire qu'on les traite selon leur nature et non selon là où ils sont apparus :

  • Si c'est des régressions (ce qui est probable), on les taggue comme tel, sinon ils ont un tag "bug"
  • Ils sont priorisés selon leur priorité intrinsèque
  • S'ils rentrent dans les critères de correction de release (= bug très grave ou très simple avec peu de risque d'effets de bord) on les corrige dans la release, sinon ils attendront

Alors je comprends le côté frustrant d'avoir découvert un bug et de le mettre en prod quand même. Mais on a pas vraiment le choix : on a déjà du mal à corriger les vrais gros problèmes dans la release dans les temps ; si on essaie de corriger tous les nouveaux bugs, on ne va plus jamais sortir quoi que ce soit.

Je rappelle que la limitation des releases à 2 semaines est là pour limiter les problèmes de merges des correctifs de release. On a déjà pas mal de merges délicats avec des conflits, et bien peu de monde pour s'occuper de ça. Toute solution alternative qu'on imaginerait doit prendre en compte cet état de fait.

+0 -0

Bonjour, je suis un des "+1" et j'ai deux choses à dire.

  1. Je suis grosso modo d'accord avec les propositions d'Eskimon: mieux vaut tard que jamais, et autant être sur que tout le monde sois d'accord là dessus. Je dis pas que c'est parfais (voir remarques de Spacefox), mais ça à le mérite d'être logique, donc je ne peux qu'approuver. Placardez ça dans la doc, faites quelques rappels à l'ordre et ça devrait passer comme sur des roulettes.
  2. Le gros, que dis-je, l'énooooorme problème du développement de ZdS, selon moi, c'est que tout le monde n'en fait qu'à ça tête. Et je dis pas ça pour rigoler: chaque dev fait un peu ce qu'il veut quand il veut s'il le veut (et moi le premier). Je ne sais pas comment on en est arrivé là ni ce qu'on peut faire contre ça, mais même si les tags sont là, si je vois un ticket et que je me dis "tiens, mais je connais la solution", je vais tenter de le résoudre, même si c'est un bug mineur et qui date d'il y a 6 mois. Et j'ai un peu l'impression que c'est pareil pour tout le monde (je dis d'ailleurs pas que c'est forcément une mauvaise chose, je dis juste qu'il faut faire avec ou aller contre ça).
+0 -0

Le gros, que dis-je, l'énooooorme problème du développement de ZdS, selon moi, c'est que tout le monde n'en fait qu'à ça tête. Et je dis pas ça pour rigoler: chaque dev fait un peu ce qu'il veut quand il veut s'il le veut (et moi le premier). Je ne sais pas comment on en est arrivé là ni ce qu'on peut faire contre ça, mais même si les tags sont là, si je vois un ticket et que je me dis "tiens, mais je connais la solution", je vais tenter de le résoudre, même si c'est un bug mineur et qui date d'il y a 6 mois. Et j'ai un peu l'impression que c'est pareil pour tout le monde (je dis d'ailleurs pas que c'est forcément une mauvaise chose, je dis juste qu'il faut faire avec ou aller contre ça).

La on touche au fait que "tout le monde est bénévole, on va pas commencer a forcer les gens a faire des choses qu'ils veulent pas".

Et en soi, si il y a un ticket et que tu connais la solution bah vazi, ca fera toujours un ticket de moins, personne t'en voudra pour ca ! Par contre si c’était un bug ce serait mieux :D

Bon je le disais pas mais j'ai espoir que mettre des priorités et que ca soit explicite car visible au premier coup d'oeil et filtrable puissent aider les contributeurs a s'orienter vers ca en premier (manipulation, psychologie toussa :ninja: ), mais c'est juste une intuition que j'ai…

+2 -0

Je suis partagé mais j'aurais 3 questions/remarques :

  1. Les tags de la catégorie du premier niveau seront des tags concrets ou uniquement les tags du second niveau ?
  2. J'ai toujours détesté les tags "Facile" et "Difficile". J'ai vu des tags "Facile" appliqué sur des bugs API qui ne l'était pas et ça induit alors en erreur le futur contributeur qui veut résoudre des bugs faciles (ces contributeurs qui sont souvent des nouveaux venus). Personne ne peut dire avec certitude si un bug est facile à corriger ou pas. La seule certitude que nous pouvons avoir, c'est de savoir si c'est un bug ou non (et encore).
  3. En tant que chef de projets, est-ce que tu prends la responsabilité de maintenir ça tous les jours de l'année ? Si oui, bravo. Si non, ça ne fonctionnera pas. Dans les 2 cas, il faut quand même un second chef de projets parce que si tu comptes maintenir ça tous les jours mais que tu pars en vacances plusieurs jours ou que tu tombes malade, les tags redeviendront crades.
+2 -0

Je suis partagé

Sur quoi ? Tout ?

  1. juste les second niveaux. Les premiers niveaux étaient juste la pour indiquer la réflexion que j'ai faite et guider la lecture.
  2. Yep, c'est assez subjectif selon le dev. Perso je met facile quand je suis sur que c'est facile (traduction qui manque, typo) ou que je donne une solution que j'estime (subjectif encore) assez claire pour être appliquée par n'importe qui en peu de temps. Le difficile je le garde généralement aux trucs qui demanderont de la refacto lourde. Mais c'est vrai qu'il y a une grosse part de feeling dans tout ca
  3. Comme dit plus haut, a priori des tickets on en a pas tout les jours. Une fois qu'un ticket est tagge, il devrait plus être touche sur ce point la. A priori pas mal de contributeurs réguliers savent comment taggue sur les critères objectifs (compétences et statut (et se font corrige s'il y a une faute, on est entre humain quand meme)). Ensuite la priorité c'est pas mal pour faire de la gestion de projets (et donc pas dramatique s'il y en a pas) et la difficulté c'est juste un indice facultatif.

Je ne l'ai pas précisé mais le taggage des PR est facultatif car trop chronophage et volatile (sauf pour les PR sans ticket, pour la génération des rapports de release ^^ )

+0 -0

A priori pas mal de contributeurs réguliers savent comment taggue sur les critères objectifs

Je n'ai pas les droits pour tagger ou bien je sais juste pas utiliser github.

En tant que chef de projets, est-ce que tu prends la responsabilité de maintenir ça tous les jours de l'année ?

Donc c'est entériné, le roi du papier peint est le CDP?

Bon je le disais pas mais j'ai espoir que mettre des priorités et que ca soit explicite car visible au premier coup d'oeil et filtrable puissent aider les contributeurs a s'orienter vers ca en premier (manipulation, psychologie toussa :ninja: ), mais c'est juste une intuition que j'ai…

ça serait un gros plus.

+0 -0

Sur quoi ? Tout ?

Sur beaucoup de choses et je voulais avoir tes réponses pour donner un avis plus précis point par point.

Pour ce qui concerne la gestion des milestones, je suis d'accord avec la finalité du débat entre SpaceFox et toi, je ne vais donc pas revenir là dessus.

Pour ce qui concerne les tickets, j'ai plusieurs choses pour lesquelles j'ai quelque chose à dire, voire contre :

Compétences/Domaine : Le tag "Front" et "Back" coulent de source. C'est quelque chose que nous utilisons déjà aujourd'hui et qui fonctionne très bien. "API" est presque un "Back" alternatif puisque ce sont des nouvelles URLs, de nouvelles vues et de nouveaux formulaires (appelées Serializer dans l'implémentation). Son tag se justifie. Nous avons assez de soucis avec la documentation pour justifier son tag. Par contre, j'ai toujours eu du mal avec le tag "Infra". Je sais qu'il est utilisé par SpaceFox (et c'est pour cette raison que je ne vais pas être contre) mais tous les tickets avec le tag Infra ne concerne pas le code source. Normalement, ces issues n'ont rien à faire là.

Priorité : Le tag "Bloquant" est sans aucun doute le tag le plus utilisé à ce jour pour indiquer aux contributeurs quelles sont les issues importantes à un instant T. Par contre, je suis contre les autres tags de cette catégorie parce que cela va te demander du travail sur le long terme de les maintenir et c'est totalement subjectif (ou alors il faut établir des règles précises binaires suite à la lecture d'une issue). Pour moi, le tag "Bloquant" est suffisant. Nous sommes dans un projet open source avec tout ce que cela implique, ce concept utilisé dans le milieu de l'entreprise n'est pas applicable dans notre projet.

Statut : Ces statuts sont déjà dans le projet aujourd'hui et fonctionnent très bien. A ceci près qu'une regression est forcément un bug. A mon sens, une issue avec le tag "Regression" ne devrait pas avoir le tag "Bug" mais c'est vraiment pour chipoter.

Difficulté : Comme tu le dis toi même, c'est subjectif. Du coup, je suis contre. Comme pour la catégorie "Priorité", s'il n'y a pas de règles binaires pour savoir si nous mettons un tag "Facile" ou "Difficile", il ne faut pas les avoir. Aujourd'hui, nous les avons déjà ces tags dans le projet et ils fonctionnent beaucoup moins bien que ceux de la catégories "Compétences/Domaine" et "Statut".

ZEP : La notion de ZEP ne devrait pas figuré sur le dépôt GitHub, encore moins dans les tags. Pour moi, c'est un concept clair pour les forums de Zeste de Savoir pour designer des specs. La suite, c'est de l'implémentation et c'est à traiter de la même manière qu'une PR d'une issue.

Comme dit plus haut, a priori des tickets on en a pas tout les jours

Aujourd'hui, nous avons 214 issues ouvertes. C'est énorme et il va falloir faire une passe sur toutes pour les fermer ou pour appliquer les nouveaux tags.

Donc c'est entériné, le roi du papier peint est le CDP?

Oui, c'est ce qui a été convenu après l'AG.

+1 -0

La notion de ZEP ne devrait pas figuré sur le dépôt GitHub, encore moins dans les tags. Pour moi, c'est un concept clair pour les forums de Zeste de Savoir pour designer des specs. La suite, c'est de l'implémentation et c'est à traiter de la même manière qu'une PR d'une issue.

Non, car certaines ZEP ont tellement d'impact qu'elles corrigent des issues de base.

La ZEP 12 permet plein de choses côté back sur les tuto et articles (notamment articles)
La ZEP 05 corrige pas mal de bug de génération, ajoute la génération aux articles (qui a sont issue) et est un précurseur à la ZEP je sais plus combien qui améliore l'éditeur et le parsing du markdown. Les ZEP d'API sont précurseurs aux issues d'ajaxification…

+2 -0

Je te retourne la question dans l'autre sens : Pourquoi les tagger ? Un tag donne des informations sur sa nature, son origine. Toi, tu veux appliquer un tag sur sa correction. C'est pas logique. Limite, tu te l'assignes mais c'est tout.

Je laisse notre CDP trancher.

+1 -0

À noter que le tags "ZEP-12" existe déjà. Je trouve qu'il a du sens parce que à un moment, je vais l'utiliser et dire "ok, ça c'est fait" et "non, ça c'est pas fait". Mais je suis tout à fait d'accord que c'est plus une question de facilité qu'un tag qui a un réel sens. Si on le fait disparaitre, j'en mourerais pas (mais je risque de zapper des trucs). Le problème de l'assignement, c'est que soit je m'assigne moi, soit artragis, mais comme on est deux sur la ZEP, ça rend l'assignement subjectif (à noter qu'"assignement" n'est pas français :p )

@artragis: les gens qui peuvent assigner des tags sont ceux qui font partie du groupe "contributeurs réguliers" et dès facto les droits de merge (c'est comme ça que je les reconnais). Ça ne nous concerne pas (ou j'ai raté le formulaire de candidature à un moment ^^).

+0 -0

CDP = Caribou/Cervidé Du Projet ;) ?

Priorité : Pour les priorités comme dit plus haut c'est surtout pour voir si les membres pourraient s'en soucier ou non. Je pense que les contributeurs les plus réguliers pourraient être tenter de les résoudre en premier, mais pas sur. Après faudrais pas qu'il y ai l'effet pervers inverse, un contributeur en puissance arrive, voit les tickets taggé "urgent" et se disent "oulah je sais pas faire je vais pas pouvoir aider". Je propose donc l'idée suivante : Est-ce qu'on peut s'accorder sur une règle officieuse entre contributeur régulier du "le tag bloquant est urgent" puis "Essayer de regarder les bugs avant les évolutions" ?

Compétences : Je vous suis, on peut donc dire que le tag infra va dégager. Le tag API reste cependant.

Statut : Une régression est un bug. C'est un pléonasme que de mettre les deux tags (sauf cas suffisamment rare pour être ignoré).

Difficulté : C'est très subjectif effectivement. Si personne ne les réclame alors on les vire.

tag ZEP : Bon c'est un cas particulier. D'une part ils n'ont rien à faire en l'état comme l'a expliqué Andr0. Cependant ils sont bien pratiqué quand des bugs sont spécifiques à une feature, en un coup d'oeil on sait grosso modo où on ira chercher. Si on les vire ca serait bien dans ce cas d'avoir cette précision dans le titre du ticket.

Aujourd'hui, nous avons 214 issues ouvertes. C'est énorme et il va falloir faire une passe sur toutes pour les fermer ou pour appliquer les nouveaux tags.

Je m'y engage (sachant que les tags "évolution" et "bug" ne bougeront pas de toute facon).

J'aimerais aussi faire une petite vague d'update sur les contributeurs et leurs droits, je verrais ca avec Spacefox :)

+0 -0

Est-ce qu'on peut s'accorder sur une règle officieuse entre contributeur régulier du "le tag bloquant est urgent" puis "Essayer de regarder les bugs avant les évolutions" ?

C'est pas déjà le cas ?

Je vous suis, on peut donc dire que le tag infra va dégager.

J'attends l'intervention de SpaceFox sur ce point.

ZEP : Je me plierai à ta décision finale. Je n'ai rien de plus à rajouter sur ce point.

CDP = Caribou/Cervidé Du Projet ;) ?

Tu as de la chance, tu veux que je t'explique à quoi me fait penser DTC ? ^^

+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