ZEP-01 : Rôle et fonctionnement des ZEP

Processus de spécification des nouvelles fonctionnalités

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

Les ZEP, c'est fini !

Après deux ans de loyaux services, nous avons décidé de mettre fin au système de ZEP, afin de le remplacer par un processus beaucoup moins rigide et contraint. Vous êtes donc invités à ne plus créer de ZEP (voir ce sujet).

Si vous êtes l'auteur ou le responsable d'une ZEP en cours. Vous pouvez choisir de terminer sa mise en œuvre comme bon vous semble : selon la ZEP, ou bien en découpant le travail en étapes…


Cartouche
ZEP 1
Titre Rôle et fonctionnement des ZEP
Révision 4
Date de création 11 Juillet 2014
Dernière révision 01 Décembre 2016
Type Process
Statut MORTE

Qu'est-ce qu'une ZEP ?

Une ZEP (ZdS Enhancement Proposal) est un texte décrivant une amélioration de Zeste De Savoir voulue par la communauté. Il faut bien voir que pour que le site puisse évoluer dans le bon sens, il peut y avoir plusieurs grosses entités à mettre d'accord1 :

  • la communauté (les utilisateurs, qui veulent ces améliorations) ;
  • les développeurs (ceux qui implémenteront les améliorations s'il s'agit de nouvelles fonctionnalités) ;
  • le staff bénévole du site ;
  • l'association Zeste De Savoir.

Pour cela, il est important de garder une trace propre de toutes les décisions majeures et avoir un processus de décision clair. Évidemment, ce genre de problématique existe également dans de nombreux autres projets open-source et communautaires. C'est pourquoi nous nous inspirons ici du fonctionnement de la communauté Python et de ses PEP, qui nous semble particulièrement adapté à ce genre de cas (ni trop lourd, ni trop léger, purement collaboratif et entièrement traçable).

Types de ZEP

Une "amélioration du site", c'est vague. À ce jour on peut en distinguer plusieurs types :

  • les évolutions sur la façon de fonctionner de la communauté ;
  • les fonctionnalités majeures du site.

Les ZEP vont donc se différencier en plusieurs types :

  • Les ZEP de type Process décrivent la façon dont fonctionne la communauté, ou bien proposent des améliorations à ces processus. Par exemple, ces propositions peuvent concerner le processus de développement, de prise de décision, de validation, de modération… Leur rôle est donc plutôt organisationnel.
  • Les ZEP de type Feature décrivent les nouvelles fonctionnalités du site, ou bien proposent une évolution d'une fonctionnalité existante. Leur rôle est donc plutôt technique.

On entend par "fonctionnalité majeure" une fonctionnalité qui nécessite un travail de spécification et de conception préalable.

Par exemple : Le changement de couleur d'un cadre ou l'ajout d'un bouton ne feront pas l'objet d'une ZEP. Une refonte du système de tutoriels ou l'ajout d'un système de gratification des contributeurs qui impliquerait des modifications au niveau de plusieurs modules du site, en revanche, devraient faire l'objet d'une ZEP.

Évidemment, la présente ZEP, qui décrit récursivement le fonctionnement des ZEP, est de type Process.

Cycle de vie d'une ZEP

La rédaction

Après une discussion sur le forum pendant laquelle une idée d'amélioration est émise et semble prometteuse, la communauté2 crée un sujet ZEP. En premier post de ce topic se trouve le texte de la proposition officielle sur laquelle la communauté va travailler. La ZEP porte alors le statut Rédaction. Le but est de permettre à tout le monde de répondre à ce sujet pour proposer des modifications au texte de la ZEP, et de se mettre d'accord.

Si la communauté ne parvient pas à trouver un consensus sur un point particulier de la proposition, le rédacteur est tenu de faire figurer clairement les différentes alternatives dans le texte de la ZEP. Il appartiendra alors aux personnes chargées de valider la ZEP de trancher en faveur d'une alternative ou d'une autre. Ceci permet d'éviter de bloquer les discussions sur des points de détail.

La validation

Lorsque la proposition est arrivée à un état stable et mature, elle prend le statut Validation. Le Staff et/ou les développeurs principaux du site (et/ou le conseil d'administration de l'association si son implication est nécessaire), faisant autorité pour valider la ZEP, se chargent alors de la relire pour l'accepter ou non.

À l'issue de la validation, la ZEP peut prendre le statut :

  • Acceptée : la proposition sera mise en place ;
  • Rédaction : la proposition est renvoyée au statut Rédaction pour être modifiée/précisée/clarifiée ;
  • Refusée : le proposition est définitivement refusée.

Ce changement de statut doit être accompagné du motif de la décision, en cas de refus ou de retour en rédaction.

Lorsqu'une ZEP de type Feature est acceptée, le(s) ticket(s) correspondant(s) est(sont) créé(s) sur le bugtracker.

La mise en place

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.

Contenu d'une ZEP

Pour qu'une ZEP soit validée, elle doit être le plus clair possible. Quel que soit son type, elle doit détailler les informations suivantes :

  • Le contexte de la proposition : le "pourquoi ?", c'est-à-dire le problème à résoudre, la situation qui nécessite une évolution.
  • L'objet de la proposition : le "quoi ?", c'est-à-dire une description précise de l'amélioration et de ce qu'elle doit permettre. Autrement dit, pour une fonctionnalité, la spécification fonctionnelle.
  • Les moyens mis en œuvre : le "comment ?", c'est-à-dire la façon dont l'amélioration doit être mise en place concrètement. Autrement dit, pour une fonctionnalité, la spécification technique.

Le plan de la ZEP en lui-même est laissé à la libre appréciation des rédacteurs, à condition qu'il permette d'identifier clairement ces trois informations.

