WCEU 2016 : le process d’ajout de fonctionnalités (WordPress core)

Mike Schroder est venu nous présenter la philosophie employée par les équipes de développement du « WordPress core » pour arbitrer si une fonctionnalité doit intégrer le core et si oui, dans quelle version.

Decision-making in WordPress core development

Jour 1 – Track 1 – 12:30

Mike Schroder


Mike mentionne en début de conférence que pour toute personne intéressée de près comme de loin à la contribution dans WordPress, l’adresse à retenir est :

Making WordPress

Rappelons l’organisation des développeurs du coeur de WordPress. Matt est le big boss, talonné de très près par 5 lead developeurs, eux-mêmes suivis par des commiters permanents ou non, les component maintainers et les contributeurs (vous et certains de mes collègues).

Quel concept intelligent le “component maintainer” ! Ces développeurs sont responsables d’une partie bien précises de WordPress comme le customizer, les sidebars ou les thèmes par exemple et ont leur mot à dire lorsqu’une fonctionnalité touche à leur territoire.

Sur le papier, il y a des procédures. Dans les faits, c’est un mix de bon sens et de règles de base tirées de la philosophie qui font qu’une fonctionnalité est intégrée ou non dans le WordPress core. Elle doit convenir au plus grand nombre, ne pas être trop spécifique donc et apporter quelque chose ou faire gagner du temps aux utilisateurs.

Historiquement, en début de chaque nouvelle version majeure, une liste de fonctionnalités à développer était votée puis tout le monde se mettait au travail, avec en ligne de mire la deadline calculée par les lead developers. Dans le cas où une fonctionnalité venait à prendre du retard, cela mettait en péril la date de sortie plannifiée de la version de WordPress en question.

Aujourd’hui l’idée est plutôt de créer à tout moment des “feature projects”, des projets indépendants liés à une fonctionnalité précise qui ont leur propre éco-système. Lors des réunions de décision sur les fonctionnalités à intégrer, les lead developeurs n’ont plus qu’à piocher parmi les feature projects les plus mûrs qui ont été testés et validés par le Component Maintainer relatif. Ainsi, le risque de mettre en péril la date de sortie programmée est limité.

Mike a pris l’exemple du projet “Shiny updates” dont l’idée est de simplifier le processus d’ajout et de mise à jour de thèmes et de plugins. Il a été constaté avant le lancement de l’itération qu’une seule partie du plugin était suffisamment mature pour être mergée dans le WordPress core donc la décision prise a été de ne garder que la partie stable.

 

Nous avons eu un second exemple qui montre la pertinence des Component Maintainers. L’administration du logo ajoutée dans la version 4.5 de WordPress a changé à deux reprises de nom passant de “Site logo” à “Theme logo” puis “Custom logo” car les Component Maintainers respectifs se sont renvoyés la balle en précisant que ça ne collait pas à l’existant. Site logo ne convenait pas puisque selon le thème le ratio peut changer, thème logo non-plus puisque les autres paramètres commençaient tous par “Custom ..”. Face à ces deux solutions antinomiques, “Custom logo” a finalement été validé.

La liste des featured projects en cours de développement se trouve ici : https://make.wordpress.org/core/features-as-plugins/

Mike nous quitte en martelant que nous sommes tous invités à contribuer d’une façon ou d’une autre et qu’il faut pour cela se rendre sur

https://make.wordpress.org

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *