ZEP-01 : Rôle et fonctionnement des ZEP

Serait-il possible d'inclure la liste suivante dans le premier message afin qu'on puisse s'y retrouver plus simplement ?

Actives :

• ZEP-01 : Rôle et fonctionnement des ZEPs.

En test :

• ZEP-03 : Page résumant les tutos en rédaction.

Acceptées :

• ZEP-05 : Refonte du traitement markdown pour l'export.
• ZEP-12 : Refonte du principe des tutoriels et articles.
• ZEP-17 : Elaboration de l'API des membres.

En rédaction :

• ZEP-02 : Elaboration d'une API.
• ZEP-04 : Nouvelle page d'accueil !
• ZEP-06 : Favoris et autres suivi d'activité.
• ZEP-07 : Champs personnalisés dans le profil.
• ZEP-08 : Utilisation de git pour gérer les tutos et articles.
• ZEP-09 : Sondages.
• ZEP-10 : Module d'exercices.
• ZEP-11 : Interface de statistiques sur les tutoriels.
• ZEP-13 : Tribune libre.
• ZEP-14 : Refonte de l'assistant d'édition Markdown.
• ZEP-15 : Navigation à facettes à travers le site.
• ZEP-16 : Page de proposition de corrections.
• ZEP-18 : Amélioration de l'ergonomie de validation.
• ZEP-19 : Page des requêtes de tutoriels.
• ZEP-20 : Relecture des tutos par les pairs.
• ZEP-21 : Refonte de l'interface des messages privés.

Cette liste est normalement automatique et à jour.

Exact. Rajouter ce lien dans le premier message alors, pour les peu dégourdis comme moi ?

Pour moi ce n'est pas le rôle de cette ZEP que de référencer les autres. En particulier, mettre une liste manuelle c'est s'engager à la maintenir (ce que personne ne voudra faire manuellement) et ça me semble philosophiquement bancal de reposer sur une feature du site (page de recherche par tags) dans la première zep.

Je suis d'accord qu'il faudrait trouver une solution, mais les deux énoncées ici ne sont pas correctes à mon sens : en fait, pour bien faire il faudrait faire un module du site dédié aux zeps, à inclure potentiellement comme un contenu (comme les articles et tutos).

PS : en ce qui concerne les termes "process" et "feature", j'ai repris directement la terminologie des PEP sans trop y penser. C'est vraiment gênant ?

Étant donné que ce sont des termes plus que courant en info, je ne pense pas, mais il y a des défenseurs du français en toute circonstance. Je pense que pour l'un ou l'autre, tant que tout le monde comprend, ça ne sert à rien de pinailler sur un mot.

Disons que ça fait un peu cheveu sur la soupe… C'est la seule partie de la ZEP qui est en anglais, et tu utilises les termes français dans la même phrase : ça fait con.

D'un autre côté, on peut opposer à cela que l'acronyme ZEP (ZDS Enhancement Proposal) est lui-même en anglais. Si on tient à rester vraiment francophone, on devrait les appeler des PAZ (Proposition d'Amélioration pour ZDS)…

Ça rejoint surtout le topic de firm1 sur le besoin urgent d'outils de gestion de projet / travail collaboratif / redmine / jira / whatever.

Y'a 22 ZEP en cours, j'ai l'impression qu'on va pas tarder à en arriver au point ou c'est plus possible à suivre correctement/manuellement.

On va s'y perdre, certaines sont quasi à l'abandon, on ne sait pas trop pourquoi ni comment la relancer. Ça serait vraiment top de pouvoir suivre l'avancement plus facilement.

A ce propos, je suggère qu'on ajoute un tag "En développement" afin de différencier les ZEPs validées mais abandonnées (donc simplement en attente d'un dev) de celles prises en charge. Actuellement, on n'a que "Acceptée".

Si elle est acceptée mais pas active c'est qu'elle est en développement non ?

Pas nécessairement : si elle est acceptée, c'est que le staff a dit banco, il n'y a pas forcément de dev qui travaille dessus pour autant.

Oui, active signifie en prod.

D'ailleurs, la ZEP-03 est en test. Peut-être serait-il judicieux d'ajouter cet état dans le premier message et de le spécifier un peu plus : quand passe-t-on de en test à active ? Qu'est-ce que ça implique ?

En somme, on aurait :

• Rédaction : la ZEP est en cours de spécification
• Acceptée : la ZEP a été validée (par ceux "faisant autorité pour valider la ZEP" : c'est qui ?). En attente d'une équipe de développeurs.
• Refusée : la ZEP a été refusée, définitivement (par ceux "faisant autorité pour valider la ZEP")
• En développement : une équipe de devs codent la ZEP.
• En test : la ZEP a été poussée en prod. Phase de test. Demande de retours de la part des utilisateurs : bugs, améliorations… ?
• Active : les bugs ont été corrigés et la ZEP ne bougera plus, sauf en cas d'évolution ?

Non, non, non.

"En test" et "En développement" n'ont rien à faire là : une ZEP est une spec, pas un ticket.

Quel est le rôle de "Active" ?

Une fois qu'une ZEP est acceptée, et que la proposition qu'elle contient est mise en application ou implémentée puis poussée en production, la ZEP prend le statut Active.

Ca n'explique pas à quoi ça sert.

Si j'ai bien compris, quand la ZEP est en production pour une feature ou quand la spécification a été implémentée dans le cas d'un process.

C'est juste, mais pourquoi faire ça alors qu'on ne renseigne pas "En test" ou "En dev" ?

Le rôle des ZEP est de séparer le développement de la théorie. On peut décrire l'aspect technique (comme on voit dans la ZEP 17, sur le formatage des erreurs, etc.), mais pas le développement (qui a plus sa place dans un ticket comme le dit nohar).

Corrigez-moi si je me trompe.

Mais du coup, pourquoi mettre "Active" ? Une fois que la spécification est acceptée, la suite ne la concerne plus, si ?

Mais du coup, pourquoi mettre "Active" ? Une fois que la spécification est acceptée, la suite ne la concerne plus, si ?

Active=ca a été développé. C'est utile car ça permet d'avoir un suivi temporel. Quand tu fais un projet tu passes par plusieurs étapes qui sont en parallèle. En face du dev il y a les test, , en face de la spec et de la conception (l' objet de la ZEP ) il y a la recette et la livraison.

Dire que la ZEP est active permet de fermer le cycle de développement et de donner une fin au projet. C'est totalement nécessaire.

A l' opposé en dev/en test c'est du pur développement / intégration. Ce sont des étapes que le responsable de ZEP doit suivre mais pas la ZEP elle même. D' où la différence avec unticket.