Gutenberg: Fournir un aperçu en langage clair de la portée, de l'orientation et des objectifs du projet

Créé le 6 nov. 2017  ·  53Commentaires  ·  Source: WordPress/gutenberg

AVANT DE POSTER VOTRE PROBLÈME : - Ces commentaires n'apparaîtront pas lorsque vous soumettez le problème. - Essayez d'ajouter autant de détails que possible. Être spécifique! - Veuillez ajouter la version de Gutenberg que vous utilisez dans la description - Si vous demandez une nouvelle fonctionnalité, expliquez pourquoi vous souhaitez qu'elle soit ajoutée. - Recherchez dans ce référentiel le problème et s'il a déjà été corrigé ou signalé. - Assurez-vous d'utiliser le dernier code avant de consigner les bogues. - Désactivez tous les plugins pour vous assurer qu'il ne s'agit pas d'un problème de conflit de plugins.

Aperçu du problème

Mon observation est que la communauté a du mal à voir la portée plus large du projet Gutenberg en raison du manque d'une seule ressource en langage clair faisant autorité contenant cette information. Cela crée un degré élevé de spéculation, de mauvaise communication et de frustration de la part de toutes les parties et le projet en souffre.

Le projet Gutenberg a besoin d'une documentation de portée et de processus en langage clair : quel est l'objectif final (tout dans la vue est un bloc), comment allons-nous y arriver (versions échelonnées en commençant par l'éditeur) et qu'est-ce que cela signifie pour l'avenir de divers composants WordPress (shortcodes, métaboxes, champs, etc.). Toutes (ou la plupart) ces informations existent sous forme de commentaires individuels, de demandes d'extraction, de billets de blog, de mises à jour de Slack et d'autres informations satellites, mais à ma connaissance et à celle de la communauté au sens large, il n'existe pas de ressource canonique unique où tous les éléments sont rassemblés dans un langage simple et facile à comprendre.

Étapes à reproduire (pour les bogues)


  1. Toute discussion sur Gutenberg sur les réseaux sociaux/blogs.
  2. Discussion dans « Les iframes sont-ils une solution viable à long terme pour les métabox ? » #3304
  3. Demandez aux utilisateurs de WordPress en dehors de la bulle Gutenberg « qu'est-ce que Gutenberg ? » » et « Que deviendra Gutenberg à terme ?

Comportement prévisible



Ceux qui connaissent (mais ne contribuent pas nécessairement) au projet Gutenberg devraient avoir une idée claire de a) ce que Gutenberg fait maintenant et comment cela les impactera immédiatement, et b) où Gutenberg se dirige.

Comportement actuel


  • La notoriété du projet Gutenberg est faible mais croissante.
  • La compréhension de l'objectif de Gutenberg au-delà de « l'éditeur change » est rare, même parmi ceux qui sont au courant du projet.
  • La conscience et la compréhension de la direction de Gutenberg au-delà de la portée immédiate de l'éditeur font défaut, même parmi ceux qui suivent le projet de près.
  • La conscience des conséquences, immédiates et à long terme, de Gutenberg sur les utilisateurs, administrateurs, concepteurs et développeurs est plus ou moins absente.
  • Comprendre, même à un niveau général, ce que Gutenberg signifie pour les fonctionnalités de base de WordPress telles que les widgets, les champs, les métaboxes, les codes courts, etc. est proche ou égal à nul.
  • L'absence d'une ressource faisant autorité pour les informations sur le projet conduit à des spéculations et des malentendus.
  • Le manque de compréhension commune de la portée et des objectifs du projet entraîne une rupture de la communication et une escalade des tensions.

Solution possible



Le projet Gutenberg doit publier une ressource centrale complète et en langage clair décrivant la portée du projet, la direction prévue, les objectifs réalistes et étendus, les délais, les sprints et d'autres informations directement liées au projet (idéalement le fichier README.md dans le projet lui-même.

Actuellement, ces informations existent, en partie, dans divers articles de Make , l' article de Gutenberg and the Ship of Thesus " , @m 's " We Called it Gutenberg for a Reason ", dans l'histoire des chats Slack, et en pull demandes et tickets dans ce référentiel.

En raison de la nature fragmentée de ces informations, il est difficile pour quiconque d'avoir une image claire de l'ensemble du projet, et bien que les publications de @mtias et @m expliquent bien la grande vision du projet, elles manquent de

Une seule ressource expliquant
a) pourquoi Gutenberg existe (une version simplifiée du post de
b) où il se dirige (objectifs finaux + grande vision),
c) pourquoi le projet se concentre actuellement sur l'éditeur, et
d) que le focus de l'éditeur est le premier élément constitutif d'un plan plus vaste,
contribuera grandement à résoudre une partie de la confusion et de l'inconfort ressentis par toutes les parties impliquées dans ces conversations et peut servir de ressource et de référence unifiées lorsque des questions sur les problèmes liés aux métaboîtes, verrouillant Gutenberg à l'éditeur, etc. se posent.

La clé du succès ici est une compréhension commune d'où nous sommes, où nous allons et ce que signifient réellement les termes que nous utilisons. Cela commence par une documentation en langage clair dans un emplacement facile d'accès.

[Type] Documentation

Commentaire le plus utile

Je suis d'accord avec les questions soulevées et la discussion sur Gutenberg a été très problématique.

Cependant, je dirais que ce qui a besoin d'une feuille de route à ce stade n'est pas seulement Gutenberg, mais _WordPress_ lui-même.

La direction actuelle du projet de "plate-forme d'applications Web JS à la mode, basée sur un noyau hérité en dialecte PHP obsolète, que les gens utilisent réellement pour créer des sites de contenu" devient bizarre.

À ce stade, le citer de manière sélective peut apparemment justifier :

  • compatibilité descendante absolue
  • rupture de la rétrocompatibilité
  • changements majeurs dans la technologie
  • la technologie ne change pas
  • apprendre de l'industrie du développement PHP et/ou Web plus large
  • ignorant complètement tout en dehors du projet

La conversation sur Gutenberg échoue non seulement parce que sa vision n'est pas claire.

C'est un échec parce que Gutenberg prétend être vital pour les objectifs du _projet WordPress_. Et ces dernières années, cette vision semble avoir progressivement perdu de la clarté de ses objectifs, de sa direction et de ses priorités.

Tous les 53 commentaires

Cela explique pourquoi une feuille de route publique claire pour les produits est utile. https://open.buffer.com/transparent-product-roadmap/

Merci, ça m'aiderait beaucoup.

Une question ouverte de nombreux propriétaires de sites planifiant leur orientation pour les années à venir devrait également être abordée : la relation de Gutenberg avec les constructeurs de pages.

