imath

Salut à tou·te·s !

La version 5.0 de WordPress et surtout son éditeur de blocs ont été discutés et continue de l’être. Beaucoup d’entre nous partagent leur mécontentement en regrettant que tel ou tel détail ait été mal pensé ou mal conçu. Aussi, je crois qu’il est important de saisir l’opportunité offerte par Josepha pour lui faire part des points forts et des points d’effort qui caractérisent cette version si controversée.

Pour vous inspirer, vous trouverez ci-dessous mes réponses à l’enquête qui servira à l’élaboration de ce bilan. J’ai volontairement fermé les commentaires de cet article, car le plus important n’est pas de me dire ce que vous avez pensé de ce cycle de développement, mais de le faire directement auprès de WordPress !

Ne tardez pas trop, vous avez jusqu’au 15 mars pour participer à ce bilan.

Q1. Quels aspects du cycle de développement de la version 5.0 devraient être maintenus lors des prochains cycles ?

J’ai beaucoup apprécié contribuer à l’extension Gutenberg depuis GitHub. Je ne sais pas si c’est le cas, mais j’ai l’impression que l’utilisation de GitHub a permis à des personnes avec un bagage ou des expériences divers de se lancer dans la contribution à WordPress. Par ailleurs, gérer des PRs est beaucoup plus pratique que gérer des patches. Donc je pense que choisir GitHub pour le développement des nouvelles fonctionnalités est une excellente idée.

C’est aussi très bien de disposer de tout ce dont nous avons besoin au même endroit : le dépôt GitHub de Gutenberg intègre notamment des notes à l’attention des contributeurs et de la documentation de développement qui sont d’une aide très précieuse. Les gens du projet Gutenberg ont vraiment été super amicaux avec moi et j’ai énormément appris à propos de React en suivant leurs conseils.

Je pense que la partie réservée aux développeurs de la communication du projet s’est vraiment bien déroulée. Nous avons fréquemment été informés des progrès effectués et de l’évolution du planning. L’article traitant de la gouvernance de la version 5.0 et de la manière dont les équipes étaient organisées a été très important selon moi, alors merci beaucoup pour celui-ci.

Finalement, je crois que c’est génial que Matt ait sponsorisé cette fonctionnalité. Il est important que le chef du projet impulse une dynamique pour transformer les idées de rupture en réalités opérationnelles.

Q2. Y-a-t-il des choses que nous devrions commencer à faire ?

Beaucoup de ce que j’ai entendu au sujet des possibles améliorations à apporter concernait l’adoption par les utilisateurs ou la gestion du changement au sein des entreprises.

Le cycle de développement 5.0 est particulier car il a introduit une innovation majeure quant à la manière de rédiger des contenus dans WordPress suite à plus de dix années d’utilisation de l’éditeur classique. Je pense, malheureusement, que les utilisateurs ou les entreprises ne lisent pas si souvent que cela les publications issues du « Make ». Je pense aussi que la manière dont nous échangeons sur ce « Make » ne parle pas beaucoup aux utilisateurs ou aux entreprises et je doute qu’un utilisateur ou un représentant d’une entreprise réagirait à une des publications.

C’est pourquoi je crois qu’un article de lancement sur w.org/news expliquant comment cette innovation de rupture pourrait impacter leur utilisation, comment le cycle pourrait être cadencé, …, le tout accompagné d’une invitation à partager leurs préoccupations à son propos dés cette étape avancée aiderait à éviter des controverses ou des malentendus. Un point à mi-parcours serait également intéressant pour échanger sur les progrès accomplis.

Une documentation pour les utilisateurs et des tutoriels mis à disposition plus tôt : je reconnais que ce n’était pas facile étant donné que l’interface de l’éditeur de blocs évoluait très rapidement. Toutefois, à la différence de l’éditeur classique, une telle documentation est nécessaire pour commencer à utiliser l’éditeur de blocs. J’ai moi-même écrit six tutoriels sur mon blogue personnel et des utilisateurs m’ont remercié par exemple parce qu’ils ne comprenaient pas comment ajouter un lien dans le bloc du paragraphe. Ainsi des choses qui peuvent nous paraître évidente ne le sont peut-être pas pour tous les utilisateurs.

