L'avenir des ZEPs sur ZdS

Bonjour chers tous,

J'ouvre ce topic, pour recueillir vos points de vue sur le concept des ZEP tel qu'il est aujourd'hui mis en place sur ZdS. Pour ceux qui ne le savent pas, une ZEP est une description (spécification) d'une fonctionnalité que l'on aimerait voir apparaître sur le site. A l'origine l'idée était de s'assurer que ce qui est développé a été voulu par la communauté et que le développeur, avec un cahier de charge tout prêt, n'a plus qu'a se charger de coder ce qui est demandé. Après un peu plus d'un an, je pense qu'il est important de se poser la question de savoir si le système fonctionne, si ce n'est pas le cas, qu'est-ce qu'il faut faire ?

Si je regardes quelques chiffres, en 22 mois, concernant les ZEP de types features, on a eu :

• 41 ZEPs qui ont démarrées
• 10 ZEPs qui ont été validées
• 5 ZEPs qui sont aujourd'hui en production
• Toutes les ZEPs aujourd'hui en production, on été rédigées par quelqu'un de l'équipe des devs réguliers (la ZEP 25 sera la première ZEP dont l'auteur n'est pas dans l'équipe technique).
• 25 ZEPs sur 41 ont pour auteur un membre de l'équipe de dev
• Une ZEP, pour arriver en production nécessite en moyenne 20 pages de discussion

De mon point de vue, le constat que j'en tire est :

• L'objectif de décharger les devs de la rédaction du cahier de charge, n'est pas atteint. Au final, c'est le développeur qui s'y colle.
• L'objectif de faire participer la communauté à la spécification des fonctionnalités est sympa sur le papier, mais dans la réalité, dès qu'on rentre dans le détail il faut avoir une fibre technique pour pouvoir se rendre compte des choses.
• Le processus des ZEPs est trop lourd. Il faut rédiger la ZEP, passer du temps à expliquer le problème, à débattre des solutions, mettre à jour la ZEP pour prendre en compte les avis, faire valider la ZEP (même si on sait que finalement la ZEP se valide toujours par les devs en Zest'Meeting), tout ça AVANT de commencer à développer quelque chose. C'est beaucoup trop lourd.
• L'effet pervers est que la ZEP étant énorme, elle met du temps à se développer par 1 ou 2 personnes, les rebase sont énormes, le test de la ZEP est laborieux. Les devs qui n'ont pas participé à la ZEP prennent plus de temps à s'habituer aux nouvelles centaines de lignes de codes qui débarques, et donc seul le dev de la ZEP peut corriger un problème qui survient sur son "terrain".
• Si on continue à cet allure, on aura des ZEPs qui seront devenus obsolètes avant la fin du développement (oui je pense à la ZEP-05 par exemple).

Attention, Je sais qu'il y'a des bonnes choses qu'apportent une ZEP. Je suis conscient que le tableau que je dresse ici est plutôt sombre, mais c'est vraiment un ressenti que j'ai. Aujourd'hui à mon avis l'idée des ZEPs ça peut être super dans une entreprise, mais dans un projet comme ZdS, avec des développeurs bénévoles qui font en fonction de leur motivations/envies, le formalisme de la ZEP est plus un démotivateur qu'un truc vraiment utile.

Je pense qu'il y a des choses à changer dans nos ZEPs. J'ai pas mal de choses qui me viennent a l'esprit et quand je rassemble tout ça, le mot clé qui se dégage est : un Product Owner. Quelqu'un chargé de faire le relai entre la communauté et l'équipe de dev. Avant de détailler un peu l'idée, j'aimerai déjà avoir vos retours sur la question posée précédemment.

Merci de m'avoir lu.

Je ne suis pas sûrs que le concept soit mauvais (discuté des fonctionnalités en amont avec la communauté) mais la réalisation actuelle est mauvaise. Il faudrait des choses beaucoup plus petites et courtes. Actuellement c'est imbuvable pour tout le monde, auteur de zep (c'est une plaie à maintenir) et lecteur (20 pages à lire ne donne pas envie de participer, ni un premier message de 42km de long). Il faut selon moi garder le même principe mais :

• rendre le format/ processus moins contraignant.
• Se forcer à découper ça a la hache.