Par exemple:

  • comment vont-ils s'intégrer dans un premier temps ?
  • quels domaines de la fonctionnalité de création de pages Gutenberg couvrira-t-il dans quel jalon ? Par exemple, structurer des mises en page réactives dans des sections/colonnes, un style détaillé (couleurs, images d'arrière-plan, rembourrage des marges et tout le reste). En d'autres termes : l'éditeur Gutenberg est-il perçu comme un outil d'écrivains ou aussi un outil de designers ?
  • Gutenberg prendra-t-il en charge quelque chose comme une bibliothèque de modèles ?

En supposant qu'ils coexistent longtemps :

  • Sera-t-il possible d'avoir un bloc contenant une mise en page de constructeur de page ?
  • Est-ce un objectif de pouvoir faire glisser une instance de Gutenberg ou des blocs uniques dans une mise en page de générateur de page ?

Sans parler de l'édition frontale...

Oui, le projet Gutenberg semble avoir une portée rampante qui crée un FUD inutile sur l'avenir de WordPress, d'autant plus que le succès du projet se chevauche avec le succès de WordPress lui-même. Bien qu'il y ait beaucoup de gestion de projet efficace et itérative, il y a un écart avec la gestion de produit que cela permettrait de combler.

Ceci est symptomatique d'un problème plus important avec la feuille de route WordPress qui n'est qu'une liste historique des versions. Le principal obstacle pour les agences utilisant les solutions WordPress pour les clients est la feuille de route selon notre récent rapport d'enquête sur l'utilisation de WordPress par WordPress Marketing. Malgré leur grande satisfaction vis-à-vis de WordPress, certaines agences s'inquiètent du manque de connaissance du cas d'utilisation du CMS et de la rétrocompatibilité.

@Skarjune D'après ce que j'ai rassemblé en observant le processus au fil des ans, en lisant divers documents publiés par l'équipe et en discutant avec les membres de l'équipe, je ne pense pas qu'il y ait (beaucoup) de dérive de portée ici. Il y a un raisonnement assez clair qui parcourt l'ensemble du projet et le dirige dans une direction spécifique pour l'avenir. Le problème est que l'information n'est pas contenue dans un seul endroit auquel les gens peuvent accéder. Si une seule ressource était créée pour décrire correctement ces choses, je pense que beaucoup de gens dormiraient plus profondément la nuit.

Quelques autres choses que j'aimerais voir sans ordre particulier :

  • Le raisonnement derrière le fait de lier Gutenberg à 5.0 spécifiquement par rapport à un plugin de fonctionnalité à la manière du travail de l'API REST qui sera intégré lorsqu'il sera prêt.
  • Une justification pour prendre en charge l'intégralité de l'écran d'édition par rapport à l'éditeur de contenu (ce que cela permet, etc.).
  • Un calendrier approximatif pour la fusion, la publication. Que pense l'équipe du moment où la version 5.0 devrait être ciblée ? Cela pourrait n'être qu'un quart ("T2 18 vs "Début avril"), mais pour le moment, les gens semblent avoir des attentes différentes quant au moment où la 5,0 se produirait et s'il attendrait vraiment, disons, un an s'il fallait autant de temps à Gutenberg pour atteindre le marque.

    • Coïncidant avec cela, les critères de libération. Que doit- il y avoir avant que l'équipe ne fusionne? La prise en charge de Metabox et la manière dont cela est réalisé sont le bouton actif actuel, mais la liste des critères devrait aller au-delà.

  • Ce qui ne sera PAS dans la première version. Par exemple, si la prise en charge de l'API Fields devait être considérée comme hors de portée, elle figurerait dans cette liste. Cela n'a pas besoin de répertorier tout ce qui est exclu, mais devrait couvrir les éléments plus importants qui ont fait l'objet d'une discussion externe.
  • Problèmes ouverts importants. En utilisant à nouveau l'API Fields comme exemple, si la décision de terminer cela et que Gutenberg le soutienne était sur la table, cela serait alors répertorié comme un problème ouvert afin que les gens sachent qu'il fait l'objet d'un débat. Encore une fois, cela ne devrait pas être tous les problèmes ouverts, mais simplement des problèmes importants qui prendront beaucoup de temps ou d'efforts ou qui auraient un impact significatif sur la direction et les capacités de Gutenberg.

@ mor10 OK, j'ai la présentation technique de l'éditeur , où je ne vois aucune référence à l'adressage des boîtes méta dans l'interface utilisateur, seulement une critique des codes courts comme une mauvaise implémentation pour la gestion des données via l'éditeur. Mon propos visait simplement à indiquer que certains utilisateurs professionnels de WordPress s'étonnent que leurs contraintes soient hors de propos.

Je ne peux pas parler au nom de tout le monde en utilisant le terme, mais quand je dis "fluage de la portée", je fais référence à une portée que j'ai supposée sur la base de déclarations publiques dans les articles de blog Make, l'ancienne page de destination du projet (que je ne peux plus trouver n'importe où) et la page actuelle du

Pour l'amour de la postérité, voici la description actuelle du plugin :

L'objectif de l'éditeur de blocs est de rendre l'ajout de contenu riche à WordPress simple et agréable.

Il s'agit d'un logiciel bêta.

La nouvelle expérience de création de publications et de pages facilitera la rédaction de publications riches, ce qui facilitera la tâche de faire ce qui aujourd'hui pourrait nécessiter des codes courts, du HTML personnalisé ou une découverte intégrée de « viande mystère ».

WordPress prend déjà en charge une grande quantité de « blocs », mais ne les fait pas très bien apparaître, ni ne leur donne beaucoup d'options de mise en page. En adoptant la nature en blocs du contenu de publication riche, nous mettrons en évidence les blocs qui existent déjà et fournirons des options de mise en page plus avancées pour chacun d'eux. Cela vous permettra de composer facilement de beaux posts comme cet exemple.

Lorsque vous lisez la page du plugin, même à ce jour, il n'y a aucune mention de boîtes méta. Nous voyons des références à l'éditeur, écrivant des articles riches, des codes courts, du HTML personnalisé, des intégrations et composant de beaux articles (qui renvoient ensuite à un exemple de contenu d'article).

La terminologie utilisée dans la description de la page du plugin amènerait toute personne familière avec WordPress à s'attendre à ce que l'éditeur de contenu soit mis à jour. Pourquoi? Parce que tous ces termes mentionnés sont des choses pour lesquelles nous utilisons l'éditeur de contenu aujourd'hui. Il n'y a rien qui indiquerait à un utilisateur ou développeur WordPress inconnu que la portée du projet a l'intention d'aller au-delà de l'éditeur de contenu.

Alors que certains peuvent interpréter la portée en fonction d'une compréhension interne, je l'examine en fonction de ces matériaux tournés vers l'extérieur. La feuille de route que @mor10 propose est une opportunité de synchroniser les deux.

Réticulation avec #3347.

Ma principale préoccupation est de savoir dans quelle mesure la collecte de données change pour s'adapter à Gutenberg ? La structure de données sous-jacente modifie-t-elle l'un de ses points de terminaison d'API associés ?

Je suis d'accord avec les questions soulevées et la discussion sur Gutenberg a été très problématique.

Cependant, je dirais que ce qui a besoin d'une feuille de route à ce stade n'est pas seulement Gutenberg, mais _WordPress_ lui-même.

La direction actuelle du projet de "plate-forme d'applications Web JS à la mode, basée sur un noyau hérité en dialecte PHP obsolète, que les gens utilisent réellement pour créer des sites de contenu" devient bizarre.

À ce stade, le citer de manière sélective peut apparemment justifier :

  • compatibilité descendante absolue
  • rupture de la rétrocompatibilité
  • changements majeurs dans la technologie
  • la technologie ne change pas
  • apprendre de l'industrie du développement PHP et/ou Web plus large
  • ignorant complètement tout en dehors du projet

La conversation sur Gutenberg échoue non seulement parce que sa vision n'est pas claire.

C'est un échec parce que Gutenberg prétend être vital pour les objectifs du _projet WordPress_. Et ces dernières années, cette vision semble avoir progressivement perdu de la clarté de ses objectifs, de sa direction et de ses priorités.

En tant qu'éditeur wordpress mineur et mainteneur principal du site wordpress de mon organisation qui suit le développement wordpress principalement à distance - en parcourant occasionnellement make.wordpress.org et en scannant wptavern.com ; Je suis tombé sur ce billet via wptavern et je suis tout à fait d'accord.

Je remercie @ mor10 pour avoir fait l'effort de décrire les préoccupations dans un langage succinct et clair, qu'une page clairement expliquée serait très utile. Cela fournirait aux utilisateurs semi-puissants (qui ne sont pas dans les mauvaises herbes et n'ont pas encore testé cela, mais qui veulent un avis pour voir ce qui se passe dans le pipeline sans contacter directement les développeurs (ce qui peut sembler ennuyeux et/ou une nuisance) pour comprendre où se dirige wordpress afin qu'ils puissent s'assurer que les modifications de wordpress peuvent être mises en œuvre de leur côté.

Je suis d'accord avec @kevinwhoffman. En mentionnant à l'origine Gutenberg lors de nos réunions mensuelles comme "la nouvelle expérience d'édition pour WordPress 5.0", je m'attendais également à ce qu'il remplace la fenêtre de l'éditeur TinyMCE. Je ne m'attendais pas à ce qu'il prenne en charge l'intégralité de la page de l'éditeur de publication, en fonction du plan de la page du plugin.

Des utilisateurs inquiets me posent toutes sortes de questions sur ce que cela signifie pour leur site, auxquelles je ne peux pas répondre clairement pour le moment.

La page du plugin mentionne qu'il s'agit d'un logiciel bêta, mais je contesterais qu'il s'agisse au moins du début de l'Alpha. Cela me rappelle les premiers sites dotcom qui affichaient le petit graphique "Bêta" dans le coin du navigateur pendant les 2 années suivantes, leur permettant essentiellement de s'en tirer sans définir ni tracer ce qu'ils faisaient, permettant ainsi à l'expérience utilisateur de varier considérablement.

De Wikipédia

La phase bêta commence généralement lorsque le logiciel est complet mais contient probablement un certain nombre de bogues connus ou inconnus

Gutenberg est loin d'être complet à mon avis (il suffit de regarder toute la saga iframe).

Des gens sont venus me voir lors de la rencontre suivante, paniqués, car lorsqu'ils ont installé Gutenberg, ils ont "perdu" beaucoup de leurs données de publication (méta-boîtes, etc.). Ce n'est pas une bonne position pour mettre des gens dans un logiciel bêta.

@rickgregory a mentionné dans son article que l'API REST était un plugin de fonctionnalité pendant des siècles jusqu'à sa fusion dans le noyau. Il semble presque que Gutenberg suive la méthodologie opposée et soit martelé dans la prochaine version de WordPress, que les utilisateurs le veuillent ou le veuillent ou non.

En tant que personne qui développe des sites Web pour les entreprises locales, j'ai eu beaucoup de mal à comprendre la portée et la vision du projet Gutenberg. J'ai pleinement soutenu le besoin d'un meilleur éditeur, mais pendant longtemps, j'ai trouvé les blocs pour tout message sortant de l'équipe extrêmement déroutants.

L'équipe Gutenberg a compris ce que signifiait un bloc, mais en tant qu'utilisateur/développeur regardant de l'extérieur, je ne pouvais pas le saisir. Je suis tombé par hasard sur le post « Gutenberg, ou le navire de Thésée » l'autre jour et c'est la première chose que j'ai lue qui m'a fait comprendre à quel point les blocs pouvaient être une bonne chose. Mais je ne suis tombé sur le post que par hasard.

Un document définitif décrivant la vision et la portée du projet contribuerait grandement à répondre aux préoccupations de la communauté dans son ensemble.

J'ai parlé à beaucoup de développeurs qui ont franchement peur pour leur avenir en ce moment. Ils ne savent pas s'ils vont devoir revenir en arrière et apporter de gros changements à tous les sites/thèmes/plugins qu'ils ont développés dans le passé. Ils ont peur de se lancer dans de gros projets en ce moment, au cas où ils devraient refaire tout leur travail lorsque la 5.0 sortira. Ils ne savent pas quand ni comment ils vont devoir former leurs clients à l'utilisation de Gutenberg. Ils ne savent pas quand ni comment apprendre à se développer avec Gutenberg. Beaucoup d'entre eux ont peur que leurs clients ne veuillent pas continuer à utiliser WordPress, et ils envisagent d'apprendre d'autres CMS ou de migrer leurs clients vers SquareSpace. Il est fort possible que toutes ces craintes soient infondées, mais ils n'ont aucun moyen de savoir d'une manière ou d'une autre. Un aperçu clair de la portée, des objectifs et du calendrier de Gutenberg aiderait les développeurs à planifier leur avenir et les rassurerait sur le fait qu'eux et leurs clients peuvent continuer à utiliser WordPress.

Donc tout le monde pense que c'est une bonne idée et serait très bénéfique. La seule chose qui reste est la question de savoir qui va l'écrire et quand ? Je proposerais de le faire mais je ne suis pas un codeur et il faut vraiment que le développeur de Gutenberg Central soit capable de décrire et de mettre en page correctement tous les détails. Bien que je propose tout de suite de m'impliquer dans tout ce qui concerne les aspects marketing, ce qui est ma force.

Je peux signaler qu'il y a quelques mois, une demande a été adressée à l'équipe marketing de WordPress pour créer un plan promotionnel pour Gutenberg. Il a été affrété et discuté, mais mis en attente, car certains d'entre nous pensaient qu'il était prématuré et étrange de promouvoir un plugin bêta auprès des utilisateurs finaux sans plus de clarté sur tout cela. Pour moi, cela soulève un problème de produit par rapport à la portée du projet, ou un panier avant les chevaux, ou une autre analogie. Point étant : le produit a besoin d'une feuille de route avec une portée de projet d'accompagnement.

@Skarjune - d'une manière étrange, il est logique qu'ils aient essayé de le faire dans le mauvais sens. Et confirme quelque peu ce qui semble être le sentiment général sur la façon dont le projet est mené. Quoi qu'il en soit, celui qui l'écrit, il doit être écrit le plus tôt possible. Trop de questions ouvertes amènent les gens à partir dans leur propre direction.

J'ai apprécié la présentation de Morten sur Gutenberg au WordCamp Seattle le week-end dernier qui, à ma propre surprise, a changé mon attitude vis-à-vis du projet dans son ensemble.

Il a également encouragé tout le monde à participer au projet, c'est pourquoi je prends le temps de commenter ici.

Définir les objectifs et la portée n'est jamais une mauvaise idée pour rassurer les gens. On dit souvent que WordPress n'a pas un problème d'acquisition mais un problème de rétention. Gérer les attentes au sein de la communauté des développeurs et parmi la mêlée (y compris moi-même) dans l'Open Source Bazaar n'est jamais une mauvaise chose.

Les malentendus conduisent à la confusion qui conduit à l'épuisement professionnel.

Merci pour tout votre travail acharné sur ce projet et pour tous ceux qui construisent des projets incroyables que nous aimons tous tellement.

Je voulais juste laisser une note ici pour dire tout d'abord, merci pour les commentaires et l'engagement de tout le monde. À l'heure actuelle, nous avons quelques ressources réparties :

Page de destination/marketing : http://wordpress.org/gutenberg

Lisez-moi : https://github.com/WordPress/gutenberg/blob/master/README.md

Docs : https://wordpress.org/gutenberg/handbook/ (maintenant récemment avec une meilleure URL).

Nous pouvons faire mieux et vous êtes entendu. Je voulais passer et m'assurer que vous le saviez.

J'ai deux suggestions, la première est déjà en cours d'élaboration. Actuellement, deux de ces ressources sont en cours d'itération ; http://wordpress.org/gutenberg et le fichier readme du projet. Les itérations incluront un focus sur ce qu'est et sera Gutenberg, en ajoutant des liens et des ressources, en prenant note de ce qui a été dit ici et au sein de la communauté. Si possible, donnez-nous juste une semaine pour le faire, car cela devrait au moins fournir du contenu sur lequel itérer. J'espère que ce sera un bon point de départ pour la prochaine étape dans la communication de cela.

Deuxièmement, je veux entendre ce que vous pensez tous être idéal ici. Qu'est-ce que tout le monde veut exactement voir produit? Quels formats fonctionnent ? Ces pages suffiraient-elles ? Quel serait pour vous tous le format que vous voudriez idéalement ?

Je sais que c'est difficile à dire pendant que ces pages sont travaillées, mais je veux m'assurer que tout est pris en compte pour passer à l'étape suivante. Une fois ceux-ci terminés, j'aimerais que davantage de personnes aident à améliorer nos ressources et notre documentation. Je les lierai ici lorsque cela arrivera pour commencer à travailler avec ceux qui se sont mobilisés pour aider. Merci tout le monde.

Il y a deux formats qui, je pense, seraient utiles en conjonction:
1) Une feuille de route montrant une liste des fonctionnalités/étapes qui seront en place avant la sortie de Gutenberg, avec au moins de vagues indications sur le moment où ces choses devraient se produire.
2) Une section FAQ avec des réponses à des questions telles que « Y aura-t-il un support metabox ? », « Dois-je réécrire mes plugins et thèmes pour qu'ils soient compatibles avec Gutenberg ? et "Puis-je revenir si Gutenberg casse mon site ?" Les réponses aux questions courantes aideraient vraiment à soulager l'anxiété.

En ce qui concerne l'emplacement de ces documents, je pense qu'au moins un lien vers eux à partir de la page marketing est logique. Il est également judicieux de placer les documents là où ils sont le plus susceptibles d'être conservés et mis à jour régulièrement. Si mettre ce contenu sur la page marketing est un obstacle à sa mise à jour, alors il devrait aller là où il est le plus susceptible de rester à jour, avec des liens sur la page marketing.

@wpalchemist Votre (1) est au centre de ce numéro avec des fonctionnalités et des jalons clarifiés.
Pour (2) le projet a déjà cela dans GitHub :
https://github.com/WordPress/gutenberg/blob/master/docs/faq.md
@karmatosed a montré qu'il existe de bonnes ressources à la fois là-bas et sur WordPress.org, et oui, ce serait bien de les avoir entièrement indexées sur la page principale :
http://wordpress.org/gutenberg

@Skarjune Merci pour le lien FAQ ! Nous devons rendre cela plus facile à trouver. :)

Bon point à propos de la page FAQ, permettez-moi de m'assurer que cela entre dans la première itération des changements dont j'ai parlé. Merci d'avoir donné votre avis. Cela illustre que beaucoup de ces informations sont là, il s'agit de les faire apparaître, donc un bon point pris.

Voici mes suggestions immédiates :

  1. Créez un document de présentation du projet complet avec les objectifs actuels et futurs, les échéanciers et les décisions clés, y compris les structures de données conservées, les structures de données ajoutées et ce à quoi les concepteurs et les développeurs doivent se préparer.
  2. Créez un wiki complet semblable à WP-API.org avec une documentation complète fournissant des documents actuels et des documents vides/nécessaires aux contributeurs pour expliquer clairement à tout le monde ce qui existe et ce qui doit être construit.
  3. Étendez la FAQ pour répondre aux questions des administrateurs, des concepteurs et des développeurs

Il y a des commentaires ci-dessus avec des suggestions sur ce qui devrait être ici. Les miens sont sur https://github.com/WordPress/gutenberg/issues/3354#issuecomment -342310592 et en général, je pense que le commentaire de Mor10 juste au-dessus est pertinent.

J'aimerais voir ce qu'il y aura dans la première version, la deuxième, etc. En d'autres termes, alors que l'objectif final de Gutenberg pourrait être beaucoup de choses, quelle est la liste des fonctionnalités de la première version ?

De plus, je pense qu'il est important d'avoir une liste des problèmes ouverts ET des problèmes fermés importants. Je dis cela parce que certaines de mes préoccupations sont fonctionnelles - comment les métaboîtes seront-elles prises en charge, etc. - mais certaines sont également centrées sur le fait que tant de choses sont indéfinies et incertaines.

À mon avis, Gutenberg est axé sur les blogs et cela pourrait en fait être un ajout intéressant pour les blogs.

D'après l'image ci-dessous qui est prise directement sur le site de Gutenberg :
image

Ajouter un titre
Écrivez votre histoire

Les sites qui ne sont pas utilisés comme blogs, mais comme sites d'entreprises, de commerce électronique, d'annonces, d'emplois, de bases de connaissances, de restaurants, d'écoles, et la longue liste s'allonge encore et encore, n'écrivez pas d'histoires .

Gutenberg est donc totalement inutile pour ce type de sites et en gardant à l'esprit que ce sont aussi les sites typiques qui utilisent des métadonnées, l'équipe de développement derrière cette monstruosité devrait à mon avis commencer à voir la lumière sur celui-ci et le garder en tant que plugin ou s'il est plié dans Core, ne le rendre actif que sur le type de publication Post par défaut.

S'appuyant sur le commentaire de @Rarst ci-dessus, j'aimerais voir des communications qui expliquent mieux comment l'approche adoptée dans le développement de Gutenberg s'oppose à la philosophie de WordPress lui-même.

L'un des principes clés de WordPress a été de se concentrer sur la compatibilité descendante. Les discussions autour des métabox, les délais imprécis, etc. m'ont fait penser à diverses conversations au fil des ans autour de la mise à niveau de la version PHP requise par WordPress. Pour citer Andrew Nacin dans l'une de ces discussions autour du passage de la 5.2 à la 5.3 : « ce n'est vraiment pas dans notre meilleur intérêt de « jouer le jeu » au détriment de nos utilisateurs. Des dizaines de millions d'utilisateurs seraient affectés - et potentiellement bloqués, ou Je me demande certainement pourquoi WordPress les met au milieu de tout cela - tout cela pour des raisons. C'est complètement idiot. C'est aussi le genre de mouvement que WordPress pourrait faire qu'une solution de blog hébergée ou alternative aimerait voir se produire. " Ce n'est qu'un exemple de quelque chose que les gens attendent et apprécient de WordPress en tant qu'écosystème : WordPress progressera mais pas aux dépens de ses utilisateurs.

Il existe un certain nombre de pratiques de développement modernes que j'aimerais voir se produire dans WordPress, mais j'ai respecté cette philosophie particulière qui a sécurisé les utilisateurs dans le fait qu'ils peuvent souvent passer à la dernière et à la meilleure sans craindre de casser leurs sites.

Cela dit, bien que j'aie lu que les principaux contributeurs de Gutenberg mentionnent qu'ils ont en tête "l'utilisateur de longue date de WordPress", je ne vois pas le lien et j'aimerais en savoir plus sur la façon dont Gutenberg fera cela. Personnellement, je suis très enthousiasmé par Gutenberg en tant que remplaçant de l'éditeur, et je pense que l'équipe de développement devrait être félicitée pour nombre de ses efforts dans cet espace.

Cependant, au fur et à mesure que je lis les conversations liées au remplacement de l'intégralité de l'écran d'édition de publication/page, je deviens de plus en plus nerveux. De nombreuses demandes bien motivées pour adopter une approche plus méthodique de la sortie de Gutenberg ont été accueillies avec des réponses telles que :

  • De telles approches ne sont pas conformes à la vision du projet
  • Il ne sera pas publié tant qu'il ne sera pas prêt.

Ce sont honnêtement des non-réponses car elles ne nous disent rien. Premièrement : pourquoi une approche par étapes consistant à publier d'abord un éditeur, puis à se concentrer sur le reste de l'écran d'édition une fois que les développeurs et les utilisateurs se sont habitués au nouveau look, va à l'encontre de la vision du projet ? Il semble plutôt que la crainte soit que cela aille à l'encontre d'un calendrier arbitraire qui a été implicitement défini autour de ce projet. Et deuxièmement : quelle est la date de préparation prévue ? "Parfois en 2018", comme l'indique la FAQ actuelle, n'est pas du tout une réponse. Quels sont les paramètres par lesquels « prêt » sera défini ? Comme l'ont indiqué les commentaires initiaux de @ mor10 , nous avons vraiment besoin de détails ici. L'absence d'un calendrier clairement défini avec des jalons dans ce projet contribue sérieusement à beaucoup d'anxiété ici. Ce serait formidable de voir une communication qui détaille clairement comment la sortie de Gutenberg est consciente du principe de base de WordPress de compatibilité descendante afin de ne pas mettre en danger les millions d'utilisateurs qui l'utilisent actuellement sur leurs sites - avec une compréhension que les variations sur « faites-nous confiance » ne sont pas vraiment une réponse.

Premièrement : pourquoi une approche par étapes consistant à publier d'abord un éditeur, puis à se concentrer sur le reste de l'écran d'édition une fois que les développeurs et les utilisateurs se sont habitués au nouveau look, va à l'encontre de la vision du projet ?

Parce qu'il n'y a probablement pas assez de ressources pour travailler sur une direction aussi isolée en plus de la direction combinée. S'il s'avère plus tard que la direction réservée à l'éditeur ne fonctionnera tout simplement pas pour l'ensemble, qu'allez-vous faire ? Combien de ces cycles d'essais et d'erreurs pensez-vous que la base d'utilisateurs sera capable de supporter ? C'est une stratégie ratée au départ.

L'impact ici est si énorme, c'est pourquoi il y a peu de place pour autre chose qu'une stratégie "tout ou rien".

Parce qu'il n'y a probablement pas assez de ressources pour travailler sur une direction aussi isolée en plus de la direction combinée.

Les ressources limitées sont précisément la raison pour laquelle une approche progressive a du sens. Notre approche devrait être de réduire les coûts irrécupérables en validant les progrès à des points de contrôle prédéfinis en cours de route, en commençant par l'éditeur.

Au lieu de cela, nous avons un petit nombre de développeurs capables qui se concentrent sur des priorités dispersées, tandis qu'il est demandé à la communauté d'avoir confiance que la vision globale se concrétisera à la fin d'un calendrier incertain. En conséquence, chaque version ressemble à une liste de fonctionnalités plutôt qu'à une progression vers un jalon.

@lkraav - Je pense que vous ne comprenez pas le point. Il n'y a pas de "direction isolée" proposée, mais un raffinement par étapes.

À l'heure actuelle, la proposition est que Gutenberg prenne en charge l'intégralité de l'écran d'édition. Ce qui a été demandé à plusieurs reprises, c'est pourquoi il ne peut pas simplement remplacer la partie éditeur de l'écran dans sa première version, de plus en plus pour prendre en charge plus d'édition immobilière au fil du temps. Cela présente quelques avantages :

1) Il habitue les utilisateurs à une expérience d'édition de blocs d'une manière limitée mais utile. Dans le même temps, il réduit l'étendue des travaux permettant de livrer cette première phase relativement rapidement.
2) Cela évite d'avoir à résoudre les problèmes de la boîte méta (et d'autres?)
3) À la suite de #1, il obtiendra l'équipe du monde réel retour sur UX et comment un éditeur de blocs est reçu par les vrais utilisateurs finaux. Cela peut aider à orienter les futurs travaux de conception avant que tant de choses n'aient été faites.

