C'est pas déjà le cas ?
J'ose l’espérer, mais comme ca au moins c'est dit 
Tu as de la chance, tu veux que je t'explique à quoi me fait penser DTC ?
Directeur Technique Canidés ? 
Ça aurais pu coller à Arius, ça, mais non
Je n'ai rien à ajouter à la discussion ! Par contre, est-ce qu'on pourra avoir une PR ajoutant le fonctionnement des milestones et la liste des tags à la documentation ?
Par contre, est-ce qu'on pourra avoir une PR ajoutant le fonctionnement des milestones et la liste des tags à la documentation ?
Quand tout sera ratifié je ferais ca 
Ca serait cool d'arriver avec le maximum d'opinions avant le prochain Zest'Meeting (qui arrivera surement en début de semaine prochaine )
Pour l'instant ca ressemblerait a ca :
J'aimerais plus d'opinions sur les catégories "priorités" et "difficultés". Les arguments sont :
Mon avis : je suis en train de revoir mon jugement, je n’émet donc pas mon opinion finale pour le moment)
Mon avis : Ces tags devraient continuer a exister, avec facultatif. Un jeu de règles pourrait être : Pour tagguer facile, une solution d’implémentation doit être proposée dans les commentaires du ticket. On tag difficile quand on sait que le travail demande s’étalera sur une durée longue (refacto) OU que c'est un module difficile a tester (solr…) OU que c'est un problème propre a une configuration particulière (gros jeu de données, charge etc).
Les tags ZEP sortent, mais les devs sont encouragé a indiquer dans les titres des issues si ces dernières concernent une ZEP particulières pour faciliter la recherche.
Les milestones 1.x et 2.x dégagent aussi au profit des tags bugs (qui reflète 1.x) et évolution (qui reflète 2.x). Dans un monde parfait les régressions seront traites en priorité.
En ecriveant ces dernières lignes je me rends compte que les tags de priorité pourraient dégager si les devs ont la même philosophie de priorisation (je vous avais dit que mon avis était pas clair !)
Précision supplémentaire : Je suis en train de regarder comment fonctionne les groupes sur GH. Je ne sais pas encore si c'est possible mais je souhaite élargir les droits de certains membres contributeurs réguliers pour qu'ils puissent eux aussi tagguer et fermer les tickets.
Dernière précision pour les futures tageur : Quand on sais pas on tag pas (ou on demande), qqun d'autres s'en occupera .
Le tag "infra" ne peut pas sortir tant qu'on a pas une solution pour gérer les problèmes d'infra, justement.
My bad ! Je voulais relire mon message et les précédents pour confirmer ce point avant d'envoyer puis j'ai oublié ! j'edit !
Ou va le tag "Chiant" ? 
Je pense que l'on pourrait rajouter :
Les milestones 1.x et 2.x dégagent aussi au profit des tags bugs (qui reflète 1.x) et évolution (qui reflète 2.x). Dans un monde parfait les régressions seront traites en priorité. En ecriveant ces dernières lignes je me rends compte que les tags de priorité pourraient dégager si les devs ont la même philosophie de priorisation (je vous avais dit que mon avis était pas clair !)
Gros +9999 !
On pourrait réduire le nombre de tags :
et n'avoir que des milestones de type "Version x.x" !
Je n'étais pas encore passé ici, je donne donc mon avis sur la base du dernier post d'Eskimon.
Si le Tag infra sort, il faudrait nommer une solution de remplacement. Aujourd'hui il y en a aucune. Car il y a des tickets qui ne peuvent pas être réglé par du code. On fait comment donc ? On crée un dépot zds-infra (on profite pour balancer tout ce qui est script de déploiement là bas) ?
A mon sens, pour faire partir ce tag, il faut une alternative, sinon le problème risque de ne jamais être résolu.
Avec du recul, pour moi un régression est un bug, on devrait garder uniquement le tag "Bug". La particularité d'une régression est le fait que c'est plus facile a résoudre en général qu'un nouveau bug. Dans ce cas se servir des tags "bug" et "facile" permet d'exprimer le fait que c'est un bug qui est simple a résoudre car on sait quel commit a apporté la régression.
Le tag "facile" à un utilité, car il permet au nouveau de savoir quels tickets prendre. Il a toujours été bien utilisé jusqu'ici, je crois qu'on peut garder son fonctionnement.
Le tag Difficile n'a pas vraiment de raison d'être pour moi pour la simple et bonne raison que si un tache n'est pas facile, elle est forcément difficile, sans oublier que la difficulté d'une tache peut diminuer en fonction du temps qui passe (la correction d'une issue liée peut rendre une issue qui était difficile autrefois, facile aujourd'hui). Avoir un tag difficile impose dont une maintenance en plus.
Il y'a une notion qui n'existe pas dans github, et je me demande si c'est pas possible de l’intégrer. Il s'agit de la dépendance entre les tickets. Pouvoir dire que la résolution d'un ticket dépend d'un autre me semble important et pouvoir filtrer dessus encore plus pertinent.
Un tag "dépendant" (ou autre nom) apposé sur les tickets qui ne peuvent pas être résolu sans la résolution d'un autre ticket permettrait d'avoir cette information. Quand un dev débarque, il saurait donc que c'est pas la peine d'aller résoudre un ticket dépendant.
EDIT : J'ai commencé a écrire et je remarque que SpaceFox a fait la même remarque que moi sur l'infra.
EDIT 2 : Pour moi le Tag Chiant ne devrait même pas exister tellement il est pas clair autant pour le taggueur pour pour celui qui veut filtrer
On crée un dépot zds-infra (on profite pour balancer tout ce qui est script de déploiement là bas)
2 problèmes pour cette solution :
Avec du recul, pour moi un régression est un bug,
Ca c'est sur. Mais a mon sens faire le distinguo reste utile, au moins pour prioriser entre un bug (lie a une nouvelle feature a priori) et une régression (une correction qui a un effet de bord négatif). Perso j'ai de la tolérance pour un bug, mais une régression a tendance a "m'agacer" car altère un fonctionnement auquel je suis habitué (et je pense pas être le seul dans ce cas).
Pour le taf infra, j'ai franchement peur que s'il est dans un autre dépôt personne ne s'en occupera jamais.
Pour cette histoire de dépendance, on a beaucoup de ticket de ce genre ?
Le tag Difficile n'a pas vraiment de raison d'être pour moi pour la simple et bonne raison que si un tache n'est pas facile, elle est forcément difficile, sans oublier que la difficulté d'une tache peut diminuer en fonction du temps qui passe (la correction d'une issue liée peut rendre une issue qui était difficile autrefois, facile aujourd'hui). Avoir un tag difficile impose dont une maintenance en plus.
Je suis d'accord, mais en terme d'indication, ça serait peut être sympa du coup de remplacer le tag "difficile" par une "estimation à la louche du temps que ça prend" pour qu'on puisse mieux s'organiser.
Un tag "dépendant" (ou autre nom) apposé sur les tickets qui ne peuvent pas être résolu sans la résolution d'un autre ticket permettrait d'avoir cette information. Quand un dev débarque, il saurait donc que c'est pas la peine d'aller résoudre un ticket dépendant.
ça peut être une solution, clairement, c'est ça qui me manque personnellement par rapport à un outil style redmine/track.
Pour la différence bug/régression, je suis aussi pour que ça soit gardé :
Je suis d'accord, mais en terme d'indication, ça serait peut être sympa du coup de remplacer le tag "difficile" par une "estimation à la louche du temps que ça prend" pour qu'on puisse mieux s'organiser.
Sauf qu'on peut pas faire de tag pour ça… (Je pense pas que des tags ~1h, ~1/2j, ~1j soit très pertinent car très dépendant de chaque dev).
Sauf qu'on peut pas faire de tag pour ça… (Je pense pas que des tags 1h, 1/2j, ~1j soit très pertinent car très dépendant de chaque dev).
n'existe-t-il pas une commande github qui permette de parser le contenu du ticket et on ajouterait dans le ticket une simple ligne temps: 1h/2h. Ensuite dans le champ recherche on n'aurait qu'à taper "les tickets où temps: 1h"
Vous allez beaucoup trop loin. J'étais déjà loin d'être chaud avec "Facile" et "Difficile" mais rajouter en plus des estimations de temps dans les tags, c'est juste non catégorique pour moi pour toutes les raisons que j'ai déjà donné sur la catégorie "Difficulté".
On crée un dépot zds-infra (on profite pour balancer tout ce qui est script de déploiement là bas)
2 problèmes pour cette solution :
- Il y a des tickets qui semblent être du code et qui sont de l'infra ou inversement. Il faut pouvoir les migrer de projets
- Le script de déploiement est lié fortement au code (Cf son historique). Ça risque de poser des problèmes si on le sort du dépôt principal.
Pour le 1. rien n’empêche de les migrer ailleurs, on a souvent le cas avec les tickets markdown. Quelqu'un poste dans "zds-site" on se rend compte que c'est à cause de "python-zmarkdown" et le ticket est fermé, puis ouvert là bas.
Pour le 2. ça dépend de ce qu'on mets dans ce dépôt je pense. Si on travaille comme avec nos dépots annexes (zmarkdown, etc.), on aurant le fonctionnement suivant :
Pour le taf infra, j'ai franchement peur que s'il est dans un autre dépôt personne ne s'en occupera jamais.
En même temps, il y'a pas grand monde qui a des accès serveurs, donc de toute façon c'est réservé a un périmètre restreint. J'ai plus le sentiment qu'ils seront mis en valeur s'il sont ailleurs que mélangés avec les issues de zds-site.
Pour cette histoire de dépendance, on a beaucoup de ticket de ce genre ?
Je suis déjà tombé sur beaucoup quand je faisais le tri sur le bug que je peux corriger. Il y'en a qui sont marqué "zep-12" en ce moment qui sont éligibles à ce tag, car dépendant de quelques choses (ici la zep-12). Il y'en a qui sont dépendant de l'API sur tel ou tel module, il y'en a qui sont dépendant d'une refacto quelconque, etc.
n'existe-t-il pas une commande github qui permette de parser le contenu du ticket et on ajouterait dans le ticket une simple ligne temps: 1h/2h. Ensuite dans le champ recherche on n'aurait qu'à taper "les tickets où temps: 1h"
Tu peux t'amuser a mettre ça dans le ticket et la fonction de recherche de GH le gérera correctement, mais comme dit plus tôt, c'est hyper subjectif comme estimation, le niveau des contributeurs est quand même assez hétérogène (chacun étant plus connaisseur d'un point ou d'un autre) !
Pour le 1. rien n’empêche de les migrer ailleurs, on a souvent le cas avec les tickets markdown. Quelqu'un poste dans "zds-site" on se rend compte que c'est à cause de "python-zmarkdown" et le ticket est fermé, puis ouvert là bas.
Pour le 2. ça dépend de ce qu'on mets dans ce dépôt je pense. Si on travaille comme avec nos dépots annexes (zmarkdown, etc.), on aurant le fonctionnement suivant :
- Je taggue le dépot "zds-site" en v1.x
- Je mets à jour le dépot "zds-infra" avec les tags à déployer. Le fameux script deploy.sh peut être mis à jour directement avec certaines instructions qu'on a l'habitude de mettre dans le update.md (genre les apt-get machin).
Le but du jeu est de simplifier et fiabiliser le fonctionnement, tes propositions font l'exact inverse.
D'autre part, le seul argument que j'ai pour une gestion séparée des tickets infra, pour l'instant, c'est "peut-être que les tickets seront plus visibles s'ils sont séparés".
Je rappelle à toutes fins utiles que l'on gère le code du site zestedesavoir.com et non une application dont le but est d'être réutilisable (c'est juste un effet de bord encouragé) ; et donc que tout argument à base de "oui mais les tickets infra mélangés au reste ça ne concerne pas les forks" est nul et non avenu.
Pour l'argument de mise en valeurs, tu peux aussi simplement sortir tout les tags infra en cliquant sur le label correspondant.
C'est pas faux, mais en règle général en ce moment mon filtre github se résume à : "bug" + "assignés à personne". Le problème c'est que je suis pollué par les issues infra et donc je perds potentiellement du temps dans mon tri.
Après si on ne peut pas faire mieux, je survivrai.
Pour les gestions des dépendances, saviez vous que l'on pouvait faire des listes a cocher dans les tickets ?
Exemple : https://github.com/zestedesavoir/zds-site/issues/2272
Et ca donne ca sur la liste des tickets :
Alors oui je sais c'est pas un vrai système de dépendance mais c'est un début !
Doc: https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments
(Merci Gustavi !)
À priori, c'est quelque chose que seul les personnes avec des droits spéciaux sur le dépot peuvent faire. Autrement dit, je peux le faire chez artragis parce qu'il m'as donné le droit, mais pas chez vous. Après effectivement, ça peut être utile
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