Exemple : j'ouvre un sujet pour parler d'une fonctionnalité type "des validations proches de pr à la github". On peut vite arriver au constat que la première étape est de séparer la beta du forum dans un module à part : hop une mini zep juste sur ce point. Pas besoin alors que ce soit super détaillé, de toute façon le dev devra s'adapter en fonction de ce qui est le plus simple pour lui et les changements à venir pourront changer. - ensuite le point suivant est probablement qu'il faut que le site soit capable de gérer les branches git : hop un point supplémentaire,

Etc.

En clair discuter n'est pas un mal mais il faut se forcer à garder les choses simples et petites.

Il peut en effet être intéressant de faire un point.

Avec seulement 5 ZEPs en productions, les chiffres ne semblent pas énormes. Mais il faut savoir que plusieurs arrivent, à court ou à plus long terme (ZEP-24, ZEP-25, ZEP-13, ZEP-09, ZEP-05, etc…). On compte aussi quelques ZEPs qui n'auraient pas du en être, mais ce n'est pas le soucis ici.

L'objectif de décharger les devs de la rédaction du cahier de charge, n'est pas atteint. Au final, c'est le développeur qui s'y colle.

Je suis actuellement en train de travailler sur la ZEP-09. Ce qui m'intéresse le plus est le développement. Toutes les phases de spécifications sont longues et fastidieuses pour moi. C'est pénible, mais notre fonctionnement actuel, c'est une étape obligatoire.

L'objectif de faire participer la communauté à la spécification des fonctionnalités est sympa sur le papier, mais dans la réalité, dès qu'on rentre dans le détail il faut avoir une fibre technique pour pouvoir se rendre compte des choses.

On rejoint d'ailleurs le point du dessus. Les développeurs doivent se charger de la spécification. Étant donné que nous sommes au maximum sur une philosophie « La réalisation technique ne doit pas être une limite », il pourrait être intéressant de séparer chaque ZEP en 2 étapes successives :

• Première étape : la spécification générale de la ZEP, avec la communauté ;

• Deuxième étape : la spécification technique de la ZEP.

Bien sûr, ce système ne peut pas s'appliquer à toutes les ZEPs (typiquement, les ZEPs concernant la mise en place de l'API), et il faudrait rester vigilant pendant la première étape, afin que la demande technique reste réalisable.

C'est peut-être une solution possible pour décharger les développeurs, et impliquer la communauté.