Une phase suivante pourrait s'attaquer, par exemple, au problème de la méta-boîte et étendre l'ensemble des fonctionnalités. Cela pourrait continuer jusqu'à ce que la vision entière soit livrée.

À terme, Gutenberg remplacerait tout l'écran d'édition mais, bien fait, cette approche évite les risques du tout ou rien, le fait parfaitement ou casse mal les choses .

Enfin, je pense que nous devons examiner cela dans un cadre plus large. Dans cinq ans, l'une ou l'autre approche aura probablement livré une expérience Gutenberg finie et robuste. Est-ce vraiment important si ce point survient dans 2 ou 3 ans ? Quand on parle d'un acteur dominant comme WP, je pense que cela n'a pas d'importance. En fait, une certaine prudence est préférable - WP n'a pas besoin de se démener pour rattraper un leader du marché puisqu'il est le leader du marché. Ce qui serait désastreux, c'est de se précipiter sur une solution qui casse les sites, compromet la capacité des agences de première ligne à fournir des solutions robustes et plus encore, le tout au service d'une vision de conception rigide que l'équipe n'envisagera pas de modifier.

Tout d'abord @lkraav , j'apprécie la réponse et j'apprécie complètement la tâche gargantuesque que l'équipe de Gutenberg a entreprise. Je pense que nous sommes tous d'accord pour dire que l'impact est énorme.