Titre du topic et cartouche

Le titre du topic créé sur le forum "Dev Zone" doit être au format suivant :

1
[ZEP][{statut}] ZEP-{numéro} : {titre}

{statut} désigne le statut actuel de la ZEP, {numéro} désigne le numéro identificateur unique de la ZEP, et {titre} l'intitulé de la proposition.

Le topic doit contenir un petit tableau en préambule, qu'on appellera cartouche et qui résume la nature, le contenu, et l'état actuel de la ZEP. Voici son format en Markdown :

1
2
3
4
5
6
7
8
9
Cartouche            | 
---------------------|-----
**ZEP**              | [Numéro de la ZEP]
**Titre**            | [Titre de la proposition]
**Révision**         | [Numéro de révision, incrémenté à chaque modification]
**Date de création** | [Date de création du topic]
**Dernière révision**| [Date de la dernière modification]
**Type**             | [*Process* ou *Feature*]
**Statut**           | [Statut de la ZEP]

  1. Toutes ces entités ne sont pas obligatoirement concernées par toutes les ZEP, mais PEUVENT l'être. 

  2. Il s'agit ici de la communauté au sens le plus large du terme. C'est-à-dire les visiteurs, les membres actifs du site, les membres du staff bénévole, les développeurs et les membres de l'association. 

Édité par nohar

I was a llama before it was cool

+17 -0
Staff
Auteur du sujet

"On", c'est évidemment la communauté, rejointe éventuellement par l'équipe de dev, le Staff, etc..

En fait, "on", c'est la communauté au sens le plus large du terme : les visiteurs + tous les groupes impliqués dans le site. ;)

Je vais faire la modif.

I was a llama before it was cool

+0 -0
Staff

Je pense qu'il faut bien préciser que les zep sont là pour les fonctionnalités ou évolutions majeurs, qui méritent un débat, pas pour rajouter un bouton dans un coin. Sinon ça va être super lourd.

+7 -0

Je sais pas si la situation va se présenter, mais je pense qu'on peut se retrouver dans le cas où une ZEP de type Process conduit à la nécessité d'implémenter une nouvelle fonctionnalité. Du coup, on créé une deuxième ZEP de type Feature pour la nouvelle fonctionnalité (ZEP qui référencerait d'une manière ou d'une autre la ZEP initiale ?) ou on gère tout dans la ZEP initiale ?

J'ai les goûts les plus simples du monde, je me contente du meilleur O. Wilde

+2 -0
Staff
Auteur du sujet

Wow, c'te question philosophique. :D

J'essaye d'imaginer un cas où ça se présenterait. Mettons par exemple "les propositions de corrections mineures par des membres tiers sur les tutoriels". Un tel cas serait une modification du processus de validation des tutoriels et articles, et il implique un développement non trivial. Dans un tel cas, je pense que la description fonctionnelle de la feature permet de bien cerner le changement apporté au processus de validation.

Du coup, pour ne pas faire trop lourd, je pense qu'on peut se contenter de tout décrire dans la ZEP Feature.

D'une façon générale, faute de pouvoir mieux anticiper le problème, je pense qu'on peut s'en remettre au bon sens des gens et décider au cas par cas quand ça se présentera.

Édité par nohar

I was a llama before it was cool

+1 -0
Staff
Auteur du sujet

À la rigueur dans les posts en-dessous de la spec, ou dans l'issue si la ZEP est acceptée tu peux mettre un lien vers la branche/le repo.

Ou alors tu peux le mettre dans un paragraphe "POC", ou "Références"…

Vu que le plan est laissé à la libre appréciation du rédacteur, on peut inclure tout ce qu'on veut du moment que ça sert la proposition. :)

I was a llama before it was cool

+2 -0
Staff
Auteur du sujet

À mon avis, on n'a pas besoin de ça pour le moment. C'est surtout pour montrer si ça a bougé ou non depuis la dernière fois qu'on a lu la ZEP.

Après, à l'usage, on peut imaginer qu'on se fasse un module de ZEP1 qui soit versionné avec git comme les articles et tutos, et exportable vers une belle documentation du site, mais pour l'instant ça me semble overkill.

PS : le changelog on le voit dans le topic ;).

Par contre à terme y'aura peut-être besoin de référencer les ZEP reliées entre elles… On verra à l'usage quand ça se présentera.


  1. faudrait faire une ZEP pour le module de ZEP… 

Édité par nohar

I was a llama before it was cool

+0 -0
Staff
Auteur du sujet

Il suffit pas de cliquer sur le tag #zep ?

Python a une PEP-00 exprès pour ça, mais dans l'absolu ce serait pas mal si on pouvait reposer sur un truc automatique pour les référencer (parce que les mettre à jour à la main est une contrainte bien relou).

I was a llama before it was cool

+0 -0

Salut. Je déterre un peu juste pour faire une petite remarque : la ZEP-01 n'a pas de cartouche.

Sinon je pense que c'est une excellente idée et j'apprécie qu'un site comme ZdS est apparu et devienne comme le feu SdZ aurait dû !

Édité par louk

+0 -3

Je vous annonce que la première ZEP vient d'être mergée !

C'est donc la ZEP 3 qui arrivera en v1.4.

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+3 -0

J'ai juste une petite question : pourquoi parler de « type Process » et de « type Feature », quand l'explication même — dans le message d'origine — de la distinction entre les deux utilise les mots « processus » et « fonctionnalité » qui en sont des traductions exactes ? Y a-t-il une raison valable au fait de ne pas parler français sur un site qui se revendique francophone ?

#JeSuisGrimur #OnVautMieuxQueÇa

+1 -2
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte