ZEP-40 : Organisons les ZEP

Introduction

Cette ZEP est volontairement détaillée sur le plan technique afin de faciliter sa réalisation. Son objectif est d'être réalisée en peu de temps.

Informations préliminaires

Aujourd'hui Zeste de Savoir possède plus de 35 ZEP dont la majorité est en rédaction. Le système fait ses preuves et met presque tout le monde d'accord. Son système de rédaction repose sur le forum ce qui est sa plus grande force mais également sa principale faiblesse.

L'objectif de cette ZEP est de proposer un système de gestion des ZEP toujours aussi simple, plus efficace et d'y apporter quelques nouvelles fonctionnalités pour faciliter la vie des développeurs.

Comment ça se passe chez les autres ?

Chez Python (PEP) tout fonctionne par mail. C'est un peu lourd mais ça à l'air de très bien fonctionner.

Chez Django (DEP) ils utilisent GitHub ce qui présente l'avantage d'avoir des diff, de pouvoir faire des PR et d'avoir une visualisation assez simple. C'est quand même moins user-frienly.

Et chez nous ?

Notre plus grande force est la suivante : notre système est intégré au site et n'importe étant capable de poster un message peut faire une proposition. Pas besoin d'envoyer un mail ou de faire une PR.

En revanche, plusieurs problèmes sont à relever, le premier étant le manque de visibilité. Aujourd'hui le filtrage avec le tag « zep » est devenu bien trop complexe. Une liste assez détaillée a vu le jour pour palier à ce problème mais il est nécessaire de la maintenir à la main. Il est donc nécessaire de trouver une solution pour avoir une vraie liste des ZEP à jour sans l'intervention d'une personne. Le forum montre également sa limite avec le système de tags qui n'est pas toujours correctement suivit.

Le second problème est l'oubli de certaines ZEP. Reléguées au fond du forum, elles finissent par être oubliées et délaissées par les développeurs malgré leur potentiel.

Enfin, le dernier problème relevé est le fait que la cartouche d'une ZEP est trop souvent inexacte. Il y a plusieurs statuts faux voir qui n'existent pas vraiment. Une uniformisation est nécessaire.

Proposition

Un système dédié … mais sans grands changements

Depuis la ZEP-12 il y a eu une uniformisation des contenus sur Zeste de Savoir, profitons en ! Le nouveau système est donc fondé sur les contenus afin d'éviter de réinventer la roue. Il possède simplement des champs et des fonctionnalités supplémentaires. Tous les membres peuvent proposer une ZEP.

Le tout est développé dans un module hors ZdS afin de ne pas alourdir le code actuel. Ce module peut être ajouté à ZdS en l'ajoutant simplement dans le settings.py. Le choix du module permet de le rendre optionnel pour d'éventuels forks.

Avantages

Les avantages sont multiples. Le premier est une meilleure visualisation globale de l'état des ZEP. Ensuite, il est facile de voir les modifications apportées à une ZEP grâce aux diff. Enfin en peut citer la possibilité de faire des brouillons et d'avoir des ZEP avec plusieurs auteurs.

Les champs supplémentaires

Les champs supplémentaires sont les suivants :