Là où je diffère de votre conclusion, c'est qu'il s'agit d'un binaire "tout ou rien". Comme le déclare @rickgregory , se concentrer sur l'éditeur ne vire pas dans une direction différente, mais constitue une étape vers la réalisation de la vision que votre équipe s'est fixée. Je pense que cela est particulièrement pertinent étant donné que le seul avantage tangible pour les utilisateurs de WordPress identifié dans la FAQ et d'autres documentations à l'heure actuelle se concentre uniquement sur l'éditeur de contenu - et non sur l'intégralité de l'écran d'administration.

Je dirai que lorsque j'entends "tout ou rien", c'est un peu un signal d'alarme pour moi, car c'est très rarement quelque chose qui coupe et sèche. L'hypothèse selon laquelle un éditeur de bloc de contenu ne peut pas fonctionner en tant que composant autonome à moins que tous les autres aspects de l'écran d'administration ne soient également sous le contrôle d'une instance de réaction centrale rend cela encore plus inquiétant.

Il semble y avoir cette hypothèse que WordPress est cassé et nous devons faire ce changement pour survivre. Si oui, s'il y a ce besoin impérieux de retravailler complètement WordPress, pourquoi n'y a-t-il pas eu plus d'intérêt à essayer le plugin ? L'écosystème des plugins nous a montré que les utilisateurs qui estiment que WordPress ne répond pas à un besoin particulier n'hésitent pas à ajouter des plugins à leur site. Et pourtant, nous en sommes à 3000 installations à ce jour. Vous pouvez dire "Eh bien, c'est parce que les gens ne veulent pas mettre de plugin bêta dans leur site"... et vous avez probablement raison. Mais j'espère que vous pouvez comprendre pourquoi nous sommes impatients de passer d'un plugin bêta (avec une utilisation de production mineure au mieux) immédiatement au noyau autour de quelque chose qui change fondamentalement WordPress.

