Dev Zone, discussions produit ou discussions techniques ?

SpaceFox a soulevé un problème tout à l'heure, et il semble important d'en discuter. Ce n'est pas un problème technique, du coup j'en parle ici, n'en débattez pas là-bas.

c'est un gros problème de Zeste de Savoir qui doit être corrigé : trop souvent, quelqu'un (ici toi, mais ça peut être n'importe qui) se réveille après la bataille alors que les discussions sont publiques et ouvertes depuis longtemps. C'est une perte de temps colossale et totalement démotivant pour ceux qui se sont bougés à faire un développement sur une base qui a déjà pris des mois de discussions en général assez stériles.

Là où nous sommes d'accord, c'est que c'est un gros problème et qu'il doit être corrigé. Certains connaissent mon point de vue sur la question mais on n'en a jamais vraiment débattu il me semble, ce sujet est là pour ça.

A mon avis, une ZEP est avant tout une décision produit. Elle concerne une (un semble de) fonctionnalités/modifications à apporter à ZdS. Le forum et le sujet de la ZEP sont là pour discuter de l'idée, pour en valider la nécessité et les détails produit. A mon sens, et c'est à contre-courant de ce qui se fait ici depuis le début, les discussions techniques et les détails d'implémentation n'ont pas leur place dans ces sujets.

Le problème évoqué par SpaceFox peut être vu de différentes manières. Fondamentalement, le problème est que les devs ne lisent pas suffisamment les ZEPs. Mais comme le dit SpaceFox, un sujet de ZEP consiste généralement en des mois de discussions en général assez stériles. Pour ma part, ces discussions ne m'intéressent généralement pas trop. J'ai rarement lu un sujet de ZEP en entier, et je suis parfois arrivé comme un cheveux sur la soupe, après la bataille, faire remarquer que ceci ou cela n'était pas top. Donc pour moi, quand on dev remarque sur le tard qu'une ZEP propose une implémentation pas top d'une feature cool, c'est pas la faute du dev qui n'a pas passé assez de temps à contribuer/lire le sujet de la ZEP, c'est la faute du système de ZEP qui engendre des discussions stériles qui n'intéressent pas un dev qui passe déjà énormément de temps à réparer des bugs, développer des fonctionnalités, améliorer la codebase, triager des tickets, etc. Je me sens pas de backlogger tous les topics de ZEP pour voir si l'implémentation proposée est ok ou pas, tout ça pour pouvoir donner un avis technique sur GitHub.

Dans mon rôle de dev pour ZdS, je fais confiance à la communauté dont je fais partie pour leurs décisions concernant le produit ZdS. Les fonctionnalités du site, etc. Et je trouve très inefficace de mélanger ces discussions produit avec des discussions techniques dans ces sujets. Je suis prêt à participer à la discussion d'une ZEP, ou à la discussion de l'implémentation d'une ZEP. Je suis pas prêt à participer à un brouhaha que certains qualifient de "stérile".

Je ne suis pas certain d'avoir la solution à ce problème, mais je suis partisan de séparer les discussions techniques et les discussions produit. Ainsi, discuter de comment implémenter une ZEP pourra suggérer des modifications à la ZEP : si on ajoute ça ici, ajoutons-le aussi là ? Et ça c'est pas trop faisable pour les raisons suivantes. Ça demandera un peu plus de discipline, mais je pense qu'on serait gagnant. On établirait donc un cahier des charges produit soumis à la validation de la communauté et un cahier des charges technique soumis à la validation des devs, en lieu et place du joyeux mélange actuel.

Pour revenir à l'exemple de la ZEP 11, firm1 a fait un travail formidable et parcourir quelques pages du sujet initial montre que les discussions étaient généralement productives. Par contre lire la "spécification" n'est pas assez compréhensible, ni en terme de fonctionnalités ni en terme technique. On y comprend vaguement que seul l'auteur aura accès à ses propres statistiques, mais on ne parle pas de ces restrictions dans l'API ? Le schéma d'architecture parle de stocker ça en NoSQL puis on parle de SQL ? Le sondage sur les infos à récolter ne correspond pas à l'implémentation ?

Je crois vraiment qu'on serait gagnant, avec cette ZEP pour exemple, à avoir d'abord une discussion : "Est-ce qu'on veut des stats ? Qui y auront accès ? Quelles infos pourra-t-on y trouver ? Etc", et une discussion séparée "Comment on fait ça ? On parse les logs en batch ou on fait ça en live ? Si on fait ça en live, sync on async ? Etc"

Vos avis et propositions sont les bienvenus, merci d'avance !

Je pense que la clé du problème vient à la fois de l’état d’esprit des participants que de la manière dont est fait la délibération. J’ai participé à de nombreuses associations et autres évènements qui demandent de prendre des décisions. Voici quelques pistes de réflexions, des points à prendre conscience.

Avant de passer à l’action, il faut une unité de but et de vision. Par unité de but, c’est en gros « ce que l’on veut », qu’il faudra définir clairement, et l’unité de vision, c’est-à-dire comment on y arrive. Bien sûr, autant l’unité de but est facilement définissable, autant l'unité de vision est changeante aux gré des apprentissage (on peut faire tel chose techniquement ou pas typiquement).

Pour y arriver, et notamment dans nos discussion, il faut changer notre état d’esprit, et ne pas être dans la confrontation. Ainsi, il faut rester humble : on n’exprime la réalité telle qu'on la perçoit, et donc qu'une facette du problème. Mais c'est justement en mettant bout à bout les différentes facettes qu'on arrivera à voir la globalité.

Je pourrais développer un peu plus au besoin si vous souhaitez. Pas de solution « clé en main », mais simplement des retours d’expérience que j’ai eu

Si je comprends bien, tu reproches aux ZEP d'avoir la double fonction de définir le but et le moyen.

Si c'est ça, les ZEP peuvent théoriquement répondre à tes besoins. Il suffit de scinder la phase rédaction en deux parties. À un moment donné, on fige la partie produit de la ZEP et on passe exclusivement à la partie technique. Associé à un changement de tag et à une mise à jour du sujet récapitulatif, est-ce que ça répondrai aux besoins ?

Je vais apporter mon retour suite à mon expérience personnelle sur les ZEP 25 et 13 que j'ai dev. Je suis entièrement d'accord avec ce qu'à dit victor plus haut à savoir que les ZEP sont faite par la communauté pour un besoin spécifique mais le cahier des charges d'un point de vue technique est laborieux (modulo quelques ZEP dont celles des API). Personnellement j'ai du lire que 20% de ce qui s'est dit dans les 4x ZEP que nous avons pour plusieurs raisons : sujets peu intéressants, longs débats fucking useless ou tout simplement manque de temps (suivre des débats interminable ou coder, on ne peut pas tout faire).

J'ai vu passer des choses niveau dev qui auraient pu être bien mieux et les ZEP ne font pas exception. Je vois deux solutions, aucune n'étant parfaite : avoir un cahier des charges très précis afin de mettre tout le monde d'accord quitte à rentrer dans des détails que seuls des devs du site peuvent comprendre ou alors faire les ZEP petit à petit avec une vérification ou un accompagnement d'un ou plusieurs devs afin d'éviter les choses bof bof.

Ce ne sont que des pistes de réflexion mais un débat technique sur l'implémentation est nécessaire. Plusieurs fois je me suis posé la question comment je vais faire ce truc ? (cf le sujet de la ZEP-13) et je pense que je ne suis pas le seul.

Pour réagir à ce qu'à dit qwerty je pense que la vision des choses, du moins d'un point de vu fonctionnalité, est assez générale mais que les divergence peuvent plutôt apparaître d'un point de vu technique.

Gabbro : oui c'est ça. Peu de ZEP parlent de technique et c'est là le problème.

*au topic de ZEP, en fait.

Se taper 12 pages de débat (débat intelligent ou pas, en l'occurrence souvent pas il semblerait) pour comprendre les détails des fonctionnalités d'une ZEP et comment les gens envisagent de l'implémenter, c'est une pure perte de temps.

Quand une ZEP est validée, on pourrait en rester là jusqu'à ce que quelqu'un décide de l'implémenter ? Cette personne pourrait ensuite proposer sa vision technique de l'implémentation et ouvrir le débat à ce sujet ? Ça éviterait probablement de noyer le poisson. On pourrait faire ça par le biais d'un ticket Feedback sur GitHub.

Vos avis et propositions sont les bienvenus, merci d'avance !

Personnellement, je trouve (et je ne suis pas le seul) que les ZEPs dans leur état actuellement sont contre productives.

Je suis totalement d'accord avec le PO sur le fait que la communauté devrait se contenter de définir le produit, et laisser aux développeurs la charge de proposer une implémentation technique.

La ZEP 11 typiquement avait été spécifiée dans tout les sens. La phase de spécification a été un cauchemar magique que je n'ai guère envie de renouveler.

Pour ce qui est du comment améliorer ça, j'avais dans le sujet sur l'avenir des ZEP proposé qu'il y ait une sorte de product owner (en fait pour moi le CDP peut cumuler ça) qui est chargé de spécifier le produit avec la communauté. C'est lui qui doit poser les questions à la communauté sur les éléments du produit sur lequel un dev à un doute (est-ce qu'on parle de tribunes libres ou de billet ? est-ce que les auteurs sont intéressés par le temps de chargement de leurs tutoriels ? est-ce que le membre du conseil de ZdS veulent pouvoir rechercher dans leurs forum ? etc.).

Voilà mon point de vue sur la discussion.

Les ZEPs sont contre productives c'est une certitude, du point de vue de la communauté qui n'arrive pas à y participer sans devoir lire 30 pages de débats par peur de répéter quelque chose, et aussi du point de vue des dev qui doivent gérer les choix de la communauté et leur implémentation. (je crois que je ne vous apprend rien c'est pour cela qu'on en est là).

Je propose de travailler sur un nouveau système de ZEP, divisant comme proposé, les discussion "produit" des discussions "dev".

Je propose donc d'utiliser les tribunes libres (ou même les articles en faisant en sorte qu'ils s'affichent séparément sur la page d’accueil) pour les discussions produits, ainsi elle pourront être présentée sous un format accessible à tous les membres mais qui pourrons discuter dans l'espace commentaire, comme sur le forum. L'avantage est que l'on libère la Dev Zone aux discussions "dev" (le nom de la catégorie du forum prenant alors tout son sens).

Le cycle de vie serait le même à la différence près que lorsqu'une ZEP est validé, sa spec "produit" est déclaré bloquée afin de commencer le développement à partir des discussions "dev".

Il me semble que ça s'apparente à ce que je proposais ici. Sans aller nécessairement jusqu'à la création d'un forum.

Je suis d'accord sur le principe (les ZEPs sont contre-productives), mais pas forcément sur la résolution. Si j'ai bien compris, on propose de séparer les suggestions de l'implémentation. Pour moi, c'est pas forcément ça qui va régler le problème:

• Il n'y a pas besoin de faire intervenir la technique pour qu'une ZEP devienne "pénible". Les ZEPs comme la 4 (page d’accueil) on généré un torrent de discussion non pas sur l'implémentation mais sur la place et la position des éléments. Donc sans entrer dans le détail technique. Je ne pense pas que cette séparation va régler le problème, malheureusement. Pour la ZEP-12, ça c'est passé en 2 topics justement, celui de la ZEP principale et justement un topic plus technique, mais j'ai pas eu l'impression que c'était mieux.
• Des suggestions, il y en a plein. Comment séparer une suggestion lambda d'une ZEP ? Ou mettre la séparation ? Quel serait l'intérêt d'une ZEP si c'est juste une suggestion "améliorée" (comprendre que la personne y a un peu plus réfléchi que juste "je veux ça", en disant "on ferait bien comme ça" ?)
• Qu'est ce qui empêche la communauté de participer aux débats techniques ? On scinde la discussion, certes, mais la discussion technique devra avoir lieu un jour ou l'autre, si ce n'est sur la ZEP au moment ou le dev' se renseigne sur le choix la techno ou "plus grave" selon moi, au moment ou il propose sa première PR ? Au delà des "guerres de religion", comme je les appelle ("cette techno là est mieux"), si un membre est motivé, il participera de toute façon à la discussion "technique" et générera 10 pages de topics.
• Il faut aussi pouvoir évaluer ce qui est irréalisable. Si un membre arrive avec une idée qui est techniquement infaisable, un dev' va forcément lui répondre avec des arguments techniques, auquel le membre va lui répondre par des arguments techniques et ainsi de suite. On ne peut rien faire contre ça, je pense.
• Les dev's ne savent pas s'en empêcher. Typiquement, la ZEP-11, c'est en partie ça : on répète "on cause pas technique" à longueur de temps, puis on en vient à comparer les technos pour lire les logs et les stocker. Et en plus, les dev's sont les premiers à lancer le débat technique (c'est pas contre Kje, c'est juste que c'est l'exemple que j'avais sous la main, mais vous remarquerez qu'on dérape dès la deuxième page du topic après quelques messages sur les acronymes).

Donc plus qu'une séparation technique/produit, je pense qu'il faudrait commencer par redéfinir ce qu'on fait exactement dans une ZEP, dans quel sens (parce que la discussion technique doit avoir lieu) et éventuellement modérer un peu le cas échéant. On pourrait par exemple dire qu'une ZEP se déroule en plusieurs phases, genre "l'idée" (je veux ça), "la mise en place" (je pense que ça prendrait cette forme là) puis "la technique" (on va faire comme ça) "l'implémentation" (un dev' s'y colle) et "le test" (la PR est prête/mergée). Et par exemple, on empêche quiconque de dire quoi que ce soit de technique avant la phase 3 (à coup de modération s'il le faut, sauf que cette modération devrait probablement être faite par le CdP).

… Sauf que ça va pas régler le problème des 10 pages de topics (qui est inhérent à ZdS ou le mot "démocratie" est quand même une valeur importante). Du coup, il faudrait mettre en place autre chose. Des retours plus réguliers, peut-être (avec une liste des "messages-clés" dans la discussion) ? Des sortes de rapports ? (éventuellement à la fin de chaque phase que j'ai cité ci-dessus, mais pas seulement avec "on va faire ça", mais "on a discuté de ça, ça et ça, et on a finalement choisi ça") ? Des diffs pour qu'on puisse suivre plus simplement l'avancement ? Évidement, c'est très contraignant :/

Finalement, je pense que l'option "suivre un forum" qui est pour le moment en bêta va améliorer les choses. Éventuelement encore plus avec un forum "ZEP" évidement, mais suivre le forum "bugs et suggestions" me semble un must do pour les dev's

EDIT: je suis pour l'idée d'utiliser les tribunes libres pour ça, modulo un ou deux aménagements. Par exemple, il faudrait probabement la fonction "diff" accessible à un lecteur lambda (pour suivre les changements). Techniquement, on ne peut pas mettre une tribune en bêta (ceci dit, ce ne serait pas dans le bon forum), ce qui est "dommage" pour la discussion (un contenu étant automatiquement lié à un topic, et les màj appariassent directement sur celui-ci). Et il faudrait aussi que la tribune ne deviennent pas un article par erreur de manipulation (je me souviens qu'à un point, on avait dit qu'une tribune devenait un article après $x$ votes positifs, ce serait dommage que ça arrive pour une ZEP).

Il mes semble que le suivi des forums est prod depuis la v19 déjà.

Sinon, je te rejoins aussi quand tu dis que l'on ne peut pas s’empêcher de parler technique dans les ZEP (peut-être parce qu'on a une communauté très technique). Et je plussoie encore la notion de modération des ZEP (voire ds débats interminables sur ZdS) par le CdP. Celui qui essaye de guider la discussion pour faire préciser certains points à la communauté et que les besoins soient identifiés.

Par contre je doute de la pertinence d'un forum ZEP. C'est dommage que l'on travaille toujours avec Github qui ne permet pas d'organiser simplement les discussions autour d'une fonctionnalité mais d'un point de vue technique.

Si tu veux éviter une discussion de 10 pages, il n'y a pas 36 solutions. Soit tu l'interdis, soit tu la tues dans l'œuf.

Pour les presse-agrumes¹, je suis parti d'une idée qui plaisait, et plutôt que de lancer un débat sans fin sur les modalités d'élection, le nom ou que-sais-je, j'ai proposé une forme arbitraire et évité la discussion en disant que c'était pour tester (en disant explicitement que je voulais éviter les discussions de trois plombes – je ne trompe personne). Sur le sujet des candidatures, je n'ai eu que deux retours classables comme discussion (sur la durée de l'expérimentation et sur le nom – fort heureusement n'ayant pas engendré de retours particulier).

C'est peut-être la chose à faire. Une fois l'idée fixée, les grandes lignes acceptées, on fige, on fait un test. La discussion est évitée, mais pas la collaboration, car la communauté intervient non seulement dans la définition des grandes lignes, mais aussi lors des retours pour l'amélioration. Bref, faire de manière itérative. La discussion technique aurait, elle, lieu sur la plateforme technique.

Ce n'est pas forcement applicable à tous les changements, mais c'est à envisager.

Il mes semble que le suivi des forums est prod depuis la v19 déjà.

Toutafé, je sais pas pourquoi je l'avais pas encore vu.

Par contre je doute de la pertinence d'un forum ZEP.

Je suis partagé. D'un coté, je me dis que ça permettrai une meilleure "visibilité", dans le sens ou on sais que les ZEPs sont là (pour le moment, il faut les rappeler avec les tags). De l'autre, couper ça du forum "bugs et suggestions" ne va peut être pas aider à rameuter du monde.

Si tu veux éviter une discussion de 10 pages, il n'y a pas 36 solutions. Soit tu l'interdis, soit tu la tues dans l'œuf.

Autant je suis d'accord, autant je sais très bien que c'est mal vu sur ZdS

Pour les presse-agrumes[^jeu], je suis parti d'une idée qui plaisait, et plutôt que de lancer un débat sans fin sur les modalités d'élection, le nom ou que-sais-je, j'ai proposé une forme arbitraire et évité la discussion en disant que c'était pour tester (en disant explicitement que je voulais éviter les discussions de trois plombes – je ne trompe personne). Sur le sujet des candidatures, je n'ai eu que deux retours classables comme discussion (sur la durée de l'expérimentation et sur le nom – fort heureusement n'ayant pas engendré de retours particulier).

Je ne généraliserai pas trop vite, mais de toute façon, c'est vers ça qu'il faudrait probablement tendre dasn une certaine mesure. Ceux qui veulent chicaner le feront de toute façon quoiqu'il arrive, et la meilleure manière de l'éviter, c'est probablement comme tu dis "arriver avec une idée toute faites", autrement dit y avoir déjà réfléchi avant. C'est peut être une piste à explorer, "demander plus de recherche avant de créer une ZEP".

C'est ce qui avait été fait pour la page d’accueil, avec les résultats qu'on connait. Après, on s'y est peut être mal pris et il faudrait ce retaper tout le sujet pour voir comment améliorer les choses.

C'est systématiquement l'inverse qui est appliqué actuellement : dès qu'un débat apparaît, il est reporté ici pour que "le plus grand nombre puisse en profiter". Je défend ce point de vue, parce que je trouve que GitHub est pas très adapté aux débats (mais ce n'est que mon avis) et aussi parce que comme l'as souligné Firm1, c'est pas la plateforme la plus adaptée pour faire autre chose que maintenir une liste de problème et les régler. Même si je regrette qu'on ne puisse pas le faire sur GH, je trouve qu'on est mieux ici.

Salut,

Je viens moi aussi mettre mon grain de sel dans cette histoire, d'autant plus que mon rôle est cité plusieurs fois.

Tout le monde semble unanime pour dire que le principe derrière les ZEPs, c'est bien, mais que sa réalisation laisse à désirer à cause de la lourdeur de son processus. Je ne peux que le confirmer puisque, aujourd'hui, les contributeurs techniques évitent le plus possible de créer et/ou contribuer à une ZEP à cause de cette lourdeur et des débats qu'ils vont devoir gérer. On en arrive même au point où certains contributeurs laissent discuter la communauté (parfois dans des débats interminables) tout en sachant que sa réalisation technique ne viendra jamais. Mais pour le signaler, il faut rentrer dans les débats, donner des raisons techniques, expliquer le désintéressement des contributeurs techniques, etc.

En conclusion, les ZEP ont bien fonctionné au lancement du site (même après, certaines ZEPs ont été plus que bénéfique au site) mais c'est rapidement devenu lourd.

Parmi les pistes proposées ici, avoir un garde fou (un product owner, parfois vu comme le chef de projet) et un découpage en phase des ZEPs (dans des sujets séparés ou non) semblent revenir le plus souvent. Je suis assez d'accord avec cette direction mais comme le dit très justement pierre_24, nous ne pouvons pas totalement empêcher les grosses discussions ou les interventions techniques dans les discussions produits (et inversement !). Le garde fou peut calmer les choses mais pas totalement y remédier et tout ceci fonctionnera le temps que le garde fou fait son boulot. Dans la mesure où cette/ces personne(s) sont des bénévoles, c'est difficile de rester rigoureux sur le long terme, sans parler des moments d'indisponibilité.

Ce que j'aimerais proposer moi découle de mon expérience personnelle dans la réalisation des ZEP, plus particulièrement de la ZEP-24. Pour rappel, la ZEP-24 concerne le centre de notifications, est à l'initiative de Taguan et a été réalisée d'abord par Taguan, puis par moi. De mon point de vue, cette ZEP a vraiment bien fonctionné parce que j'ai fais un boulot de découpage. Pas sur les discussions produits et techniques mais en découpant sa réalisation par étape. J'aimerais simplement étendre la chose un peu plus loin pour commencer dès la création de la ZEP.

Pour faire simple, une ZEP expliquerait la fonctionnalité voulue, comme le fait un peu toutes les ZEPs aujourd'hui, mais en restant que sur des descriptions fonctionnelles. Puis, l'auteur ferait un découpage en identifiant les prérequis et les étapes pour parvenir à la réalisation de la ZEP et chacune de ces étapes ferait l'objet d'une validation ; c'est-à-dire une discussion technique sur l'étape en cours, puis une validation fonctionnelle et technique et finalement sa réalisation avant de discuter de l'étape suivante. Ainsi,

• on se dirigerait plus vers une approche dite agile, donc itérative.
• on aurait des débats moins important puisque les fonctionnalités seront plus petites.
• on peut imaginer des résumés à la fin de chaque étape avec des liens au premier message.
• on motiverait les gens à contribuer puisque le processus serait bien moins lourd.

Qu'est ce que vous en pensez ?

J'aimerais aussi discuter du rôle du CdP mais il faudrait sans doute d'abord se fixer sur le nouveau format des ZEPs puis discuter des nouveaux rôles potentiels dans un sujet dédié à ça.

Je pense que c'est une nécessité vu nos idées de modifications. Une sorte de ZEP-01b. Mais dans ce cas, comment gérera t'on les ZEPs qui obéissent à l'ancienne ZEP-01 ?

Je suis entièrement d'accord avec ce qu'à dit Andr0 sur le fait de découper la réalisation en plusieurs petites étapes, c'est également ce que j'ai essayé de faire avec la ZEP-13 et c'est bien plus efficace.

Une idée que j'avais déjà évoquée dans des discussions précédentes pour gérer les spécifications techniques des ZEP : GitHub. Je m'explique.

Aujourd'hui le forum c'est bien pour avoir un discussion linéaire et pour des débats qui n'intéressent pas toujours les développeurs (personnellement, savoir s'il y a 3 ou 4 articles sur la page d'accueil ça m'en bouge une sans remuer l'autre). En revanche ce qui nous intéresse c'est de savoir techniquement comment vont être faites les choses. Des exemples en vrac : savoir quels seront les modèles pour la BDD et les relations entre, savoir si l'API va être utilisée et comment, savoir si une fonctionnalité magique de Django permet de faire les choses facilement, etc. Bref, tout un tas de choses qui ne concernent quasiment que les développeurs et qui sont vraiment importantes pour ne pas faire n'importe quoi et se retrouver dans l'avenir avec un sujet comme celui-ci. Je pense qu'on est tous d'accord qu'il faut séparer les discussions sur la fonctionnalité et les discussions sur son implémentation.

Comment on procéderai avec GitHub ? Tout simplement avec un repo dédié et un système de PR pour valider les spécifications des ZEP. Une PR = une proposition de ZEP, une fois qu'on l'accepte (voire une validation partielle) on la merge.

C'est un système cool car :

• On peut facilement commenter des morceaux de la ZEP car la discussion n'est pas linéaire comme dans un forum. Les discussions seraient ciblées sur une partie donnée et ça éviterai de s'y perdre.
• On peut aussi utiliser le système de +/- facilement pour donner son avis (sur le forum aussi, certes, mais au moins on ne perd pas àa).
• On peut proposer des modifications avec des PR, avoir un VRAI historique des modifications qui ont été faites.
• Ce système existe déjà.

Voilà, c'est une idée qui permettrai de résoudre ce problème de discussions techniques. Qu'en pensez vous ?

EDIT : quand je parle de repo dédié pour les ZEP je parle d'un repo pour la spécification et non la ZEP en elle-même (à ne pas confondre avec ce qui c'est fait lors de la réalisation de la ZEP-12).

gustavi, j'ai eu l'exacte même idée tout à l'heure mais je pouvais pas poster.

Je te rejoins sur l'aspect non linéaire des discussions et sur les réactions aux messages.

C'est chouette parce qu'on a un diff et donc qu'on peut facilement retrouver la raison d'une décision ou constater que c'est juste passé sans commentaire. Aussi, avec une PR, on peut commenter le diff, et quand un truc est pris en compte par l'auteur, le commentaire se cache (mais reste accessible), ce qui rend la prise en compte d'une modification très aisée pour les relecteurs.

Je suis largement en faveur d'un repo ZEP.

Pour préciser mon propos et parce que Andr0 et Situphen sont passé sur IRC quand je mangeais : ce que je propose est uniquement une spécification technique faite PAR les dev et POUR les dev. Si le membre foo veut venir aider à spécifier une ZEP d'un point de vue technique je pense que créer un compte GitHub devrait être à sa portée, surtout qu'il en a déjà très probablement un. Ensuite je rappelle qu'on peut faire toutes les modifications (commits, PR et autre) directement via GH. Enfin bon, je pense que quelqu'un qui à les connaissances pour spécifier techniquement une ZEP maîtrise un minimum git, si ce n'est pas le cas ça ne lui fera pas de mal d'apprendre à utiliser l'outil.

À terme, pour moi on devrait spécifier les ZEP uniquement sur GitHub car les forums puent à ce niveau. Ça reste un autre débat.

Pour moi au contraire c'est pas un autre débat, c'est exactement le débat de ce topic : comment fait-on pour rendre les ZEP plus pratiques ?

Je pense qu'avoir la spécification produit et la spécification technique dans un repo zds/zep serait nettement mieux, je pense pas qu'on peut s'en sortir à jongler entre les deux plateformes. Il y a une forte corrélation entre spec technique et spec produit, elles s'influencent l'une l'autre assez tôt et jusqu'à la fin de l'implémentation.

Je pense aussi que montrer à plus de gens que s'ils veulent contribuer à la plateforme ZdS et pas seulement à son contenu c'est possible-c'est sur github-c'est ouvert-ça fait pas peur, ce serait pas un mal. J'ai bien l'impression que par rapport au nombre de personnes ici qui pourraient contribuer à la plateforme technique, le nombre de personnes qui participent vraiment* est très bas. Il y a clairement des choses à améliorer de notre côté, par exemple rendre l'installation locale de ZdS potable. Mais y'a aussi clairement un effort à faire pour montrer que github fait pas peur, python non plus, et l'open source non plus.

* Je parle pas forcément de développer pour la plateforme. Je parle par exemple d'ouvrir une issue, mettre un +1 sur une PR, etc. Des trucs plus utiles à ZdS que 10 pages de discussion sur le forum.

Je ne suis pas certain de comprendre ce qui est voulu ici quand on parle de faire une spécification technique dans un repo dédié aux ZEP.

De mon point de vue, on rajoute une n-ième étape (spécifier techniquement la solution) entre la spécification du produit et le développement de la solution. Une étape de plus par laquelle le dev doit passer avant de commencer le dev. Je ne sais pas pour vous, mais ça me donne l'impression d'écrire la documentation de mon produit avant de commencer à coder. Et on sait très bien que le code, à la fin ne ressemble jamais à ce qu'on avait en tête au départ. Ce qui nous obligera à modifier la spec technique pour rester cohérent, etc.

Perso, dans l'idée, ça reste toujours lourd.

@firm1, y'a deux options à mes yeux, soit on fait un repo zds/zep pour les specs techniques et donc on précise environ comment implémenter une spec produit, sont on fait un repo zds/zep pour les zeps donc specs produit et techniques.

J'opterais pour la seconde option.

Par rapport à l'argument d'ajouter une Nème étape entre la spec produit et son implémentation, je tempérerais un peu ton propos. Je pense que pour la personne qui implémente une spec produit, expliquer au préalable l'approche qu'il adoptera est en tous points bénéfiques. Il s'agit pas de dire "dans ce fichier je ferai ça, dans celui-ci j'ajouterai ça", etc. Il s'agit de dire "je compte utiliser tels trucs et faire ceci comme ça". Dans les grandes lignes. Le travail technique sur ZdS est un travail d'équipe. Je pense qu'expliquer au préalable comment on implémentera une ZEP est bénéfique pour tout le monde : pour la personne qui implémente parce que ça la force à tirer au clair ses idées, pour la personne qui implémente parce que les autres devs pourront valider l'approche ou proposer de meilleures pistes, pour les autres devs parce qu'ils sauront ce qui arrive et pourront planifier en conséquence. Et évidemment aussi parce que si la personne qui implémente la ZEP choisit une route qui n'est pas privilégiée, le temps perdu à l'implémenter et finalement proposer une PR est généralement largement évitable par l'ouverture d'une discussion au sujet de l'implémentation.

Les devs actuels ont une réactivité assez exemplaire je trouve. On le voit quand quelqu'un ouvre une PR WIP et demande du feedback. Si la même chose se reporte sur les discussions d'implémentation, cette proposition n'augure qu'une amélioration de la situation actuelle.

1. On ouvre une PR créant un fichier contenant une spécification technique sommaire.
2. Les devs commentent.
3. Au fur et à mesure que les commentaires justifiés sont pris en compte, l'auteur de la PR met à jour sa PR et donc "cache" les commentaires.
4. Quand y'a plus rien d'important à discuter, la PR est mergée et devient donc un fichier genre zds/zep/zep-acceptée/19-bouton-admin-autodestroy.md sur le repo, c'est parti.

Evidemment rien n'empêche la personne qui implémente de commencer son travail d'implémentation avant. Seulement, si son implémentation a besoin d'une grosse révision avant merge et que la personne n'a pas suivit le processus avant, personne va être désolé de dire que c'est pas mergeable en l'état.