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}
|
où {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] |
-
Toutes ces entités ne sont pas obligatoirement concernées par toutes les ZEP, mais PEUVENT l'être. ↩
-
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. ↩