Le fait que les échéanciers ne peuvent pas être spécifiés rend cela d'autant plus déroutant. J'apprécie le défi que les développeurs de Gutenberg ont relevé, et si vous me dites que "tout" est la seule solution acceptable et que vous prendrez le temps nécessaire pour bien faire les choses, c'est très bien. Cependant, la version 5.0 est déjà prévue comme la prochaine version... donc soit elle est prête à être fusionnée, soit vous vous dirigerez vers une échéance qui a été fixée artificiellement sans comprendre clairement si vous pouvez même faire fonctionner "tout" pour "tous". Utilisateurs de WordPress. Dans le cadre de votre projet, je suis curieux de savoir quand Gutenberg sera-t-il suffisamment stable pour que les développeurs commencent à examiner l'impact que cela aurait sur leurs plugins et thèmes ? Combien de temps seront accordés à ces développeurs pour se préparer à Gutenberg ? Si vous ne pouvez pas encore répondre à ces questions, je ne comprends pas comment vous pouvez envisager de fusionner cela dans le noyau au cours des 12 prochains mois.

Je dirai que quand j'entends "tout ou rien", c'est un peu un drapeau rouge pour moi...

Je n'ai rien à voir avec la définition de la direction sur Gutenberg, donc pas besoin de lever des drapeaux à cause de tout ce que j'écris. Juste interpréter le monde ici avec le reste d'entre vous, agrémenté de quelques décennies d'expérience en développement de logiciels. J'ai de vrais clients et des entreprises personnelles qui bourdonnent sur WordPress, et le paradigme d'édition Visual HTML brisé avait déjà atteint ses limites avec moi il y a quelque temps. Je vois exactement quelles améliorations Gutenberg (ou le modèle, tel que nous le connaissons aujourd'hui) peut apporter à mes processus et je l'accueille à bras ouverts, en contribuant ce que je peux au noyau et au processus Gutenberg.

Pour le sujet : tout le monde peut parler d'« itératif » ou de « tout compris » autant qu'il veut, y compris moi, mais les mots + les souhaits ne coûtent pas cher et proposer suffisamment de pull request de qualité pour prouver la faisabilité d'un choix de direction est ce qui compte.

Je n'ai tout simplement vu personne d'autre mettre les ressources nécessaires pour travailler sur ces idées d'orientation alternative assez rapidement, donc à la fin de la journée, ceux qui fournissent les ressources passeront les appels d'une manière ou d'une autre. Compréhensible, car c'est cher comme l'enfer de participer à un grand détail (au niveau du code) et au niveau d'expertise requis.

Et puis nous devrons simplement voir comment cela se passe et essayer d'influencer les choses avec nos exigences dans le cadre d'une direction stratégique choisie. Certes, je ne suis pas quotidiennement la liste des relations publiques (trop grande), mais l'équipe de Gutenberg a déjà déclaré publiquement qu'elle accueillait toutes les contributions. Tout changement de direction ne se produira que si quelqu'un s'efforce de comprendre la technologie, assez rapidement. « ans » n'est probablement pas un délai raisonnable pour assembler les pièces.

C'est pourquoi je prédis (je ne suggère pas, ni ne souhaite spécifiquement, etc.) que la direction "tout" continuera. L'hypothèse personnelle ici est que quoi qu'il arrive, je serai capable de comprendre les choses pour mes affaires et les clients que je sers, car même le modèle actuel semble assez prometteur. Cela pourrait certainement être prouvé faux.

Je n'ai tout simplement vu personne d'autre mettre les ressources nécessaires pour travailler sur ces idées d'orientation alternative assez rapidement, donc à la fin de la journée, ceux qui fournissent les ressources passeront les appels d'une manière ou d'une autre. Compréhensible, car c'est cher comme l'enfer de participer à un grand détail (au niveau du code) et au niveau d'expertise requis.

C'est précisément là que ce genre de projet échoue – et ce en particulier. Incapacité à comprendre que la capacité de contribuer à une bonne solution n'est pas – ne peut pas – être proportionnelle à la capacité à écrire du code. Je dirais par contre que la capacité d'écrire du bon code est inutile (voire dangereuse) lorsque le codeur n'a pas une vision large des usages auxquels son code doit répondre.

WordPress est ce qu'il est en raison de sa flexibilité et de son extensibilité, car il est attrayant pour les développeurs, qui peuvent étendre ses fonctionnalités, et pour les auteurs et créateurs, qui n'ont pas besoin de connaissances élevées pour le façonner à leur manière. C'est aussi la raison pour laquelle WordPress est utilisé de différentes manières, pas seulement pour les blogs ou les sites centrés sur les histoires.

Lors de la conception d'une nouvelle façon de créer et de modifier du contenu, il est crucial que tous ceux qui contribuent à ce projet sachent qu'ils ne peuvent pas négliger cette flexibilité et cette extensibilité, l'utilisation de champs personnalisés, l'utilisation de types de publication personnalisés et d'autres formulaires. de gestion et d'interaction avec le contenu dans WordPress. Ce n'est pas secondaire, c'est le cœur de son succès.

Si cette nouvelle expérience d'édition n'est pas en mesure d'intégrer cette gamme complète d'utilisations, alors elle n'est pas prête à être publiée et ne devrait pas être publiée.

@lkraav --Pas de soucis... cela ne suggère certainement pas que vous êtes en quelque sorte responsable du binaire "tout ou rien". Je commentais juste cette conclusion particulière parce que j'ai lu des déclarations similaires dans d'autres fils de discussion et articles liés à Gutenberg. Et comme vous, j'accueille Gutenberg en remplacement de l'éditeur Visual HTML - aucun désaccord de ma part :)

