Améliorer les outils et l'environnement de développement

[GerardPaligot]

Salut l'équipe technique,

J'aurais bien aimé un label discussion pour cette issue mais on fera sans.

Je ressens de plus en plus le besoin d'installer un réel environnement de développement autour du projet. Même si nous ne sommes pas beaucoup dans l'équipe technique, la nécessité se fait ressentir dès que 2 développeurs travaillent sur le projet en même temps (ce qui devrait bientôt être à nouveau le cas).

Avant d'en dire plus, l'existant :

• Un projet GitHub avec GIT comme versionning pour le projet,
• Des issues pour répertorier un peu tout et n'importe quoi (allant des tâches à réaliser à la gestion du projet en passant par divers questions ou sujets de discussion comme celui-ci).
• Travis comme intégrateur continu qui exécute régulièrement les tests unitaires du projet (et ils sont malheureusement peu nombreux).
• Des milestones pour organiser nos sprints.

Voilà, c'est un peu tout. Même si ça convenait au début, ça atteint très vite ses limites dès qu'on veut gérer le projet ou qu'on veut discuter d'un sujet particulier (technique ou un récapitulatif d'un sprint, etc).

Ce que je propose ? Nous pourrions avoir :

• JIRA pour organiser des sprints avec toutes les taches répertoriées dans un backlog.
• Un service (je n'en connais malheureusement pas) pour pouvoir discuter sans venir pourrir les issues sur le projet GitHub.
• Ouvert à d'autres propositions !

Qu'est ce que vous en pensez ?

[SpaceFox]

De l'extérieur, je n'ai pas l'impression que des limites soient atteintes. Tu peux nous en dire plus sur les problèmes qui t'ont gêné et ce que tu aurais aimé avoir ? Ça m'intéresse parce que je devrais (conditionnel) pouvoir donner un coup de main dans pas trop longtemps.

Je rappelle à tout hasard qu'on a un Redmine qu'on a laissé tombé pour tout mettre dans Github.

Le 14 mars 2014 14:14, Gerard notifications@github.com a écrit :

Salut l'équipe technique,

J'aurais bien aimé un label discussion pour cette issue mais on fera sans.

Je ressens de plus en plus le besoin d'installer un réel environnement de développement autour du projet. Même si nous ne sommes pas beaucoup dans l'équipe technique, la nécessité se fait ressentir dès que 2 développeurs travaillent sur le projet en même temps (ce qui devrait bientôt être à nouveau le cas).

Avant d'en dire plus, l'existant :

• Un projet GitHub avec GIT comme versionning pour le projet,
• Des issues pour répertorier un peu tout et n'importe quoi (allant des tâches à réaliser à la gestion du projet en passant par divers questions ou sujets de discussion comme celui-ci).
• Travis comme intégrateur continu qui exécute régulièrement les tests unitaires du projet (et ils sont malheureusement peu nombreux).
• Des milestones pour organiser nos sprints.

Voilà, c'est un peu tout. Même si ça convenait au début, ça atteint très vite ses limites dès qu'on veut gérer le projet ou qu'on veut discuter d'un sujet particulier (technique ou un récapitulatif d'un sprint, etc).

Ce que je propose ? Nous pourrions avoir :

• JIRA pour organiser des sprints avec toutes les taches répertoriées dans un backlog.
• Un service (je n'en connais malheureusement pas) pour pouvoir discuter sans venir pourrir les issues sur le projet GitHub.
• Ouvert à d'autres propositions !

Qu'est ce que vous en pensez ?

Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/200 .

[GerardPaligot]

Je ressens surtout très fortement le besoin sur la gestion du projet et avoir un canal de discussion officiel.

[firm1]

Personnellement, actuellement je ne sais pas vraiment si ça vaut le coup de prendre du temps pour mettre en place un vrai outils de gestion de projets vu le nombre d'intervenants actuels. On sait globalement qui bosse sur quel type de problematique (front, back django, markdown, transco, etc .). On sait ce qu'il nous reste a faire pour fermer un sprint ou un bakclog (d'ailleurs la dernière fois que j'en parlais on m'a dit qu'on ne bosse pas en agile :-p ). De plus, je pense que ce n'est pas une mauvaise idée d'avoir les discussions techniques dans les issues. Mon coté "Je raisonne en terme d'optimisation des ressources et gestion des priorités" me dit que ça peut être une perte de temps (installations d'un outil, reports des taches a faire, ...) et une perte de visibilité/communication dus a plusieurs canaux d'echanges (mailing list, github, le nouveau). Alors qu'on a pas non plus 50 000 ressources sous la main, pas trop le temps, et une palanquée d'issues a corriger pour une v1 basique.

En gros, ça peut être sympa, mais faudrait penser a l'éventualité d'un recrutement.

[dreherch]

"d'ailleurs la dernière fois que j'en parlais on m'a dit qu'on ne bosse pas en agile" -> Et c'est gênant ?

PS: Attention, un troll se cache sous ce message.

Le 14 mars 2014 17:44, firm1 notifications@github.com a écrit :

Personnellement, actuellement je ne sais pas vraiment si ça vaut le coup de prendre du temps pour mettre en place un vrai outils de gestion de projets vu le nombre d'intervenants actuels. On sait globalement qui bosse sur quel type de problematique (front, back django, markdown, transco, etc .). On sait ce qu'il nous reste a faire pour fermer un sprint ou un bakclog (d'ailleurs la dernière fois que j'en parlais on m'a dit qu'on ne bosse pas en agile :-p ). De plus, je pense que ce n'est pas une mauvaise idée d'avoir les discussions techniques dans les issues. Mon coté "Je raisonne en terme d'optimisation des ressources et gestion des priorités" me dit que ça peut être une perte de temps (installations d'un outil, reports des taches a faire, ...) et une perte de visibilité/communication dus a plusieurs canaux d'echanges (mailing list, github, le nouveau). Alors qu'on a pas non plus 50 000 ressources sous la main, pas trop le temps, et une palanquée d'issues a corriger pour une v1 basique.

En gros, ça peut être sympa, mais faudrait penser a l'éventualité d'un recrutement.

Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/200#issuecomment-37669060 .

[GerardPaligot]

Je comprends mais c'est dommage de penser comme ça parce que ça risque de nous prendre du temps (non négligeable je l'accorde) pour tout lancer mais un gain en temps sur le long terme. On pourra peut-être y réfléchir plus sérieusement après la bêta publique alors ?

Pour les méthodologies agiles, je ne pense pas que c'est adapté mais se référer aux concepts agiles pour les adapter à notre projet pourrait convenir.

[dreherch]

Je ne suis pas convaincu que déployer de l'outillage de gestion de projet soit très intéressant quand il n'y a que 5 dev (en tous cas, j'ai toujours observé une perte de temps, sauf si on prévoit un fort turn-over), mais n'étant pas concerné, mon avis n'est que purement indicatif.

Pour les méthodologies agiles, se référer à des concepts et faire notre sauce, c'est déjà ce qui se fait. Regarde le vocabulaire employé dans les mails, c'est celui de la gestion de projet, et notamment Agile. Ma remarque portait plus sur le fait que les méthodes agiles sont aussi variées que les personnes qui les appliquent, et que reprocher à quelqu'un qui fait de l'agile de ne pas le faire rigoureusement est un non-sens, l'absence de rigidité étant la base des méthodes Agiles. Pour ceux qui veulent des choses strictes, il y a les cycles en V, ISO9001, et CMMI, DO-178B ou autre en fonction de son domaine d'application.

Le 14 mars 2014 18:03, Gerard notifications@github.com a écrit :

Je comprends mais c'est dommage de penser comme ça parce que ça risque de nous prendre du temps (non négligeable je l'accorde) pour tout lancer mais un gain en temps sur le long terme. On pourra peut-être y réfléchir plus sérieusement après la bêta publique alors ?

Pour les méthodologies agiles, je ne pense pas que c'est adapté mais se référer aux concepts agiles pour les adapter à notre projet pourrait convenir.

Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/200#issuecomment-37671276 .

[Eskimon]

Je déterre un peu la conversation car le sujet m'intéresse et j'ai une question... Lorsque vous décidez de corriger un bug, est-ce que vous vous l'attribuez sur GH ou pas ? Si la réponse est non, ce serait pratique de le faire... Par exemple je m'étais mis en tete de regarder un bug une fois mon truc fait. Entre temps, quelqu'un s'y est mis et la corriger (ou commencer à commiter à ce sujet je sais plus). Du coup s'y je m'étais mis moi aussi à travailler à côté la dessus on aurait été deux à faire le même travail en parallèle ce qui aurait été dommage... Bref, tout ca pour dire que "GH fournit des outils qui fonctionne bien pour faire un peu de gestion de projet, ce serait dommage de ne pas les utiliser..."

[Alex-D]

En théorie oui, on s'affecte l'issue qu'on est en train de traiter.

[SpaceFox]

Vu les dimensions que prennent le projet, je pense qu'on peut remettre ce sujet sur la table (sur le forum dev ?)

[zopieux]

Je débarque sur votre projet, qui m'intéresse plus ou moins d'autant que je connais très bien Django et Python. Je suis effectivement un peu perdu. Y'a-t-il un salon IRC où l'équipe technique se réunit ? Si non, c'est un manque à combler…

[Alex-D]

il n'y a pas de guide du contributeur et autres informations importantes dans le README.

Il y a un CONTRIBUTING qui est fait pour ça.

y'a-t-il un salon IRC où l'équipe technique se réunit ?

Oui, #zds-dev sur irc.smoothirc.net

[gustavi]

UP !

Cette issue a 7 mois et les choses ont pas mal évoluées.@GerardPaligot est-tu toujours sur ta position ?

Personnellement ce qui manque c'est une interface où le commun des mortels (comprenez ceux qui ne font pas parti de l’équipe de dev et qui n'utilisent pas régulièrement Github ou une plateforme équivalente) peut signaler facilement un bug, une suggestion ou une question. OK on a les forums mais c'est pas ce qu'il y a de plus agréable/visible. Plusieurs fois on nous signal un bug déjà corrigé. En plus, il est difficile de savoir quelles améliorations sont voulues pas les membres du site (il y a le système de vote mais il est pas pratique dans ce cas), quelles améliorations sont en prévues/en cours/corrigées mais pas en prod.

L'idéal serait une interface où un membre de ZdS peut :

• avoir un accès à la liste des bugs/suggestions/questions en cours ;
• signaler un problème ;
• voter pour une amélioration de sorte à ce qu'elle soit traitée en priorité ;
• commenter pour donner son avis

Avec cela il faudrait ajouter la possibilité de lier :

• une ou plusieurs issues Github
• un lien vers une ou plusieurs ZEP qui traite des la question.

C'est peut être un peu utopiste mais ça simplifierai grandement le signalement des bugs.

Après je trouve que Github est très bien fait et fournit un grand nombre d'outils adéquats, je ne vois pas ce qu'une solution comme JIRA apporterait en plus.

[GerardPaligot]

J'avoue ne plus trop me soucier de ces questions puisque mon investissement dans le développement n'est plus aussi conséquent. Mais je pense toujours qu'un JIRA est nécessaire pour des questions de clarté dans les bugs & suggestions et de gestion de projets.

Après, je sais que ça ne sera pas fait et la gestion du projet actuelle semble convenir aux contributeurs très actifs actuels du projet.

[firm1]

la gestion du projet actuelle semble convenir aux contributeurs très actifs actuels du projet.

Moi ça ne me convient pas mais bon :(

[gustavi]

@firm1 explicite !

[SpaceFox]

+1

Un "ça ne me convient pas" sans la moindre explication, c'est juste du bruit.

[firm1]

Pour être plus précis. ça fait un moment déjà (depuis l'ouverture du code) que JIRA est devenu indispensable pour le projet car aujourd'hui on utilise github assez mal et au final on s'y perd clairement dans les issues.

Le must serait de developper un truc maison pour ZdS, mais mon petit doigt me dit qu'il y'a d'autres priorité, et que JIRA serait une meilleure solution provisoire que le bordel actuel.

[SpaceFox]

Le must serait de developper un truc maison pour ZdS

Ce n'est jamais une bonne solution, à moins d'avoir des besoins ultra-spécifiques qu'on a pas.

[GerardPaligot]

Pour être plus précis. ça fait un moment déjà (depuis l'ouverture du code) que JIRA est devenu indispensable pour le projet car aujourd'hui on utilise github assez mal et au final on s'y perd clairement dans les issues.

Je t'aime firm1 ! ^^

[firm1]

Je t'aime firm1 ! ^^

Veux tu m'épous .....

Non mais plus sérieusement, on a déjà la problématique des taches infra sur lesquelles ont a aucun suivi par exemple. On a une gestion des priorité un poil désastreuse actuellement. Tout ceci est déjà fourni gratuitement dans JIRA, pourquoi ne pas l'utiliser ?

Ce n'est jamais une bonne solution, à moins d'avoir des besoins ultra-spécifiques qu'on a pas.

Quand je disais le must, c'était surtout pour avoir un truc vraiment intégré au site et user-friendly. Aucun outil gratuit du marché ne permet ça.

[SpaceFox]

Ben en même temps, aujourd'hui on a plusieurs problèmes en parallèle :

• On a des issues sur github, sur le forum et parfois même dans la tête des gens
• La gestion des priorités on l'a à l'heure actuelle : bloquant, à faire bientôt, à faire si on a le temps un jour. 95% des tickets sont priorisés. Sauf que personne n'en a rien à faire (principalement parce que les trucs bloquants sont les trucs chiants).
• On a des erreurs de tags
• On a des QA qui n'avancent pas par manque de personnes pour faire de la QA - ce qui fout la merde dans les priorités. Le peu de personnes qui en font, font leur maximum
• Les tâches infra sont pour la plupart dans Github. Avec le tag "infra". C'est simple, sauf pour les issues pures infra qu'on oublie parce qu'on a aucun suivi des tâches spécifiques au déploiement (y'a une issue en cours). Mais il paraît que c'est hérétique et qu'il ne faut pas le faire. Alors ?

C'est clairement pas d'un outil dont on a besoin, mais d'un processus, duquel peut découler un outil.

Mais ajouter un outil juste pour ajouter un outil, c'est l'assurance de faire encore plus de merde.

Et d'autre part, il est absolument indispensable que l'outil soit le point d'entrée unique pour les issues. Les grandes propositions du genre "oui mais j'assurerai la synchronisation", on a déjà constaté que ça ne fonctionne pas.

[SpaceFox]

J'en rajoute : on avait un redmine à une époque. On a arrêté de l'utiliser le jour où on a commencé à utiliser Github. Et ce n'était pas prémédité.

[SpaceFox]

D'autre part, parlons de communication : s'il y a un problème "depuis l'ouverture du code", c'est "depuis l'ouverture du code" qu'il faut en parler.

Là, ça fait deux mois et je n'ai jamais entendu cette doléance, pas même quand j'ai relancé le sujet il y a un mois et demie.

[SpaceFox]

Je précise un truc : je n'ai rien contre JIRA ou un quelconque concurrent si ça peut améliorer notre process et notre qualité de développement.

Ce que je veux dire ici, c'est que depuis le début on se fixe sur les outils, alors que les outils ne sont clairement pas le problème : ce sont les processus. J'ai expliqué pourquoi ici et là.

Si pour améliorer ces processus on doit passer par un outil tiers, il n'y a aucun problème. Mais la réflexion doit se faire dans ce sens, sinon c'est le mur assuré.

Quand je disais le must, c'était surtout pour avoir un truc vraiment intégré au site et user-friendly. Aucun outil gratuit du marché ne permet ça.

Pourquoi pas. Mais c'est plutôt de l'intégration de solution qu'il faut faire plus que du développement ; et c'est une priorité ultra-basse.

[firm1]

Pour ma défense j'en avais parlé sur le topic de changement de bugtracker (il a malheuresement disparu depuis) et je l'ai relancé ici :)

[SpaceFox]

D'accord, je vois mieux les arguments.

Du coup reprenons : si on passe à JIRA :

1. Comment migre-ton les tickets actuels ? (Je rappelle qu'un double ticketing ne fonctionnera pas par expérience sur ce projet ; il y a 136 tickets à migrer en ne migrant que les ouverts, avec leurs discussions associées).
2. Comment peut-on faire pour les les priorité assignées soient un minimum suivies ?
3. Comment évite-t-on les erreurs de classement ?
4. Est-ce que ça peut nous aider à avancer autrement que d'un point de vue purement ticketing, par exemple en simplifiant la QA ?
5. Comment gère-t-on les tâches infra ?

Ce sont de vraies questions qui doivent trouver une réponse avant migration, pas une liste pour faire genre "je ne veux pas de Jira".

Je pars du principe que l'outil se couple déjà avec Git et le compte Github (à confirmer).

La 1. en particulier soulève un vrai problème.

PS : et du coup que devient l'outil de ticket Github ? On le vide complètement ? Il sert toujours à quelque chose ? Quoi ?

[gustavi]

J'avoue que les différentes discutions que j'avais loupés m'ont fait un peu changer d'avis.

Si JIRA apporte vraiment quelque chose pourquoi pas, ça semble beaucoup plus flexible et ça centralise un peu tout. Je pense qu'un ZdS-meeting sur l'infra et le process de dev pourrait être une bonne chose.

@SpaceFox : il existe un truc pour migrer fait par les gens de JIRA. (cf. https://www.atlassian.com/software/jira/importer-migrations#!jira-GitHub )

[firm1]

Comment migre-ton les tickets actuels ?

C'est intégré dans JIRA, on lui passe le lien projet et il migre toutes les issues actuelles. Et propose même par défaut de les ranger par priorités.

[SpaceFox]

OK, donc la contrainte technique principale est levée.

Maintenant rentrons dans le fonctionnel :

1.Concrètement, que nous apporte JIRA que Github ne nous permet pas ?

2. Quels seraient les inconvénients ? (je pense notamment à l'hébergement si ce n'est pas fourni en SaaS).

L'idée est de sortir une balance bénéfice / risques pour savoir dans quoi on se lance, pourquoi et avec quels risques et quelles difficultés. Je pense notamment face à ceci :

car aujourd'hui on utilise github assez mal et au final on s'y perd clairement dans les issues

Où l'une des solutions envisageables serait de bien utiliser Github (quoique cette expression veuille dire).

[GerardPaligot]

1.Concrètement, que nous apporte JIRA que Github ne nous permet pas ?

Prenons les fonctionnalités clés des deux plateformes.

1. Fonctionnalités de JIRA
2. Fonctionnalités de GitHub

GitHub est excellent dans la gestion d'un repo git (évidemment) au sens large (visualisation des sources, de la documentation, d'outils liés à l'intégration contenu, dans la visualisation des branches, etc.) mais sa gestion des tickets reste basique. Nous disposons d'une liste de tickets avec la possibilité d'y ajouter une milestone, une personne assignée et quelques tags. Les limites sont vite atteintes (elles le sont quasiment avec Zeste de Savoir).

Je ne connais pas toutes les possibilités de JIRA mais cet outil est destiné à la gestion des tickets et tente de le faire le mieux possible. Outre les possibilités agiles qui nous intéresse pas (moins), la gestion des tickets, des deadlines et le filtrage de ces tickets sont nettement plus avancés. Notons quand même que JIRA s'intègre avec GitHub (possibilité de lier le compte JIRA avec un repository GitHub) mais que je ne sais pas jusqu'à quel point il le permet (quid de la récupération des issues JIRA sur GitHub pour récupérer les changelogs pour chaque release ?).

1. Quels seraient les inconvénients ? (je pense notamment à l'hébergement si ce n'est pas fourni en SaaS).

Gratuit pour les projets open sources. Le Saas doit donc être disponible.

[Eskimon]

Outils ou pas, en tout cas faut pas se faire d'illusions sur ces points la:

La gestion des priorités on l'a à l'heure actuelle : bloquant, à faire bientôt, à faire si on a le temps un jour. 95% des tickets sont priorisés. Sauf que personne n'en a rien à faire (principalement parce que les trucs bloquants sont les trucs chiants). On a des QA qui n'avancent pas par manque de personnes pour faire de la QA - ce qui fout la merde dans les priorités. Le peu de personnes qui en font, font leur maximum

C'est un projet bénévole, les gens font ce qui les intéresse (normal) donc faut pas rêver, les issues chiantes resteront chiantes et resteront les dernieres corrigées...

[SpaceFox]

C'est un projet bénévole, les gens font ce qui les intéresse (normal) donc faut pas rêver, les issues chiantes resteront chiantes et resteront les dernieres corrigées...

Je suis 100% d'accord hein : on avance comme on peut. Si des gens se motivent à faire les trucs chiant, tant mieux, et je remercie grandement ces personnes ! Sinon tant pis, on ne peut obliger personne ici.

Par contre il faut bien comprendre que si ceci est vrai de fait :

On a une gestion des priorité un poil désastreuse actuellement

Aucun outil ne permettra de nous améliorer sur ce point, parce qu'on est un projet amateur. Râler sur ce point c'est donc faire du bruit pour faire du bruit, ça ne sert à rien.

[Alex-D]

Yop !

Personnellement, les seules choses que j'ai à dire sont :

• si JIRA est dans son coin sans lien avec les notifs Github, je ne les verrais clairement pas (je suis plusieurs projets sur Github, donc je passe régulièrement et j'y vois ZdS au passage)
• JIRA c'est de la belle mécanique, mais on a déjà du mal à maintenir tout le bousin avec une gestion "simple" des tickets, qu'est-ce que ça va être si on a une gestion plus poussée ? Encore une fois, est-ce qu'on a les ressources ?

C'est pas tellement de "pour ou contre JIRA", ça n'est qu'un exemple et mes deux remarques s'appliquent à n'importe quel outil similaire.

Aussi, je tiens à faire remarquer que notre problème n'est pas tellement l'organisation (puisqu'au fond, chacun fait ce qu'il a envie) mais les ressources humaines. En gros, avoir un outil génial de la mort pour 5 devs moitié actifs, c'est pas viable selon moi.

[cgabard]

Perso j'ai du mal a voir en quoi Jira reglerai quoique ce soit. Je ne pense pas que la gestion des ticket soit notre plus gros problème actuellement.

Pour les utilisateur, 90% des bugs sont rapporter sur le forum donc ça changera rien. Pour les dev je doute. Perso j'ai déjà du mal a suivre les ticket ici alors que j'utilise github quotidiennement pour le taf donc sur un service annexe il est fort probable que je n'y mette jamais les pieds.

La gestion des deadline ou ce genre de truc n'ont aucun sens pour un projet tel que le notre fait par une poignée de dev bénévole.

Du coup, quels sont les soucis réels des tickets github et que va nous apporter jira pour ça ? Car oui Jira est bien plus complet mais en a ton besoin ?

[SpaceFox]

Attention, je vais faire mon chef de projet relou dans le type d'argumentation :

Donc si je reprends vos messages et la liste des "Key Features of JIRA" et que je raye ceux dont on a pas l'utilité :

• Project Tracking
• Agile, Scrum, Kanban <-- on ne fait pas ça
• Project Planning <-- on ne planifie pas
• Issue Tracking
• Code Integration
• Service Desk
• Mobile <-- on va espérer que c'est plus complet que le mobile Github
• Custom Workflow <-- on ne va pas commencer à s'embarquer là-dedans
• OpenSocial Gadgets <-- tout est dans le nom : "gadget"
• Reporting <-- lui j'ai envie de le rayer parce qu'on en a pas besoin mais je sais qu'on l'utilisera, au moins pour faire des articles
• Connect to LDAP and Active Directory <-- pour les entreprises
• Bug Tracking
• Git Integration
• 1000's of Add-ons <-- allez, on va dire qu'on va trouver un truc cool là-dedans
• OnDemand or Hosted
• Free for Open source projects
• eMail Notifications

Il nous reste finalement des trucs évidents ("eMail Notifications") et principalement qu'on a déjà, d'une certaine manière, sous Github.

Aujourd'hui, vous ne semblez pas vraiment d'accord pour dire si oui ou non Github est vraiment le problème, ou notre manière de l'utiliser :

Les limites sont vite atteintes (elles le sont quasiment avec Zeste de Savoir).

car aujourd'hui on utilise github assez mal et au final on s'y perd clairement dans les issues

Ce que je vois en positif pour JIRA, c'est ça :

la gestion des tickets, des deadlines et le filtrage de ces tickets sont nettement plus avancés.

Sauf que là encore, concrètement je ne sais pas ce que ça nous apporte. Est-ce que ces outils plus avancés vont vraiment nous aider ou est-ce que ça va être des outils mal utilisés en plus ?

Est-ce que quelqu'un connaît JIRA assez bien pour fournir des cas concrets de comment ça pourrait nous aider ?

Sinon, est-ce que ça vaut le coût qu'on se lance dans un essai de JIRA ?

---

D'autre part :

Aussi, je tiens à faire remarquer que notre problème n'est pas tellement l'organisation (puisqu'au fond, chacun fait ce qu'il a envie) mais les ressources humaines. En gros, avoir un outil génial de la mort pour 5 devs moitié actifs, c'est pas viable selon moi.

Justement : plus on est à développer sur un projet, plus on a besoin d'organisation. 5 développeurs c'est déjà un beau projet hein. Personne ne se lance là-dedans sans aucune forme de gestion de projet. Même si les développeurs font un peu ce qu'ils veulent et sont à moitié actifs.

[GerardPaligot]

Rapidement, j'ai été voir quelques projets open-sources (Wordpress, JUnit et commons-lang) pour voir leur gestion des tickets. Aucun des trois n'utilisent la gestion des tickets de GitHub hormis JUnit pour recenser les bugs de la communauté.

Je suppose (parce que je n'ai trouvé pour aucun des trois), ils ont tous un système de ticketing à côté pour la gestion du projet.

Dans notre cas, nous avons quelques désavantages a utiliser JIRA :

• Nous allons devoir nous débarrasser de la gestion des tickets sur GitHub au profit de JIRA, il faut donc effectuer une migration des tickets (inconvénient minime puisqu'une fois que ça sera fait, il disparait) ;
• Nous serons sur 3 plateformes différentes : Zeste de Savoir (site), GitHub (code source) et JIRA (gestion de projets). Ca change les habitudes.
• Il faut donc que tous les contributeurs acceptent de se créer un compte sur JIRA.
• Dans tous les cas, si notre utilisation de JIRA sera la même que l'utilisation que nous avons de GitHub, nous aurons les mêmes problèmes que actuellement.

Je liste les désavantages mais il y a beaucoup d'avantages aussi dont les principaux sont liés à la prioritisation des tâches, les labels, renseigner la version pour le fix, les filtres des tâches pour faire apparaitre les tâches importantes ("major") aux contributeurs, etc.

Mais ...

Est-ce que ces outils plus avancés vont vraiment nous aider ou est-ce que ça va être des outils mal utilisés en plus ?

Très sincèrement, j'en sais rien. C'est quand même confortable de centraliser tout sur GitHub.

Sinon, est-ce que ça vaut le coût qu'on se lance dans un essai de JIRA ?

C'est quand même un gros investissement.

[Eskimon]

mais il y a beaucoup d'avantages aussi dont les principaux sont liés à la prioritisation des tâches, les labels, renseigner la version pour le fix, les filtres des tâches pour faire apparaitre les tâches importantes ("major") aux contributeurs, etc.

Tout cela on le fait déjà sur GH non ?

[cgabard]

Ce qui me laisse perplexe c'est que j'ai du mal a voir en quoi changer d'outil va améliorer le process actuel. La principale raison est que là tout de suite je n'arrive toujours pas a vraiment mettre le doigts sur ce qu'est le problème. Donc dire que Jira les résoudra...

On va bientôt fêter les un an du premier commit, il est peut etre temps d'organiser un débat sur le forum pour centraliser les contraintes, les problèmes, etc. Bref faire un petit bilan de notre organisation actuel.

[cgabard]

Rapidement, j'ai été voir quelques projets open-sources (Wordpress, JUnit et commons-lang)

Je ne suis pas surs que ce soit des projets comparables au notre. Entre autre parce que "Wordpress" est géré par une entreprise (ce qui du coup explique l'obligation d'avoir un vrai outils de ticket) ou "commons-lang" qui est un projet Apache et qui donc hérite automatiquement du process de l'organisation (c'est même pas une question de choix du projet). JUnit je ne connait pas assez pour juger.

[gustavi]

Notons également que WordPress c'est 23% du web. Je pense qu'on parle de choses pas comparables.

[GerardPaligot]

Tout cela on le fait déjà sur GH non ?

Tout à fait mais de manière plus chaotique. Par exemple, à mon niveau de contribution, je n'ai aucune idée de savoir comment vous renseigner les version pour les fixes dans vos issues, ni les issues prioritaires/majeures (pour l'instant, je regarde plus ou moins les bloquantes).

Ce qui me laisse perplexe c'est que j'ai du mal a voir en quoi changer d'outil va améliorer le process actuel. La principale raison est que là tout de suite je n'arrive toujours pas a vraiment mettre le doigts sur ce qu'est le problème. Donc dire que Jira les résoudra...

En fait, selon moi, le problème c'est que nos issues regroupent un peu de tout (des discussions, des suggestions, des bugs) et toutes ces issues peuvent devenir une discussion interminable ! Et là, franchement, c'est un problème. Si nous restons sur GitHub, nous devons avoir des discussions sur les forums de ZdS et ensuite, créer l'issue correspondante pour que les contributeurs sachent exactement quoi faire.

Pour l'instant, je fais un peu de QA et je zap les 3/4 parce que je n'ai pas envie de me taper 3 mois de discussion pour chaque issue.

On va bientôt fêter les un an du premier commit, il est peut etre temps d'organiser un débat sur le forum pour centraliser les contraintes, les problèmes, etc. Bref faire un petit bilan de notre organisation actuel.

Il y a un article en cours. Nous pouvons y placer des questions importantes de gestion en fin d'article et inviter la communauté à en débattre sur un topic.

Je ne suis pas surs que ce soit des projets comparables au notre. Entre autre parce que "Wordpress" est géré par une entreprise (ce qui du coup explique l'obligation d'avoir un vrai outils de ticket) ou "commons-lang" qui est un projet Apache et qui donc hérite automatiquement du process de l'organisation (c'est même pas une question de choix du projet). JUnit je ne connait pas assez pour juger.

Ce que font ces projets, je m'en tamponne un peu l'oreille. Je regarde leur gestion de projets. :)

[cgabard]

Tout à fait mais de manière plus chaotique. Par exemple, à mon niveau de contribution, je n'ai aucune idée de savoir comment vous renseigner les version pour les fixes dans vos issues, ni les issues prioritaires/majeures (pour l'instant, je regarde plus ou moins les bloquantes).

N'est ce pas juste un problème de communication interne alors ? Car si je me souvient bien, les prioritaires sont celles notés "Bloquante" et on a dit que hotfix mit a part, on ne fixait pas de millestone sur les issues car on a pas les ressources de developpeurs necessaire pour les respecter et que ça n'entraine que des retard dans la livraison des versions.

En fait, selon moi, le problème c'est que nos issues regroupent un peu de tout (des discussions, des suggestions, des bugs) et toutes ces issues peuvent devenir une discussion interminable ! Et là, franchement, c'est un problème. Si nous restons sur GitHub, nous devons avoir des discussions sur les forums de ZdS et ensuite, créer l'issue correspondante pour que les contributeurs sachent exactement quoi faire.

Pour l'instant, je fais un peu de QA et je zap les 3/4 parce que je n'ai pas envie de me taper 3 mois de discussion pour chaque issue.

Je comprend. Est ce que JIRA évitera ce phénomène ?

Il y a un article en cours. Nous pouvons y placer des questions importantes de gestion en fin d'article et inviter la communauté à en débattre sur un topic.

On peut en parler en effet ou plutot insiter les membres a venir en parler sur le forum. Car en fait ce qu'il nous faut c'est un débat pour que les dev et les membres puissent nous dire ce qui les gênent. Est ce que c'est le fait que ce soit sur un outils externe ? Est ce que le process est trop lourd ? Est ce que les gens se perdent entre le forum et les tickets ?

Ce que font ces projets, je m'en tamponne un peu l'oreille. Je regarde leur gestion de projets. :)

Pourtant pour moi c'est primordiale. Un projet géré par une entreprise a des contraintes largement différente des notres. Wordpress, doit y avoir une équipe a temps pleins qui travail dessus avec des objectifs fixés à l'avance, des bugs remontés par des entreprises cliente. Rien que pour gérer le travail des dev permanent c'est indispensable. Nous on se bat avec 4 dev qui travaillent dessus 3h par semaine. Les contraintes ne sont pas les mêmes et donc la solution retenu pour l'un n'est pas forcément celle qui conviendra à l'autre.

Mais je reste persuadé que le principal soucis actuel est qu'on a du mal a définir où est le soucis dans notre organisation et je suis loin d'etre convaincu que l'outil de gestion de ticket soit le principal point bloquant.

[GerardPaligot]

N'est ce pas juste un problème de communication interne alors ? Car si je me souvient bien, les prioritaires sont celles notés "Bloquante" et on a dit que hotfix mit a part, on ne fixait pas de millestone sur les issues car on a pas les ressources de developpeurs necessaire pour les respecter et que ça n'entraine que des retard dans la livraison des versions.

D'accord mais les bloquantes, il n'y en a pas énormément. Les centaines d'autres issues, c'est freestyle.

Je comprend. Est ce que JIRA évitera ce phénomène ?

Pas du tout. Comme je le mentionne, si nous restons sur GitHub, il faut que les choses changent en discutant sur les forums et, une fois le débat arrivé à son terme, transférer sur GitHub ou les discussions sont minimes (nous ne sommes pas à l'abris de quelques modifications à faire après coup). En fait, un système similaire aux ZEP en (beaucoup) moins lourd.

On peut en parler en effet ou plutot insiter les membres a venir en parler sur le forum. Car en fait ce qu'il nous faut c'est un débat pour que les dev et les membres puissent nous dire ce qui les gênent. Est ce que c'est le fait que ce soit sur un outils externe ? Est ce que le process est trop lourd ? Est ce que les gens se perdent entre le forum et les tickets ?

J'aime beaucoup l'idée personnellement.

Pourtant pour moi c'est primordiale. Un projet géré par une entreprise a des contraintes largement différente des notres. Wordpress, doit y avoir une équipe a temps pleins qui travail dessus avec des objectifs fixés à l'avance, des bugs remontés par des entreprises cliente. Rien que pour gérer le travail des dev permanent c'est indispensable. Nous on se bat avec 4 dev qui travaillent dessus 3h par semaine. Les contraintes ne sont pas les mêmes et donc la solution retenu pour l'un n'est pas forcément celle qui conviendra à l'autre.

Autant pour moi, je nuance : ce que font les projets, ce n'est pas important. Mais si c'est maintenu par une entreprise, bien entendu, ce n'est pas comparable.

[cgabard]

Du coup est ce que la solution que tu préconise ne serait pas de décourager (voir d'empecher ?) les gens de poster sur github et réserver ça pour les dev et de forcer tout le monde a aller sur le forum ?

Malheureusement je pense que cela ne servira pas a grand chose, ce sont surtout les dev qui discutent et ils discutent où ils voient la conversation. Ce débat serait mieux sur le forum et pour tant on le continue ici depuis pas mal de temps.

[firm1]

La discussion a pas mal avancée ici, cool. Pour moi mon avis est le suivant :

• Aujourd'hui on fais de la gestion de ticket en double. Les membres postent sur le forum, et "parfois" ces bugs son raportés sur github. La tâche de recopie sur Github représente une perte de temps non négligeable car :
  • il faut suivre des deux cotés (quand on y pense)
  • à chaque avancée du problème il faut aller sur le forum dire "issue rapportée", "pr en cours", etc.
  • retrouver les doublons fait perdre du temps aussi
• Aujourd'hui on utilise un système de tags sur github, mais les tags ne veulent juste rien dire si on n'est pas habitué du projet. On voit parfois des bloquant, on peut se poser la question, bloquant par rapport à quoi ? De même que le tag "Validation" qui n'a aucun sens quand on découvre le projet. Le tag "En cours" ne signifie pas grand chose non plus du manque de suivi après la fermeture d'une issue sur GH (c'est mergé, mais pas encore en prod, etc.). Bref, on melange déclaration du problème, gestion de la priorité et gestion de projet. Ici, JIRA nous permettrai d'établir une suite de tags qui représente le suivi du projet "bug"/"evolution" -> "en cours de résolution" -> "correction proposée" -> "en cours de QA" -> "corrigée" -> "en attente de MEP" -> "Mise en production".
• L'un des points noir de github est sa gestion des droits. On a soit beaucoup trop de droit, soit rien. Par exemple nombreux sont ceux qui ne peuvent pas s'assigner à une issue tout seuls.

Tout ceci pour dire que GH n'est pas fait pour organiser la gestion d'un projet. Les membres du site ne peuvent pas déclarer les issues directement ici car ils ne pourront jamais identifier les doublons tellement au delà de 50 issues on n'y voit plus rien. D'ou la necessité pour moi de centraliser tout ceci au sein d'un seul et même outil officiel qui permet de rapport les bugs de la communauté et aux developpeurs de pouvoir suivre et assurer un bon suivi.

Certes aujourd'hui ils y'a d'autres problèmes dans le projet, mais il y'a aussi celui là. Après le gros inconvénient que je vois à passer à une solution externe serait :

cgabard a ecrit :

Perso j'ai déjà du mal a suivre les ticket ici alors que j'utilise github quotidiennement pour le taf donc sur un service annexe il est fort probable que je n'y mette jamais les pieds.

Alex-d a écrit :

si JIRA est dans son coin sans lien avec les notifs Github, je ne les verrais clairement pas (je suis plusieurs projets sur Github, donc je passe régulièrement et j'y vois ZdS au passage)

[SpaceFox]

D'accord mais les bloquantes, il n'y en a pas énormément. Les centaines d'autres issues, c'est freestyle.

Les "bloquants", c'est les tickets qui risquent de péter un truc en prod tant qu'ils ne sont pas corrigés.

Les autres sont rangés dans des milestones qui disent en gros "ce serait cool de pas trop laisser trainer" et "franchement, ça peut attender".

Aujourd'hui on fais de la gestion de ticket en double. Les membres postent sur le forum, et "parfois" ces bugs son raportés sur github. La tâche de recopie sur Github représente une perte de temps non négligeable car :

• il faut suivre des deux cotés (quand on y pense)
• à chaque avancée du problème il faut aller sur le forum dire "issue rapportée", "pr en cours", etc.
• retrouver les doublons fait perdre du temps aussi

Ça c'est clairement un problème, prévu depuis le jour où on a décidé d'avoir ce fonctionnement. Comme prévu à l'époque, je ne touche pas à la synchro Github <---> Forums.

Aujourd'hui on utilise un système de tags sur github, mais les tags ne veulent juste rien dire si on n'est pas habitué du projet. On voit parfois des bloquant, on peut se poser la question, bloquant par rapport à quoi ? De même que le tag "Validation" qui n'a aucun sens quand on découvre le projet. Le tag "En cours" ne signifie pas grand chose non plus du manque de suivi après la fermeture d'une issue sur GH (c'est mergé, mais pas encore en prod, etc.). Bref, on melange déclaration du problème, gestion de la priorité et gestion de projet. Ici, JIRA nous permettrai d'établir une suite de tags qui représente le suivi du projet "bug"/"evolution" -> "en cours de résolution" -> "correction proposée" -> "en cours de QA" -> "corrigée" -> "en attente de MEP" -> "Mise en production".

On a un vrai problème de gestion des tags.

Typiquement, je suis DT sur ce projet, et pourtant :

• Je ne sais pas ce que signifie ce tag "Validation" (et donc je ne m'en sers pas)
• Je ne sais pas à quoi sert réellement ce tag "En cours" (et donc je ne m'en sers pas)

Il me semble que ces tags servaient avec Waffle, mais je n'ai jamais réussi à me faire à cet outil (je le trouve au moins aussi bordélique que le Github nu).

On pourrait émuler le workflow avec des tags, mais là soyons sérieux : ça ne va pas être suivi. Donc si un outil permet un vrai workflow, c'est un très bion point.

---

Pour moi une _killer-feature- de Github, c'est la possibilité de suivre et de répondre aux tickets par mail.

Sans ça, c'est à peu près sûr que je ne verrai plus passer la moitié des tickets.

[cgabard]

2014-10-21 10:36 GMT+02:00 SpaceFox notifications@github.com:

Pour moi une _killer-feature- de Github, c'est la possibilité de suivre et de répondre aux tickets par mail.

Et la deuxième est d'etre centralisé avec le code. Ça ne fait qu'un endroit a regarder.

Christophe.

[firm1]

SpaceFox a écrit

Ça c'est clairement un problème, prévu depuis le jour où on a décidé d'avoir ce fonctionnement. Comme prévu à l'époque, je ne touche pas à la synchro Github <---> Forums.

Et comme je l'avais déjà dit à l'époque c'était déjà une erreur de conserver ce fonctionnement après ouverture du code. La synchro Github <--> Forums est chiante et perso, ça fait parti des barrières à l'entrée qui font que j'ai tout de suite la flemme de proposer une PR correctrice.

SpaceFox a écrit

Il me semble que ces tags servaient avec Waffle,

Le truc c'est que les tags doivent parler à tout le monde, pas juste aux DTs ou aux habitués du projet.

SpaceFox a écrit

Pour moi une _killer-feature- de Github, c'est la possibilité de suivre et de répondre aux tickets par mail.

J'ignore si JIRA le propose dans la version gratuite pour projet opensource, mais je sais que ça existe.

[SpaceFox]

Et comme je l'avais déjà dit à l'époque c'était déjà une erreur de conserver ce fonctionnement après ouverture du code. La synchro Github <--> Forums est chiante et perso

Ah mais je suis 100% d'accord, et c'est exactement pour ça que je ne touche pas à cette synchro.

On avait conservé ce mode parce que certains s'étaient proposés pour assurer la synchro. Force est de constater que le fonctionnement prévu n'est pas effectif :(

[cgabard]

Donc le prob c'est d'avoir 2 bug tracker. Donc on fait quoi ? On vire le forum bug et suggestion ? Le 21 oct. 2014 10:54, "SpaceFox" notifications@github.com a écrit :

Et comme je l'avais déjà dit à l'époque c'était déjà une erreur de conserver ce fonctionnement après ouverture du code. La synchro Github <--> Forums est chiante et perso

Ah mais je suis 100% d'accord, et c'est exactement pour ça que je ne touche pas à cette synchro.

On avait conservé ce mode parce que certains s'étaient proposés pour assurer la synchro. Force est de constater que le fonctionnement prévu n'est pas effectif :(

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/200#issuecomment-59897708 .