Q3. Des choses que nous devrions cesser de faire ?

À mon humble avis, une nouvelle fonctionnalité, quelque soit son importance ou ses grandes attentes, ne devrait jamais avoir un impact sur le rythme des cycles de développement. Suite à la publication de la version majeure 4.9.0, certaines versions mineures faisaient plus que simplement résoudre des anomalies ou des problèmes de sécurité. Par exemple la version 4.9.6 a introduit le composant de la vie privée. Elle aurait déjà dû être étiquetée 5.0.0.

Je pense que la décision d’attendre que le projet Gutenberg dispose d’un éditeur prêt à l’emploi était trop risquée. Une forte pression s’est abattue sur les membres de l’équipe de ce projet, et des personnes d’autres équipes de contribution ont dû être assez démotivées que toute l’attention se soit portée sur une seule fonctionnalité.

Après coup, je pense que l’intégration de l’éditeur de blocs dans WordPress aurait pu se faire de manière plus harmonieuse durant un cycle de développement ultérieur (ex: 5.1 ou 5.2). Cela nous aurait permis d’éviter de se balancer entre le tronc et la branche 5.0 lors de nos contributions à WordPress pendant un temps certain !

Presser un projet open source devrait vraiment être évité. Je me revois lire que des nécessités d’accessibilité n’étaient pas au rendez-vous et penser que peut-être nous devrions patienter pour ne pas risquer de générer une mauvaise opinion des membres de la communauté à propos de l’éditeur de blocs avant même d’avoir commencé à l’utiliser.

Je pense également qu’il est préférable d’ouvrir des discussions lorsqu’il reste encore quelque chose à discuter. Je me rappelle de ce compte-rendu de la réunion JavaScript du 23 avril 2017 au sujet du cadre JavaScript que WordPress devait choisir pour son avenir. Si vous relisez les commentaires aujourd’hui, vous vous apercevrez qu’une large majorité d’entre eux sont favorables à Vue.js, mais c’est React qui a été choisi. Et ce choix n’est certainement pas étranger au fait que les premières itérations de l’éditeur de blocs ont été développées dans ce cadre. Je pense que c’est mieux de directement annoncé : « nous avons choisi React pour ces raisons… »

Q4. D’autres retour d’information à propos du cycle de développement que vous aimeriez partager ?

Je ne sais pas si seule la France est concernée, mais j’ai le sentiment que le cycle de développement de la version 5.0 a égratigné la communauté française. Désormais il existe deux clans principaux :

• celles et ceux qui sont frustrés parce qu’ils ont subit l’éditeur de blocs dans leur business. Elles et ils ont l’impression que la décision d’intégrer la fonctionnalité n’a pas été le résultat d’un consensus mais leur a été imposée par la force.
• les supportrices et supporteurs de l’éditeur de blocs.

C’est maintenant très compliqué de se parler et toute nouvelle annonce relative aux fonctionnalités de WordPress est vécue comme une menace ou comme une décision qui ne satisfait pas l’intérêt général mais des intérêts particuliers.

Je suis très heureux que Josepha ait publié cette enquête car je pense qu’il est important que nous essayions en permanence d’améliorer le logiciel et la manière dont nous le construisons. J’espère vraiment que les personnes sceptiques partageront leurs préoccupations afin que nous trouvions une manière de nous réconcilier.

Nombreux remerciements à toutes les contributrices et à tous les contributeurs du cycle de  développement de la version 5.0. Ça n’a pas été facile, c’est un cycle très controversé, mais félicitations pour l’excellent travail accompli.

Q5. Y a-t-il d’autres questions que nous aurions dû poser ?

En voici une : si vous n’avez pas contribué à ce cycle de développement, qu’est ce qui, selon vous, vous a manqué pour vous lancer ?