Je voulais commenter les demandes d'extraction car cela indique un problème que @kevinwhoffman a soulevé dans sa réponse la plus récente sur ce fil. Je peux tout à fait comprendre la frustration que peuvent ressentir certains contributeurs à ce projet face au nombre limité de ressources de développement. Cependant, je pense aux conversations de ces derniers mois autour de l'adoption d'un framework JS pour WordPress qui se divise souvent entre Vue et React. L'une des principales raisons de la prise en charge de Vue JS était la baisse de la barrière d'entrée pour commencer. Ce projet a évidemment commencé avant cette discussion, mais veuillez comprendre que la barrière d'entrée plus élevée de React limitera évidemment le nombre de personnes pouvant contribuer à ce projet. L'équipe a décidé d'elle-même d'utiliser React, ce qui est bien, car elle fait actuellement le gros du travail ; mais l'équipe ne peut pas alors se plaindre si le nombre de contributeurs au projet n'est pas aussi élevé qu'elle le souhaiterait. Pour ma part, je travaille quotidiennement dans Vue et Angular dans un environnement d'entreprise, mais je n'ai jamais touché à React en raison de ses problèmes de licence BSD. En tant que tel, le temps de montée en puissance pour arriver à un point où je peux fournir une demande d'extraction de qualité dans React semble prohibitif sur la base (ce qui est à mon avis) d'un calendrier agressif.

Ajoutons simplement ici que wordpress.org/gutenberg et le fichier readme ont maintenant des mises à jour. Travaux en cours mais un pas dans la bonne direction.

Je ne vais pas supposer, parce que je ne sais tout simplement pas. Mais Automattic ou quelqu'un d'autre chez WordPress com/org a-t-il déjà commandé une étude de marché, ou étudié les métriques disponibles, pour pouvoir dire exactement comment WordPress est utilisé ?

Quel pourcentage l'utilise pour raconter des histoires et publier des articles sous forme de blog, et combien l'utilisent comme CMS pour présenter leur entreprise ou vendre sur leur boutique en ligne ? Et comment cela augmente/rétrécit/est-il projeté ?

J'aurais dû penser que cela pourrait être une contribution utile à cette discussion et nous aiderait à voir la nature appropriée de Gutenberg, ou non, à chaque modalité.

Est-ce que n'importe qui sait si ceci est disponible et peut nous tirer un lien ici ?

Merci Tammy ! Les sections wordpress.org/gutenberg et wordpress.org/gutenberg/handbook/ sont très utiles. Mais existe-t-il une feuille de route complète vers la version 5 de WordPress, comme j'ai entendu Matt Mullenweg sur le podcast WP Tavern cette semaine affirmer que Gutenberg sera livré en tant que noyau dans cela. Quand je regarde wordpress.org/about/roadmap/ tout ce qui est donné est :

Version : 5.0
Prévu : 2018
Le mois précédant une version, les nouvelles fonctionnalités sont gelées et l'accent est entièrement mis sur la qualité de la version en éliminant les bogues et en profilant le code pour tout problème de performances.

Le nœud de ce problème est que les développeurs sont particulièrement préoccupés par les délais, les extinctions de support et les dépréciations. À titre d'exemple, Drupal propose des délais LTS clairs :
https://www.drupal.org/core/release-cycle-overview

Terrence, je me suis penché sur une étude de marché cette année pour un projet Make WordPress Marketing. Il y avait eu des sondages informels de concepteurs, de développeurs et d'agences sur WordPress, mais rien de formel ni de concluant sur l'utilisation. Notre projet s'est concentré sur une enquête informelle des agences sur l'utilisation de WordPress, uniquement dans le but de développer du matériel de support pour les agences afin de commercialiser WordPress auprès des clients et pour envisager l'adoption par l'entreprise.

Bien que nous n'ayons pas eu beaucoup de succès, nous n'avons que des ressources bénévoles et n'avons pas eu d'exposition comme l'actuel « Avez-vous déjà participé au sondage WordPress 2017 ? » lien sur WordPress.org, mais nous avons obtenu des informations précieuses. Jetez un coup d'oeil s'il vous plait:
https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

@David Skarjune - merci, cela confirme à peu près ce que j'avais imaginé.
La plupart des organisations renoncent à cette étape car elle les met face à face
avec la réalité, plutôt que de les laisser faire ce qu'ils veulent, ou ce
est pire, ce qu'ils ont décidé de faire en fonction de la réaction intestinale et du passé
vivre. La question demeure donc. quelle serait la meilleure façon d'apporter
une certaine réalité dans cette histoire du projet Gutenberg back-to-front. Par
le chemin, je ne sais pas si je me souviens bien, si je viens de le rêver,
mais Gutenberg n'était-il pas l'un des bébés de Matt ? Si oui, je me demande quel était le
motivation et à quel point c'était "réel" ?