Le processus des ZEPs est trop lourd. Il faut rédiger la ZEP, passer du temps à expliquer le problème, à débattre des solutions, mettre à jour la ZEP pour prendre en compte les avis, faire valider la ZEP (même si on sait que finalement la ZEP se valide toujours par les devs en Zest'Meeting), tout ça AVANT de commencer à développer quelque chose. C'est beaucoup trop lourd.

Je suis entièrement d'accord. Le processus dans son ensemble est très long. Je me demande qu'est ce qui peut-être fait pour l’accélérer.

L'effet pervers est que la ZEP étant énorme, elle met du temps à se développer par 1 ou 2 personnes, les rebase sont énormes, le test de la ZEP est laborieux. Les devs qui n'ont pas participé à la ZEP prennent plus de temps à s'habituer aux nouvelles centaines de lignes de codes qui débarques, et donc seul le dev de la ZEP peut corriger un problème qui survient sur son "terrain".

Peut-on faire autrement ? Il faudrait, pour pallier ce problème, que toute l'équipe dev travaille en même temps sur une même ZEP. Ce serait trop contraignant. Il ne faut pas oublier que les développeurs sont des bénévoles, et qu'il choisissent donc de travailler sur ce qui les branche le plus.

Le processus des ZEPs est trop lourd. Il faut rédiger la ZEP, passer du temps à expliquer le problème, à débattre des solutions, mettre à jour la ZEP pour prendre en compte les avis, faire valider la ZEP (même si on sait que finalement la ZEP se valide toujours par les devs en Zest'Meeting), tout ça AVANT de commencer à développer quelque chose. C'est beaucoup trop lourd.

Pour ce point, je pense qu'il ne faut pas non plus omettre le fait qu'il s'agit d'une garantie que tout le monde soit sur la même longueur d'ondes et que le travail de conception soit le plus "fiable" possible, réalisé en amont. Est-ce qu'il y a moyen d'améliorer ça ? Certainement. Est-ce qu'accélérer à la volée le processus n'engendrerait pas des problèmes par la suite ? Peut-être faudrait-il repartir sur des bases nouvelles ?

Après, ouais, ça demande du temps et c'est très laborieux. Vu de l'extérieur, en tous cas. Je suis assez surpris de ne pas avoir vu quelqu'un rager dessus sur ce forum bien avant, d'ailleurs.

C'est dommage d'énoncer que le mauvais dans les ZEP. Le tableau n'est pas aussi sombre que tu le décris. D'ailleurs, nous n'avons pas 5 ZEP en production mais 8 (cf le tableau ici).

En tant qu'auteur de 2 ZEPs en production (ZEP-17 et ZEP-23) et développeurs de 3 ZEPs en production (dont une spécifiée par une personne non technique, la ZEP-24), je peux dresser un tableau des avantages d'être passé par les ZEP :

1. La ZEP-17 et ZEP-23 n'aurait jamais pu voir le jour et n'auraient pas été aussi abouties sans leurs spécifications associées. C'est réellement parce qu'il y a un échange avec les communauté et des personnes compétentes dans les API REST que j'ai pu en apprendre plus sur le sujet et passer à l'étape de réalisation.
2. La ZEP-17 et la ZEP-23 sont des "sous-ZEP" de la ZEP-02 (spécification générale des API). Un travail de découpage a été fait et il n'en tient que à l'auteur ou à la communauté de demander aux auteurs de découper certaines ZEP jugées trop conséquentes. Attention tout de même à ne pas créer trop de ZEP.
3. La ZEP-24 a été initiée par Taguan (non technique à la base et peu dans la réalisation) et la communauté a énoncé clairement ce qu'il voulait pour les notifications. La réalisation a été fait par un développeur et prouve dans un sens que le système peut marcher ! Mais il faut garder à l'esprit que ZdS est un projet open-source. Si les contributeurs n'ont pas envie de travailler sur certaines choses, rien ne peut être reproché !
4. La ZEP-24 a été réalisée en plusieurs phases qui a permit d'avoir une première contribution légère et d'ouvrir plus facilement les contributions à des développeurs externes sur la base technique réalisée. Encore une fois, le système fonctionne. La ZEP-25 a intégré le suivi des tribunes facilement (gustavi viendra me contredire si je dis des bétises mais je suis persuadé que je peux affirmer mes propos).

Donc oui, il y a des soucis de lourdeur dans le principe des ZEPs (qu'il pourrait être intéressant de résoudre) mais il y a aussi des avantages. Cela ne dépend que des auteurs des ZEP à faire les choses correctement et à l'équipe technique de les orienter s'ils éprouvent des difficultés.

En tant qu'auteur, j'ai toujours refusé de parler de la technique dans l'élaboration des spécifications. La réalisation peut légèrement différée mais les spécifications ne doivent pas toucher un mot de la technique.

Coucou,
AMHA, je suis d'accord avec firm1 sur le fait que suivre une ZEP en temps qu'externe et devoir lire plusieurs pavés sur plusieurs pages, c'est chiant.
Un systeme qui collerait aux métas-bugs ne serait pas plus approprié ? Un peu comme https://bugzilla.mozilla.org/show_bug.cgi?id=782563 par exemple (exemple au pif) ou un plus gros bug dépend de plus petit. Ça permet d'aller vers une grosse fonctionnalité via de plus petites fonctionnalités. Le problème de cette méthode, c'est que dans l'état actuel c'est plus chiant à gérer, ce n'est en rien automatique. Un des avantages, c'est que ça garde les avantages du système actuel (les statuts confirmé, en prod, etc), permet de garder l'idée d'une ZEP=une grosse fonctionnalité tout en divisant les 20 pages en plusieurs topics plus facile d'accès). Je pense que ça n'améliorera pas la vitesse de prod (et je pense que de toute façon, on a le temps).

Edit : Andr0 a posté avant que je finisse de rédiger

Exact Andr0.

Le système des ZEP est bien pensé mais mal réalisé.

En tant que dev de 2 ZEP j'ai pu m'en rendre compte à plusieurs reprises et je suis revenu de nombreuses fois sur les sujets pour pour des questions.

Les défauts que je pointe :

• Les forums c'est bien pour discuter mais ça pue pour garder un premier surjet à jour. Le système des DEP de Django via GitHub est bien plus intéressant.
• Ensuite la non technicité de certaines ZEP amènent quelques surprises lors du développement (je dois entièrement revoir les votes pour la ZEP-13 par exemple) ce qui en soit est une ZEP dans une ZEP sauf qu'on va régler le problème en 15 jours étant donné que c'est purement technique.

L'idée d'AmarOK est intéressante.

Je rajouterai que dev une ZEP n'est pas quelque chose d'évident et je suis pour découper le travail en plusieurs étapes comme l'a fait Andr0 avec la ZEP-14.

@Andr0 : relis bien mon message, je parle de 5 ZEP en production (pas en beta) de type Feature. Sinon, on est d'accord (et je l'ai précisé dans mon premier topic) qu'il y'a aussi des bon coté aux ZEPs.

Si j'en crois les premiers retours, et les +1 sur le premier message, le problème semble partagé. Par contre (et je n'avais pas réalisé cette dimension des choses) d'après Arius, vu de l'extérieur tout aussi laborieux.

Maintenant, si je regarde les solutions proposées :

• Séparer chaque ZEP en 2 étapes : je pense que ça ne ferait qu'alourdir le process et garder le coté lourd, laborieux et rebutant qui fait que finalement on a pas envie de s'y intéresser.
• rendre le format/ processus moins contraignant : +1. Je vois plusieurs formalismes qui font joli, mais au final on peut s'en passer.
  • La cartouche : à mon avis on peut la réduire à son titre tout simplement
  • Dans le cycle de vie de la ZEP, pas besoin de mêler toute la communauté au processus de rédaction. On peut tout simplement demander l'avis de la communauté (c'est là qu'intervient le product owner) sur un sujet très précis concernant une fonctionnalité à développer sur la ZEP. En gros ne faire intervenir la communauté qu'a travers des questions ou des précisions sur un sujet bien précis. Mais il faut quelqu'un pour récolter les avis, et les transmettre aux devs.
• Se forcer à découper ça a la hache :+1 aussi.

Pour répondre aux craintes d'Andr0, je suis d'accord qu'il faut des specs pour le developpeur. Mais pour que les specs soient efficaces et sans douleur pour tout le monde, il faut simplifier certaines choses.

• On aura probablement plus de personnes qui vont répondre à un sondage pour ou contre la desanonymisation des votes, plutôt que s'ils devaient lire un sujet de 20 pages dans lequel est planqué la question.
• Durant la rédaction d'une ZEP, c'est normal d'avoir des questions/interrogations, mais dans le cadre des ZEPs API par exemple, encore une fois, il y'a des choses qui étaient évidentes, et les 20% d'interrogations, peuvent passer par des questions très précises à la communauté ou (pour des questions techniques) à un panel de membres.

L'idée générale -> simplifier pour rester efficace.

Nous sommes plus ou moins d'accord. L'idée n'est pas de tuer les ZEPs parce qu'elles sont importantes mais une simplification du process ne fera que du bien.

Peut-être que ce serait plus simple en liant les ZEP à un pad. Chacun pourrait commenter, et modifier lorsque il y a accord, un bout du message principal.

Avantages,

• On peut ne s'intéresser qu'à un bout de la ZEP facilement.
• Aucun développement.
• Le message principal est maintenu à jour via un simple copier-coller.

Inconvénients,

• Ajoute encore un nouveaux canal.
• Nécessite une confiance dans les différents participants de la ZEP.
• En cas de désaccord, implique des sondages, et donc des aller et retours entre le pad et le forum (donc rapidement bordélique).
• Éventuellement perte de l'historique.

Dans le même genre (plus une différence technique qu'autre chose), faire des ZEP des articles, mettre les gens qui veulent participer comme auteur et maintenir la ZEP principale par le système de béta.

les avantages et inconvénient sont pour ainsi dire les mêmes.

Si ça facilite l'entrée dans la ZEP et la lisibilité des discussions (chaque point est discuté indépendamment dans des zones séparés), je crains que ça ne complique (encore) la gestion.

Peut-être que ce serait plus simple en liant les ZEP à un pad. Chacun pourrait commenter, et modifier lorsque il y a accord, un bout du message principal.

-> GitHub. Modification en ligne, Pull Request, etc. Voir mon message plus haut avec les DEP de Django.

Je pense qu'il faut justement ne rien imposer. Il faut injecter de la souplesse. L'auteur veut utiliser un pad ou github ? Libre à lui ! Pour moi il faut dénormaliser les zep, laisser beaucoup plus de souplesse dans le fond et la forme pour que ce soit plus fluide et adapté à chaque cas.

Tout à fait. Il y en a qui ne savent pas utiliser github (il ne faut pas l'oublier), il y en pour qui un pad suffira largement, etc.

Au final, mettre des contraintes, ne me semble pas une bonne idée.

Désolé. J'avais mal compris ton message.

+1 pour mes deux voisins du dessus. Si on veut que des membres $\lambda$ participent, il faut en tenir compte dans le choix du canal.