• numéro : entier, numéro de la ZEP auto-incrémenté à chaque ZEP publiée (non stockée
• révision : entier, auto-incrémenté à chaque modification (hors modification mineure)
• type : chaine de caractères, « Process » ou « Feature »
• statut : chaine de caractères, « Rédaction », « Validation », « Acceptée », « Active » ou « Refusée » ; le changement de statut ne peut être effectué que par certaines personnes (voir la partie « Évolution du statut »)
• développement : chaine de caractère, optionnelle, URL vers une branche ou une PR si le développement est commencé
• votes : M2M, voir « Système de vote » ci dessous
• ZEP parente : ForeignKey vers une ZEP, permet d'avoir une certaine relation entre les ZEP (exemple : API)

Système de vote

Aujourd'hui il est un peu compliqué de faire passer une ZEP du statut de « En validation » à « Validée ». Un système de vote assez simple permet de faire bouger les choses. Le vote est lancé une fois que le statut est « En validation ».

Chaque développeur (membre du groupe dédié) peut voter. Si le vote est négatif il doit nécessairement être accompagné d'une justification afin que l'auteur puisse retravailler dessus.

Chaque mise à jour de la ZEP (hors modification mineure, n'impactant pas le numéro de version) remet de compteur à zéro.

Le système de vote sera normalement introduit dans la ZEP-13.

Évolution du statut

Le statut n'est pas souvent mis à jour c'est pourquoi il est plus simple de le mettre à jour avec ce système. En revanche, chaque évolution du statut n'est pas faisable par tout le monde. Explications avec les différents statuts :

• -> Rédaction : tout le monde
• Rédaction -> Validation : auteur ou développeur
• Validation -> Acceptée : responsable développeur
• Acceptée -> Active : développeur
• -> Refusée : responsable développeur

Affichage

La page principale regrouperai les ZEP sous le même format que la liste des ZEP.

Historique

Révision 1

Le 4 janvier 2016 par par gustavi

• Création

Liens divers

• ZEP-12
• ZEP-13
• ZEP-25
• Liste des ZEP

Chaque développeur (membre du groupe dédié) peut voter.

Pourquoi le vote d’acceptation ou non d’une ZEP est-il ouvert aux seuls développeurs ?

Le système de vote sera normalement introduit dans la ZEP-13.

J’en ai parlé dans le sujet de la ZEP-13, mais la question du vote sur les contenus est directement lié à la ZEP-22 aussi.

ZEP-01 :

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.

Gustavo sur le fait que le site décide de ce qui se passe. Mais si des idées, traits ne conviennent pas à la communauté, ça serait cool de pouvoir s'en rendre compte.

Histoire d'avoir un peu de démocratie sur les nouveautés

On a pas de troll (trop), profitons en pour créer un système de participation d'idée ?

Une liste assez détaillée a vu le jour pour palier à ce problème mais il est nécessaire de la maintenir à la main.

C'est vrai.

Le second problème est l'oubli de certaines ZEP. Reléguées au fond du forum, elles finissent par être oubliées et délaissées par les développeurs malgré leur potentiel.

En quoi ta solution lutte contre ce problème ? Une liste automatique n'y changerait rien. La solution serait de mettre un pictogramme à coté du lien après un certain temps d'inactivité.

Enfin, le dernier problème relevé est le fait que la cartouche d'une ZEP est trop souvent inexacte. Il y a plusieurs statuts faux voir qui n'existent pas vraiment. Une uniformisation est nécessaire.

C'est à dire ?

Ce système serait je pense effectivement utile mais est-il urgent ? Et comment faire si le système de ZEP évolue ?

Je ne comprends pas trop cet argument, et je rejoins Dominus sur le fait de : « pourquoi seul les développeurs pourraient voter ? ».

Moi, ce que je sors de ta citation, c'est que le Staff (et les autres autorités compétentes en la matière), sont là juste pour faire passer les étapes à la ZEP. En soi, dire « oui c'est bon, c'est possible de le faire » ou au-contraire la refouler.

Actuellement sur le forum tous le monde peut voter, et le principe même des ZEP, de ce que j'avais compris c'est ça : elles sont là pour que tous le monde puisse participer même en ayant aucune connaissance de la technique. En restreignant le vote aux développeurs, je pense qu'on sort absolument du principe des ZEP qui ont pour but de faire évoluer le site collectivement.

L’idée de restreindre la validation aux seuls développeurs est en désaccord avec ce qui se fait ici par exemple (je l’ai vu récemment sur une autre ZEP, mais je ne me souviens plus où).

Alors peut-être s’agit-il d’une évolution par rapport au fonctionnement prévu à l’origine, mais je pense que pas mal de monde y est attaché.

Gustavi, il fallait écrire toute la citation. La voici :

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.

En gros, nous avons 4 status : rédaction, validation, accepté/refusé.

• La rédaction est initiée par la communauté et réfléchit entre les membres de la communauté.
• La mise en validation est initiée par la communauté quand ils sont tous d'accord.
• L'acceptation est initiée par l'équipe technique et, globalement, sera refusée par le staff pour des questions légales ou par l'équipe technique parce que ce n'est pas faisable. Sinon, elle sera acceptée parce que la communauté l'a déjà accepté.

Sinon, la réalisation de cette ZEP ne me semble ni urgente, ni spécialement nécessaire. Le forum m'a suffit pendant 1 an et me suffira encore sans doute l'année qui arrive.

C'est gustavi.

La phase de rédaction et de passage en validation est là pour ça. C'est ce qui se fait aujourd'hui.

Comme ?

Si tu vas sur une page avec un liste de toutes les ZEP tu vois facilement des ZEP qui ont potentiellement été reléguées en page n du forum. D'accord la liste de ZEP règle le problème mais la maintenir à la main n'est pas chose aisée.

Regarde les ZEP, combien on le premier post qui n'est pas à jour ?

Non il n'est pas urgent mais me semble intéressant.

Voir la réponse d'And0.

Je pense que ce que je propose n'a pas été compris. Je veux juste structurer les ZEP. L'aspect collaboratif reste, seule un vote d'approbation sur le plan technique se fait par les dev. En général il y a de nombreuses discussion avant et pendant la validation. La validation finale reste la même : SpaceFox a la main pour approuver ou non (en se fondant sur les votes et commentaires).

Après je pose la question : qu'est ce que change un vote ouvert à tous ? Sachant que la discussion n'est pas fermée, les dev sont là uniquement pour dire "OK c'est faisable, ça me semble bon et correcte en vue du code". OK nous n'avons pas la science infuse et je suis d'accord que des interventions extérieures sont NÉCESSAIRES (vraiment, il y a quelques membres qui ont vraiment un avis pertinent dans les discussions). Cependant sur l'aspect technique, la majorité des membres n'a aucune idée de l'état du code. Donc après on peut laisser le vote à certains membres mais c'est discriminatoire et je pense que ça ne plait à absolument personne.

Donc on est bien d'accord, tout le monde peu voter et en soie c'est une statistique intéressante pour savoir quel ZEP est attendue ou non. Le staff/équipe technique peut cependant malgré un vote favorable ne pas passer la ZEP dans le statut "Acceptée".

Oui et non. Le vote final, après discussions pendant la phase de rédaction et de passage en validation, appartient à l'équipe de développement.

Donc il y a deux votes alors, un vote de la communauté pour la partie rédactionnel et un vote du staff (argumenté ?) une fois que la ZEP est dans le statut "En Validation".

Question bête, mais en concret, ne serait-il pas intelligent de se servir de la ZEP-12 comme socle à cette ZEP ? Parce-que finalement, une ZEP sa ressemble très fort à un article/tuto à par qu'il y a quelques informations en plus.

Non il n'y a qu'un seul vote. Les discussions sont là pour la partie communautaire.

Je pense que tu n'as pas juste pas lu la ZEP.

Si si j'ai bien vu qu'il y avais une proposition d'un vote pour le staff afin de passer du statut "En validation" au statut Valider (ou Refuser).

Sauf que je trouve intéressant l'idée que la communauté puisse elle aussi voté pour une ZEP, ne fusse que pour jaugé de l'attente de la communauté vis à vis d'une ZEP

Je ne vois pas l'intérêt de ce vote.