Le vendredi 1er décembre 2017 à 16h54, David Skarjune [email protected] a écrit :

Terrence, je me suis penché sur une étude de marché cette année pour un Make WordPress
Projet de commercialisation. Il y avait eu des sondages informels de designers,
développeurs, et agences sur WordPress, mais rien de formel ni de concluant
sur l'utilisation. Notre projet s'est concentré sur une enquête informelle des agences sur
Utilisation de WordPress, uniquement dans le but de développer du matériel de support pour
Agences pour commercialiser WordPress auprès des clients et pour l'examen de l'entreprise
adoption.

Bien que nous n'ayons pas eu beaucoup de succès, nous n'avons que des ressources bénévoles et
n'a pas eu une exposition comme l'actuel "Avez-vous pris le WordPress 2017
Survey encore ?" sur WordPress.org, mais nous avons obtenu des informations précieuses.
Jetez un coup d'oeil s'il vous plait:

https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348547816 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AD0dztdHtoNFHDbK2mNc_yma5n8O1GFpks5s8C8zgaJpZM4QTl13
.

>

https://qloudpress.com/
Écuries de Kypeside, Nether Kypeside
par Deadwaters, South Lanarkshire ML11 0JL
Téléphone : +44 (0)141-416-3322

ID de clé PGP : 18D7884E29597525
http://keyserver.pgp.com

@Skarjune - informations intéressantes, merci pour le lien. Ma principale préoccupation avec cette enquête en tant que guide de la communauté WP est la répartition de la façon dont les gens décrivent leurs rôles. Développeur... 30%. Créateur de contenu... 1%. Lorsqu'on leur a demandé combien de sites ils gèrent, 46% ont répondu 25 ou plus. Ce public est typique des agences, pas des personnes qui utilisent WP pour créer et gérer du contenu.

C'est une excellente ressource pour comprendre le point de vue des agences, mais il me semble que nous devons également comprendre le point de vue des personnes qui utilisent les solutions que nous construisons.

@rickgregory @TerenceMilbourn L'enquête était un petit groupe de discussion auto-sélectionné répondant à un appel ouvert promu sur WP-org, WP Tavern et les médias sociaux, pour guider WordPress Marketing. Il n'a pas été conçu comme un vaste véhicule de recherche WordPress, comme expliqué ci-dessous. Voici la répartition des répondants (Entreprise=Client) :

Agence : 58 69 %
__service​ ​WordPress​ ​pour​ ​clients 46 - 55 %
__fournir​ ​WordPress​ ​aux​ ​clients 12 - 14%
Entreprise : 18 21 %
__en utilisant​ ​WordPress​ ​avec​ ​Host 14 — 17%
__en utilisant​ ​WordPress​ ​avec​ ​Agence 4 — 5%
Entreprise : 8 10%
__Entreprise​ ​WordPress​ ​(réseau/cloud) 4 — 5%
__Hôte​ ​fournissant​ ​WordPress 4 — 5%

Ne dévions pas du sujet, mais permettez-moi de commenter la nécessité d'une feuille de route WordPress qui se concentre actuellement sur le projet Gutenberg.

L'enquête était mon idée en réponse aux idées générées par l'équipe marketing de la startup lors de la Journée des contributeurs WCUS 2016, en particulier pour le sous-groupe sur les clients et les agences que je préside maintenant. Mon intérêt était de vérifier auprès des agences sur l'utilisation de WordPress avant d'essayer de le promouvoir auprès d'autres agences.

Alors que les personnes interrogées ont obtenu des notes plus positives sur les raisons d'utiliser WordPress que sur les obstacles, la feuille de route (c'est-à-dire son absence) était un obstacle principal, c'est pourquoi je publie sur ce fil de discussion.

Oui, ce serait bien d'avoir une large perspective sur l'utilisation de WordPress, mais cela nécessiterait des ressources et un parrainage sérieux. Malheureusement, l'argument derrière Gutenberg semble être que les blogueurs ont besoin d'un système de construction de blocs à l'avenir, bien que je n'aie vu aucune preuve à ce sujet, ni pourquoi ce serait un facteur principal étant donné la vaste base d'utilisateurs et de cas d'utilisation

Personnellement, j'ai travaillé sur des projets de CMS d'entreprise pendant quelques années sur diverses plateformes, et les problèmes de workflow peuvent être complexes. Quant à l'éditeur, il est généralement personnalisé en fonction du flux de travail et varie selon le rôle de l'utilisateur, et le traitement par lots est également utilisé. Je n'ai jamais vu de question sur l'un ou l'autre sur quel éditeur est le meilleur. La meilleure référence sur certains d'entre eux est "Author Experience" de Rick Yagodich. J'ai parlé du sujet dans certains WordCamps au cours des dernières années, mais franchement, personne ne s'en souciait... maintenant, vous penseriez que cela avait de l'importance.

@Skarjune - OK, j'ai eu le temps de lire et de réfléchir au rapport maintenant, et
c'est vraiment un excellent document. Je peux voir qu'il y a eu beaucoup de travail acharné
cela et il fournit évidemment des retours et des validations substantiels.

Ma réaction serait, disons, en tant que client qui avait commandé le rapport,
qu'il est trop limité dans sa portée pour ce que nous voulons maintenant, car il
vise à recueillir les commentaires des agences et de la communauté des développeurs.

Afin d'essayer de comprendre exactement ce que devrait être Gutenberg, et comment il
devrait fonctionner, je pense que nous avons besoin d'une approche beaucoup plus tournée vers l'extérieur, afin que
nous commençons à comprendre la réaction, les intentions et les besoins du marché des utilisateurs finaux,
en ce qui concerne le type de contenu qu'ils souhaitent créer et gérer. Et
comment ils veulent faire ça.

C'est surprenant pour moi que la curiosité, à tout le moins, n'ait pas poussé
WordPress ou Automattic pour commander une étude de marché qui, à la
au moins, est capable de donner une ventilation définitive de la segmentation de l'industrie,
types d'organisations d'utilisateurs finaux, répartition des cas d'utilisation, etc. pour tous ses millions
des utilisateurs finaux.

Je veux dire, comment quelqu'un peut-il décider quoi construire, s'il ne sait pas qui il
le construisent pour?

Si nous ne comprenons pas ces principes fondamentaux, nous continuons à parler à
nous-mêmes, essentiellement, et renoncer à toute contribution substantielle du monde réel. Et
cela signifie que nous ne comprenons pas ce qui est vraiment nécessaire là-bas, et pourrait
continuez simplement à construire quelque chose que les développeurs pensent être un chouette
Solution.

Mais une solution à quoi ? C'est la vraie question.

Avec la possibilité de « pousser » un questionnaire à des millions d'utilisateurs finaux via le
Tableau de bord WordPress, par exemple, nous pourrions, si nous voulions vraiment
comprendre ce dont ont besoin les personnes qui utilisent cet outil au quotidien
base ~ en fonction des besoins au sein de l'écosystème WordPress ~ prendre une
un échantillonnage vraiment global d'opinions et développer une certaine définition du marché,
la taille du segment et d'autres mesures sur lesquelles construire les objectifs futurs et
Planification.

Un questionnaire et une méthodologie bien pensés pourraient être extrêmement
utile, tant que le projet n'a pas été autorisé à aller trop loin.

Comment ferions-nous pour faire quelque chose comme ça. Pourrions-nous faire quelque chose comme
cette?

Le vendredi 1er décembre 2017 à 20h01, rickgregory [email protected] a écrit :

@Skarjune https://github.com/skarjune - informations intéressantes, merci
pour le lien. Ma principale préoccupation avec cette enquête en tant que guide du WP
la communauté est la décomposition de la façon dont les gens décrivent leurs rôles. Développeur...
30%. Créateur de contenu... 1%.

J'ai l'impression que nous devons comprendre la perspective non seulement de
les gens qui construisent des solutions mais de ceux qui utilisent les solutions que nous construisons.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348600347 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AD0dzqdI4q0CIp4ViLLF6duied048AhEks5s8FsugaJpZM4QTl13
.

>

https://qloudpress.com/
Écuries de Kypeside, Nether Kypeside
par Deadwaters, South Lanarkshire ML11 0JL
Téléphone : +44 (0)141-416-3322

ID de clé PGP : 18D7884E29597525
http://keyserver.pgp.com

@TerenceMilbourn Il y a des tests d'utilisabilité Gutenberg, donc c'est utile avec l'appel pour une feuille de route plus claire. La télémétrie a été discutée pour WordPress, mais cela devient compliqué, tout comme une recherche massive. Ainsi, comme pour Gutenberg, l'accent mis actuellement sur la convivialité et la feuille de route nous aidera à déterminer s'il est approprié de lancer début 2018 pour la version 5.

Si vous avez des idées ou des suggestions supplémentaires, veuillez rejoindre le canal Make WordPress Marketing Slack : https://make.wordpress.org/marketing/

Deux objectifs pour 2018 sont

Édition Gutenbergpersonnalisation Gutenberg

Y a-t-il une mise à jour sur le problème d'origine? Concrètement ceci :

Une seule ressource expliquant
a) pourquoi Gutenberg existe (une version simplifiée du post de
b) où il se dirige (objectifs finaux + grande vision),
c) pourquoi le projet se concentre actuellement sur l'éditeur, et
d) que le focus de l'éditeur est le premier élément constitutif d'un plan plus vaste

J'ai cherché aujourd'hui un document de feuille de route et je n'en ai pas trouvé.

@ mor10 , cela a été examiné lors du nettoyage des bogues Gutenberg d'aujourd'hui, nous aimerions obtenir vos commentaires sur wordpress.org/gutenberg et le README.md de ce

@jeffpaul Pour commencer, il n'y a pas de feuille de route. Personne ne fournira de réponse claire quant aux fonctionnalités que Gutenberg aura lors de sa première publication et/ou quelles fonctionnalités seront dans les révisions ultérieures.

Oui, Gutenberg a ajouté une bonne documentation. Mais, comme certains l'ont noté, il n'y a pas de feuille de route de développement utile, par rapport à Drupal par exemple. Bien qu'il y ait un suivi détaillé du développement, où est la feuille de route de haut niveau ?

Une grande préoccupation est le soutien à long terme. Il a été dit que la version 4.9.x serait corrigée après le lancement de la version 5.x, et cela a toujours été le cas :
https://codex.wordpress.org/WordPress_Versions

Étant donné qu'il est fortement conseillé à la communauté d'aller de l'avant avec la version 5.0, les versions héritées continueront-elles à être corrigées et pour combien de temps ?

On craint que le chemin de l'héritage puisse être déroutant. Le plugin Classic Editor est proposé en tant que solution partielle, mais cela nécessite également Gutenberg et quelques configurations supplémentaires. L'objectif de LTS est d'assurer un chemin sûr pendant quelques années, lorsque les mises à niveau complètes vers les nouvelles technologies ne sont pas justifiées ou budgétées.

@maddisondesigns @Skarjune faute d'un document de feuille de route que vous appelez, il y a au moins la liste des étapes à venir pour Gutenberg.

@Skarjune d'après mon expérience, qui est de moins de 2 ans de bénévolat avec le noyau WordPress, les correctifs sont revenus à 3.7.x. Je pense qu'il est réaliste de s'attendre à ce que le correctif si lointain ne dure probablement pas éternellement, mais il est encore plus réaliste de s'attendre à ce que toute décision à ce sujet se produise lors de réunions ouvertes dans Slack avec des mises à jour publiées sur Make/Core.

@jeffpaul Honnêtement, c'est surtout inutile. Tout ce qui fait est essentiellement de fournir des liens vers les différents jalons Gutenberg marqués. Non seulement cela n'inclut qu'une très petite partie des problèmes qui ont été marqués avec un jalon, mais il est très facile pour quiconque de modifier simplement les jalons, s'il le décide. A quoi sert une feuille de route si vous pouvez simplement changer tous les jalons la veille de la sortie du projet, si vous en avez envie ?

Il doit y avoir une feuille de route de projet appropriée (en anglais simple), décrivant toutes les fonctionnalités qui seront disponibles dans Gutenberg à partir du WP5.0, ainsi que les fonctionnalités qui seront poussées vers les versions suivantes (5.1, 5.2, etc. ..). Pour le moment, personne en dehors du projet Gutenberg n'a la moindre idée de la fonctionnalité à laquelle il peut s'attendre, une fois qu'elle sera enfin dans le noyau, et personne ne fournira de réponse lorsqu'on lui demandera. Tout ce qu'on nous dit, c'est que "_Gutenberg sera livré avec WordPress 5.0, mais la version sortira lorsque Gutenberg sera prêt, et non l'inverse_".

Qui décide quand Gutenberg est « prêt » ? Comment prennent-ils cette décision ? Qui décide quelles fonctionnalités sont publiées dans le noyau ? Qui décide des fonctionnalités de la première version et de la suivante ? Il est évident que personne en dehors des développeurs principaux de Gutenberg ne sera impliqué dans cette décision. Il est ridicule que le projet ait duré aussi longtemps sans qu'aucune portée ou feuille de route ne soit définie, ce qui signifie également qu'il y a eu peu ou pas de discussion avec la communauté WP sur les fonctionnalités que les gens veulent réellement voir dans cette chose.

@jeffpaul Merci pour l'info ! C'est utile, mais plus encore pour le processus de développement interne et les parties intéressées, pas tellement pour les parties externes qui planifient l'architecture et le support du système, à court et à long terme.

Par exemple, les jalons de version Drupal et LTS sont très spécifiques :
Feuille de route de développement Drupal
Cycle de publication du noyau Drupal : versions majeures, mineures et correctifs

Joomla, d'autre part, bafouille un peu sur leur nouveau framework 4.0, ce qui n'augure rien de bon pour le projet compte tenu de leurs problèmes de version passés :
Joomla !

Ainsi, malgré les débats sur Gutenberg, et dans l'esprit de « Fournir un aperçu en langage clair de la portée, de la direction et des objectifs du projet », une feuille de route détaillée et un calendrier LTS feraient une grande différence, en particulier pour les camps d'agences et d'entreprises. Merci pour ton aide!

Il y a beaucoup d'informations, ainsi que l'énoncé de mission de Gutenberg ( Tout est un bloc ), dans le README du projet.

Bien que je pense qu'il y ait de bonnes idées dans ce numéro, le problème est devenu assez accablant avec de nombreuses voix différentes, différentes questions et différents buts/objectifs.

L'équipe Gutenberg a répondu/continue de répondre à de nombreux commentaires dans ce numéro. L'un des points communs que je vois ici est l'inquiétude concernant la feuille de route/la compatibilité ; Je pense qu'il est important de se rappeler que WordPress 5 prévoit d'être livré avec Gutenberg, mais les utilisateurs peuvent toujours se rabattre sur le "Classic Editor", nous ne devrions donc pas laisser les utilisateurs bloqués.

Je vais fermer ceci parce que je ne pense pas que ce soit un problème pouvant donner lieu à une action. Cela ne veut pas dire que quelque chose/tout ici est faux ou qu'il n'y a pas d'éléments pouvant donner lieu à une action. En général, il y en a trop pour considérer facilement ce problème comme « clos ».

Qu'avez-vous fait avec WP Tavern !!?? Je viens lire les actualités de WP et tout le portail est au service de la propagande de Gutenberg. Laisse-moi tranquille.

Oui, je connais la réponse. Vous n'êtes pas associé à eux.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

maddisondesigns picture maddisondesigns  ·  3Commentaires

franz-josef-kaiser picture franz-josef-kaiser  ·  3Commentaires

moorscode picture moorscode  ·  3Commentaires

mhenrylucero picture mhenrylucero  ·  3Commentaires

pfefferle picture pfefferle  ·  3Commentaires