Gutenberg: プロジェクトの範囲、方向性、および目標のわかりやすい概要を提供する

作成日 2017年11月06日  ·  53コメント  ·  ソース: WordPress/gutenberg

問題を投稿する前に:-問題を送信すると、これらのコメントは表示されません。 -できるだけ詳細を追加してみてください。 具体的に! -説明に使用しているグーテンベルクのバージョンを追加してください-新機能をリクエストする場合は、追加する理由を説明してください。 -このリポジトリで問題を検索し、問題が修正されているか、すでに報告されているかどうかを確認します。 -バグをログに記録する前に、最新のコードを使用していることを確認してください。 -すべてのプラグインを無効にして、プラグインの競合の問題ではないことを確認します。

問題の概要

私の観察では、この情報を含む単一の信頼できる平易な言語リソースがないため、コミュニティはグーテンベルクプロジェクトのより広い範囲を見るのに苦労しています。 これは、すべての関係者からの高度な憶測、誤解、およびフラストレーションを生み出し、結果としてプロジェクトは苦しみます。

グーテンベルクプロジェクトには、わかりやすい言語の範囲とプロセスのドキュメントが必要です。最終目標は何ですか(ビュー内のすべてがブロックです)、そこに到達する方法(エディターから始まる段階的なリリース)、そしてそれは将来に何を意味しますかさまざまなWordPressコンポーネント(ショートコード、メタボックス、フィールドなど)のこの情報のすべて(またはほとんど)は、個別のコメント、プルリクエスト、ブログ投稿、Slackの更新、およびその他の衛星情報として存在しますが、私とより広いコミュニティの知る限り、すべての要素がまとめられた単一の正規のリソースはありません。わかりやすいわかりやすい言葉。

再現手順(バグの場合)


  1. ソーシャルメディア/ブログでのグーテンベルクの議論。
  2. 「iframeはメタボックスの実行可能な長期ソリューションですか?」での議論 #3304
  3. グーテンベルクバブルの外にいるWordPressユーザーに「グーテンベルクとは何ですか?」と尋ねます。 そして「グーテンベルクは最終的に何になるのだろうか?」

予想される行動



グーテンベルクプロジェクトに精通している(ただし必ずしも貢献しているわけではない)人は、a)グーテンベルクが現在何をしていて、それがすぐにどのように影響するか、b)グーテンベルクがどこに向かっているのかを明確に把握している必要があります。

現在の動作


  • グーテンベルクプロジェクトの認識は小さいですが、成長しています。
  • 「編集者が変わっている」以外のグーテンベルクの目的を理解することは、プロジェクトを知っている人の間でもまれです。
  • プロジェクトを密接にフォローしている人々の間でさえ、直接の編集者の範囲を超えたグーテンベルクの方向性についての認識と理解が不足しています。
  • ユーザー、管理者、設計者、および開発者に対するグーテンベルクの結果の即時および長期的な認識は、多かれ少なかれ欠けています。
  • ウィジェット、フィールド、メタボックス、ショートコードなどのWordPressのコア機能に対してグーテンベルクが何を意味するかを一般的なレベルでさえ理解することはnillに近いか等しいです。
  • プロジェクト情報のための信頼できるリソースの欠如は、憶測と誤解につながります。
  • プロジェクトの範囲と目標についての共通の理解の欠如は、コミュニケーションの崩壊と緊張のエスカレーションにつながります。

考えられる解決策



Gutenbergプロジェクトは、プロジェクトの範囲、意図された方向性、現実的でストレッチの目標、タイムライン、スプリント、およびプロジェクトに直接関連するその他の情報(理想的にはプロジェクト自体のREADME.mdファイル)の概要を示す包括的でわかりやすい言語の中央リソースを公開する必要があります。

現在、この情報は部品では、様々に、存在するメイクの記事、@mtias "ポスト『グーテンベルクとThesusの船』、@mさんは『私たちが理由でグーテンベルクそれを呼んだ』、スラックチャットの歴史の中で、プルにこのリポジトリ内のリクエストとチケット。

この情報は分断されているため、プロジェクト全体を明確に把握することは誰にとっても困難です。 @mの投稿はプロジェクトの壮大なビジョンを説明するのに役立ちますが、具体的な説明が不足しています。コミュニティがこのプロジェクトが何であるか、そしてそれがどこに向かっているのかをしっかりと理解するために必要な必需品の言語の内訳。 それらはまた、プロジェクト自体のコア部分ではなく、プロジェクトを周回する情報の独立した衛星として存在します。

説明する単一のリソース
a)グーテンベルクが存在する理由( @mの投稿の簡略版?)、
b)それが向かっているところ(最終目標+壮大なビジョン)、
c)プロジェクトが現在エディターに焦点を合わせている理由、および
d)編集者の焦点がより大きな計画の最初の構成要素であること。
これらの会話に関与するすべての関係者が感じる混乱や不快感の一部を解決するのに大いに役立ち、メタボックスに関する問題、グーテンベルクを編集者にロックするなどに関する質問が発生したときに、統一されたリソースおよび参照として機能します。

ここで成功するための鍵は、私たちがどこにいるのか、どこに行くのか、そして私たちが使用する用語が実際に何を意味するのかについての共通の理解です。 それは、アクセスしやすい1つの場所にある明確な言語ドキュメントから始まります。

[Type] Documentation

最も参考になるコメント

私は提起された問題に同意し、グーテンベルクに関する議論は非常に問題がありました。

ただし、現時点でロードマップが必要なのは、グーテンベルクだけでなく、_WordPress_自体です。

「人々が実際にコンテンツサイトを構築するために使用する、時代遅れのPHP方言のレガシーコアに基づく、トレンディなJSWebアプリケーションプラットフォーム」の現在のプロジェクトの方向性は奇妙になりつつあります。

この時点で、そこから選択的に引用することは、一見正当化できるようです。

  • 絶対的な下位互換性
  • 下位互換性を破る
  • テクノロジーの大きな変化
  • テクノロジーは変わらない
  • 大規模なPHPおよび/またはWeb開発業界から学ぶ
  • プロジェクト外のすべてを完全に無視する

グーテンベルクについての会話は、そのビジョンが不明確であるため、「ただ」ではなく失敗しています。

グーテンベルクが_WordPressプロジェクト_の目標に不可欠であると主張しているため、失敗しています。 そして近年、そのビジョンは着実に目的、方向性、優先順位の明確さを失っているようです。

全てのコメント53件

これは、明確な公開製品ロードマップが役立つ理由を詳しく説明しています。 https://open.buffer.com/transparent-product-roadmap/

おかげで、それは大いに役立つでしょう。

今後数年間の方向性を計画している多くのサイト所有者の未解決の質問もカバーする必要があります。グーテンベルクとページビルダーの関係です。

例えば:

  • それらは最初のステップでどのように統合されますか?
  • グーテンベルクはどのマイルストーンでページビルダー機能のどの領域をカバーしますか? たとえば、セクション/列でのレスポンシブレイアウトの構造化、詳細なスタイリング(色、背景画像、余白のパディングなど)。 言い換えれば、グーテンベルクのエディターはライターツールと見なされますか、それともデザイナーツールと見なされますか?
  • グーテンベルクはテンプレートライブラリのようなものをサポートしますか?

それらが長期間共存すると仮定すると、次のようになります。

  • ページビルダーのレイアウトを含むブロックを持つことは可能ですか?
  • グーテンベルクのインスタンスまたは単一のブロックをページビルダーのレイアウトにドラッグできるようにすることが目標ですか?

フロントエンド編集は言うまでもありません...

はい、グーテンベルクプロジェクトには、特にプロジェクトの成功がWordPress自体の成功と重なっているため、WordPressの将来について不要なFUDを作成している忍び寄る範囲があるようです。 効率的で反復的なプロジェクト管理はたくさんありますが、これで対処できる製品管理にはギャップがあります。

これは、リリースの履歴リストにすぎないWordPressロードマップのより大きな問題のWordPressMarketingによる最近の

@Skarjune何年にもわたってプロセスを観察し、チームから公開されたさまざまな資料を読み、チームメンバーと話をしたことから、ここに(多くの)スコープクリープはないと思います。 プロジェクト全体を実行し、将来の特定の方向に向ける、かなり明確な推論の線があります。 問題は、人々がアクセスできる1つの場所に情報が含まれていないことです。 これらのことを正しく概説するために単一のリソースが作成された場合、多くの人が夜はぐっすりと眠るだろうと思います。

私が順不同で見たい他のいくつかのこと:

  • Gutenbergを5.0に具体的に結び付ける理由と、準備ができたときに統合されるRESTAPI作業の機能プラグインである理由。
  • 編集画面全体とコンテンツエディタを引き継ぐ理由(これにより何が可能になるかなど)。
  • マージ、リリースの大まかなタイムライン。 5.0をいつリリースの対象にするべきかについて、チームはどのように考えていますか? これはたった4分の1(「2018年第2四半期」と「4月上旬」)かもしれませんが、今のところ、5.0がいつ発生するか、そしてグーテンベルクがマーク。

    • それと一致して、リリース基準。 チームが合併する前に何なければなりませんか? Metaboxのサポートとそれがどのように達成されるかが現在のホットボタンですが、基準リストはそれを超える必要があります。

  • 最初のリリースには含まれないもの。 たとえば、Fields APIのサポートが範囲外であると判断された場合、それはこのリストに含まれます。 これは除外されたものすべてをリストする必要はありませんが、外部の議論を受けたより大きなアイテムをカバーする必要があります。
  • 重要な未解決の問題。 再びFieldsAPIを例として使用すると、それを終了し、Gutenbergがそれをサポートするという決定がテーブルにある場合、それは未解決の問題としてリストされるため、人々はそれが議論されていることを知ることができます。 繰り返しになりますが、これは、かなりの時間や労力を要する、またはグーテンベルクの方向性と能力に大きな影響を与える大きな問題だけを開いているすべての問題ではありません。

@ mor10 OK、私はグーテンベルクがプロジェクトとしての「スコープクリープ」に苦しんでいないことを訂正しましたが、それは多くのオブザーバーの認識です。 UIでメタボックスをアドレス指定することへの言及が見当たらない、エディターの技術概要の初期の投稿以降の進捗状況を追跡しました。エディターを介してデータを管理するための不十分な実装としてのショートコードの批判のみです。 私のポイントは、WordPressの一部のプロのユーザーが彼らの制約がテーブルから外れていることに驚きを表明していることを示すことを単に意味していました。

この用語を使用してすべての人に話すことはできませんが、「スコープクリープ」と言うときは、プロジェクトの以前のランディングページであるMake blogpostsの公式声明に基づいて推測したスコープを指します(これはもうできません)どこでも検索)、および現在のプラグインページ

後世のために、これは現在のプラグインの説明です:

ブロックエディターの目標は、WordPressにリッチコンテンツを簡単かつ楽しく追加できるようにすることです。

これはベータ版ソフトウェアです。

新しい投稿とページ作成のエクスペリエンスにより、リッチな投稿を簡単に作成できるようになり、ショートコード、カスタムHTML、または「謎の肉」の埋め込み検出が必要になる可能性のある作業を簡単に実行できるようになります。

WordPressはすでに大量の「ブロック」をサポートしていますが、それらをうまく表示することも、レイアウトオプションの点で多くを提供することもありません。 リッチポストコンテンツのブロック状の性質を取り入れることで、既存のブロックを表示し、それぞれにさらに高度なレイアウトオプションを提供します。 これにより、この例のような美しい投稿を簡単に作成できます。

プラグインページを読むと、今日でもメタボックスについての言及はありません。 エディターへの参照、リッチな投稿の作成、ショートコード、カスタムHTML、埋め込み、美しい投稿の作成(投稿コンテンツの例へのリンク)が表示されます。

プラグインページの説明で使用されている用語により、WordPressに精通している人なら誰でも、コンテンツエディターが更新されることを期待することになります。 どうして? 言及されているこれらの用語はすべて、今日のコンテンツエディタを使用するものであるためです。 なじみのないWordPressユーザーや開発者に、プロジェクトの範囲がコンテンツエディターを超えることを意図していることを示すものは何もありません。

内部の理解に基づいて範囲を解釈する人もいますが、私はこれらの外向きの資料に基づいて範囲を見ています。 @ mor10が提案しているロードマップは、両方を同期させる機会です。

#3347との架橋。

私の主な関心事は、グーテンベルクに対応するためにデータ収集がどの程度変更されるかです。 基盤となるデータ構造は、付随するAPIエンドポイントのいずれかを変更しますか?

私は提起された問題に同意し、グーテンベルクに関する議論は非常に問題がありました。

ただし、現時点でロードマップが必要なのは、グーテンベルクだけでなく、_WordPress_自体です。

「人々が実際にコンテンツサイトを構築するために使用する、時代遅れのPHP方言のレガシーコアに基づく、トレンディなJSWebアプリケーションプラットフォーム」の現在のプロジェクトの方向性は奇妙になりつつあります。

この時点で、そこから選択的に引用することは、一見正当化できるようです。

  • 絶対的な下位互換性
  • 下位互換性を破る
  • テクノロジーの大きな変化
  • テクノロジーは変わらない
  • 大規模なPHPおよび/またはWeb開発業界から学ぶ
  • プロジェクト外のすべてを完全に無視する

グーテンベルクについての会話は、そのビジョンが不明確であるため、「ただ」ではなく失敗しています。

グーテンベルクが_WordPressプロジェクト_の目標に不可欠であると主張しているため、失敗しています。 そして近年、そのビジョンは着実に目的、方向性、優先順位の明確さを失っているようです。

私の組織のワードプレスベースのサイトのマイナーなワードプレス編集者およびリードメンテナーとして、主に離れた場所からワードプレスの開発をフォローしています-時々make.wordpress.orgを閲覧してwptavern.comをスキャンすることから; 私はwptavernを通してこのチケットに出くわし、心から同意します。

簡潔で明確な言葉で懸念を概説する努力をしてくれた@ mor10に感謝します。明確にページを説明したページが非常に役立つでしょう。 それはセミパワーユーザー(まだこれをテストしていないが、開発者に直接連絡することなくパイプラインに何が来るのかをヘッドアップで確認したい(迷惑および/または迷惑)ワードプレスがどこに向かっているのかを理解し、ワードプレスの変更を確実に実行できるようにします。

@kevinwhoffmanに同意します。 毎月のミートアップでグーテンベルクについて「WordPress5.0の新しい編集体験」と最初に言及したとき、私もそれがTinyMCEエディターウィンドウの代わりになると思っていました。 プラグインページの概要に基づいて、投稿エディタページ全体を引き継ぐとは思っていませんでした。

心配しているユーザーから、現時点では明確に答えられないサイトにとっての意味について、さまざまな質問が寄せられています。

プラグインのページには、これはベータ版ソフトウェアであると記載されてい

ウィキペディアから

ベータフェーズは通常、ソフトウェアが機能を完了したときに開始されますが、既知または未知のバグが多数含まれている可能性があります

私の意見では、グーテンベルクは完全な機能にはほど遠いです(iframeの物語全体を見てください)。

グーテンベルクをインストールしたときに多くの投稿データ(メタボックスなど)を「失った」ため、次のミートアップでパニックに陥った人がいました。 これは、ベータ版ソフトウェアを利用するのに適した立場ではありません。

@rickgregoryは、REST APIがコアにマージされるまでの

ローカルビジネス向けのウェブサイトを開発している私は、グーテンベルクプロジェクトの範囲とビジョンを理解するのが非常に難しいことに気づきました。 私はより良いエディターの必要性を完全に支持しましたが、長い間、チームから出てくるすべてのメッセージのブロックが非常に混乱していることに気づきました。

グーテンベルクのチームはブロックの意味を理解していましたが、ユーザー/開発者が外部から見ていると、それを理解できませんでした。 先日、偶然「グーテンベルク、またはテセウスの船」の投稿に出くわしました。最初に読んだことで、ブロックがどのように良いかを理解することができました。 しかし、私は偶然にそのポストに出くわしただけです。

プロジェクトのビジョンと範囲を概説する決定的な文書は、コミュニティ全体の懸念に対処するのに大いに役立ちます。

私は今、彼らの将来を率直に恐れている多くの開発者と話をしてきました。 彼らは、過去に開発したすべてのサイト/テーマ/プラグインに戻って大きな変更を加える必要があるかどうかを知りません。 5.0がリリースされたときにすべての作業をやり直さなければならない場合に備えて、彼らは今すぐ大きなプロジェクトに取り組むことを恐れています。 彼らは、グーテンベルクを使用するためにクライアントをいつ、どのように訓練する必要があるのか​​を知りません。 彼らは、グーテンベルクと一緒に成長するためにいつ、どのように自分自身を教えるかを知りません。 彼らの多くは、クライアントがWordPressの使用を継続したくないと考えており、他のCMSを学習したり、クライアントをSquareSpaceに移行したりすることを検討しています。 これらの恐れのすべてが根拠のないものである可能性は十分にありますが、どちらか一方を知る方法はありません。 グーテンベルクの範囲、目標、およびタイムラインの明確な概要は、開発者が将来の計画を立てるのに役立ち、開発者とそのクライアントが引き続きWordPressを使用できることを保証します。

したがって、誰もがそれは良い考えであり、非常に有益であると考えています。 残っているのは、誰がいつそれを書くのかという問題だけです。 私はそれを申し出るつもりですが、私はコーダーではありません。GutenbergCentralの開発者は、すべての詳細を正しく記述してレイアウトできるようにする必要があります。 私は今、マーケティングの側面に関わるあらゆることに関与することを申し出ますが、それが私の強みです。

数か月前に、グーテンベルクのプロモーション計画を作成するようにWordPressマーケティングチームにリクエストが届いたことを報告できます。 それはチャーターされ議論されましたが、私たちの何人かは時期尚早であり、すべてをより明確にすることなくエンドユーザーにベータプラグインを宣伝するのは奇妙だと思ったので、保留にされました。 私にとって、これは製品とプロジェクトのスコープの問題、または馬車の前のカート、または他のいくつかのアナロジーを引き起こします。 要点:製品には、プロジェクトスコープを伴うロードマップが必要です。

@ Skarjune-奇妙な方法で、彼らがそれを間違った方法でやろうとしたことは理にかなっています。 そして、プロジェクトが実行されている方法についての一般的な感覚が何であるかをいくらか確認します。 とはいえ、誰が書いたとしても、できるだけ早く書く必要があります。 未解決の質問が多すぎると、人々は自分の方向に進むことになります。

先週末のWordCampSeattleでのGutenbergに関するMortenのプレゼンテーションに感謝しました。驚いたことに、プロジェクト全体に対する私の態度が変わりました。

彼はまた、みんなにプロジェクトに参加するように勧めました。それが私がここでコメントする時間を取っている理由です。

人々を安心させるとき、目標と範囲を概説することは決して悪い考えではありません。 WordPressには、取得の問題ではなく、保持の問題があるとよく言われます。 開発者コミュニティ内およびオープンソースバザールでの争い(私を含む)の間で期待を管理することは決して悪いことではありません。

誤解は、燃え尽き症候群につながる混乱につながります。

このプロジェクトにご尽力いただき、そして私たち全員が大好きな素晴らしいプロジェクトを構築してくださった皆様に感謝いたします。

みんなからのコメントとエンゲージメントに感謝します。 現在、リソースにいくつかの広がりがあります。

ランディング/マーケティングページ: http

Readme: https

ドキュメント: https

しかし、私たちはもっとうまくやることができ、あなたは聞いています。 私は立ち寄って、あなたがそれを知っていることを確認したかった。

私には2つの提案があります。最初の提案は、すでに取り組んでいるものです。 現在、これらのリソースのうち2つが繰り返されています。 http://wordpress.org/gutenbergとプロジェクトのreadme。 反復には、グーテンベルクが何であるか、そしてこれからどうなるかに焦点を当て、リンクとリソースを追加し、こことコミュニティ内で言われていることに注意することが含まれます。 可能であれば、少なくとも反復するコンテンツを提供する必要があるため、1週間待ってください。 うまくいけば、これを伝えるために次に進む場所への良い出発点になるでしょう。

第二に、皆さんがここで理想的だと思うことを聞きたいと思います。 誰もが生産を見たいと思っているのは正確には何ですか? どのフォーマットが機能しますか? それらのページで十分でしょうか? あなたにとって理想的なフォーマットは何でしょうか?

それらのページが作業されている間は言うのが難しいことは知っていますが、次のステップに進むためにすべてが確実に実行されるようにしたいと思います。 それらが完成したら、より多くの人々に私たちのリソースとドキュメントの改善を手伝ってもらいたいと思います。 それがたまたま助けにステップアップした人々と働き始めるとき、私はそれらをここにリンクします。 みなさん、ありがとうございました。

私が一緒に役立つと思う2つのフォーマットがあります:
1)グーテンベルクがリリースされる前に実施される機能/マイルストーンのリストを示すロードマップ。少なくとも、これらのことがいつ発生すると予想されるかについては漠然とした兆候があります。
2)「メタボックスのサポートはありますか?」、「グーテンベルクと互換性があるようにプラグインとテーマを書き直す必要がありますか?」などの質問への回答が記載されたFAQセクション。 「グーテンベルクが私のサイトを壊した場合、元に戻すことはできますか?」 よくある質問への回答は、不安を和らげるのに本当に役立ちます。

これらのドキュメントがどこにあるかについては、少なくともマーケティングページからそれらにリンクすることは理にかなっていると思います。 また、定期的に保守および更新される可能性が最も高い場所にドキュメントを配置することも理にかなっています。 マーケティングページにこのようなものを置くことがそれを更新することへの障壁であるならば、それはマーケティングページ上のリンクで、それが更新され続ける可能性が最も高いところならどこへでも行くべきです。

@wpalchemist Your(1)がこの問題の焦点であり、機能とマイルストーンが明確になっています。
(2)の場合、プロジェクトにはすでにGitHubにそれがあります。
https://github.com/WordPress/gutenberg/blob/master/docs/faq.md
@karmatosedは、そことWordPress.orgの両方にいくつかの優れたリソースがあることを示しました。そうです、メインページでそれらを完全に索引付けしておくと便利です。
http://wordpress.org/gutenberg

@Skarjune FAQリンクをありがとう! それを見つけやすくする必要があります。 :)

FAQページの良い点は、私が話した変更の最初のイテレーションに入ることを確認させてください。 フィードバックをお寄せいただきありがとうございます。 それは、この情報の多くがそこにあることを示しています。それはそれを表面化することに関するものなので、良い点があります。

これが私の当面の提案です:

  1. 現在および将来の目標、タイムライン、および保持されるデータ構造、追加されるデータ構造、設計者と開発者が準備する必要があるものなどの重要な決定を含むプロジェクト概要ドキュメントを作成します。
  2. WP-API.orgに似た包括的なウィキを作成し、現在のドキュメントと空/寄稿者が必要とするドキュメントを提供する包括的なドキュメントを使用して、存在するものと構築する必要があるものをすべての人に明確にします。
  3. FAQを拡張して、管理者、設計者、および開発者向けの質問に回答します

ここに何があるべきかについての提案を含む上記のコメントがあります。 私のはhttps://github.com/WordPress/gutenberg/issues/3354#issuecomment-342310592にあり、一般的に、これのすぐ上のMor10のコメントは正しいと思います。

最初のリリース、2番目のリリースなどで何が行われるかを確認したいと思います。つまり、グーテンベルクの最終目標は多くのことかもしれませんが、最初のリリースの機能リストは何ですか?

また、重要な未解決の問題と未解決の問題のリストを用意することが重要だと思います。 私の懸念のいくつかは機能的であるため(メタボックスはどのようにサポートされるかなど)、これを言いますが、多くが未定義で不確実であるという事実に集中しているものもあります。

私の意見では、グーテンベルクはブログに焦点を当てており、実際にはブログにとって素晴らしい追加になるかもしれません。

グーテンベルクのサイトから直接取られた以下の画像によると:
image

表題を加える
あなたのストーリーを書く

ブログとしてではなく、企業、eコマース、リスト、仕事、知識ベース、レストラン、学校のサイトとして使用され、長いリストが何度も続くサイトは、

したがって、グーテンベルクはこれらのタイプのサイトにはまったく役に立たず、メタデータを使用する典型的なサイトでもあることを念頭に置いて、この怪物の背後にある開発チームは、私の意見では、このサイトに光を当て始め、プラグインまたはCoreに折りたたまれている場合は、デフォルトの投稿投稿タイプでのみアクティブにします。

上記の@Rarstのコメントに

WordPressの重要な信条の1つは、下位互換性を確保することに重点を置いてきました。 メタボックスやあいまいなタイムラインなどに関する議論は、WordPressに必要なPHPバージョンのアップグレードに関する長年にわたるさまざまな会話を思い起こさせました。 5.2から5.3への移行に関する議論の1つで、Andrew Nacinを引用すると、「ユーザーを犠牲にして「一緒に遊ぶ」ことは、私たちの最善の利益ではありません。数千万人のユーザーが影響を受け、潜在的に立ち往生するか、なぜWordPressがそれらをこれらすべての真ん中に置いているのか疑問に思っています—すべて理由があります。それは完全にばかげています。それはまた、WordPressがホスト型または代替のブログソリューションが実現することを望んでいるような動きでもあります。」 これは、人々がWordPressをエコシステムとして期待し、評価するようになった一例にすぎません。WordPressは進歩しますが、ユーザーを犠牲にすることはありません。

WordPress内で行われることを望んでいる最新の開発慣行がいくつかありますが、サイトを壊すことを恐れずに最新かつ最高のものにアップグレードできるという事実で、ユーザーを安全にする特定の哲学を尊重しました。

とは言うものの、グーテンベルクの主要な貢献者がここで「長年のWordPressユーザー」を念頭に置いていると述べているのを読んだのですが、私はそのつながりを見ていません。グーテンベルクがこれをどのように行うかについてもっと知りたいです。 私は個人的に、編集者の後任としてグーテンベルクに非常に興奮しており、開発チームはその分野での彼らの努力の多くを称賛されるべきだと感じています。

しかし、投稿/ページ編集画面全体の置き換えに関連する会話を読んでいると、私はますます神経質になっています。 グーテンベルクの解放にもっと系統だったアプローチをとるという多くの理にかなった要求は、次のような反応で満たされました。

  • そのようなアプローチは、プロジェクトのビジョンと一致していません
  • 準備が整うまでリリースされません。

彼らは私たちに何も教えてくれないので、これらは正直なところ答えではありません。 最初に:開発者とユーザーがプロジェクトのビジョンに反する新しいルックランに慣れたら、最初にエディターをリリースし、次に編集画面の残りの部分に焦点を合わせるという段階的なアプローチを行うのはなぜですか? このプロジェクトの周りに暗黙的に設定されている任意のタイムラインに逆行しているのではないかという恐れがあるようです。 そして第二に:予想される準備日は何ですか? 現在のFAQに記載されているように、「2018年のいつか」はまったく答えではありません。 'ready'を定義するためのパラメータは何ですか? @ mor10の最初のコメントが述べているように、ここでは本当に詳細が必要です。 このプロジェクト内にマイルストーンを含む明確に定義されたタイムラインがないことは、ここで多くの不安を深刻に引き起こしています。 グーテンベルクのリリースが、現在サイトでそれを使用している何百万ものユーザーを危険にさらさないように、下位互換性のコアワードプレスの信条にどのように注意を払っているのかを明確に詳述するコミュニケーションを見るのは素晴らしいことです-そのバリエーションを理解して「私たちを信頼する」については、実際には答えではありません。

最初に:開発者とユーザーがプロジェクトのビジョンに反する新しいルックランに慣れたら、最初にエディターをリリースし、次に編集画面の残りの部分に焦点を合わせるという段階的なアプローチを行うのはなぜですか?

結合された方向の上にそのような孤立した方向で作業するために回るのにおそらく十分なリソースがないからです。 後で判明した場合、編集者のみの指示が全体像に対してうまくいかない場合は、どうしますか?ソフトウェアを再構築し(非常にコストがかかる)、全員を再トレーニングします(非常にコストがかかります)? そのような試行錯誤のサイクルは、ユーザーベースが何回耐えられると思いますか? それは前もって失敗した戦略です。

ここでの影響は非常に大きいため、「オールオアナッシング」戦略以外の余地はほとんどありません。

結合された方向の上にそのような孤立した方向で作業するために回るのにおそらく十分なリソースがないからです。

限られたリソースが、インクリメンタルアプローチが理にかなっている理由です。 私たちのアプローチは、エディターから始めて、途中で事前定義されたチェックポイントで進捗状況を検証することにより、埋没費用を削減することです。

代わりに、散在する優先順位に焦点を当てた有能な開発者が少数いますが、コミュニティは、不確実なタイムラインの終わりに全体的なビジョンが一緒になることを信頼するよう求められています。 その結果、各リリースは、1つのマイルストーンに向かって進むというよりも、機能のリストのように感じられます。

@ lkraav-あなたは要点を誤解していると思います。 提案されている「孤立した方向」はありませんが、段階的詳細化があります。

今のところ、グーテンベルクに編集画面全体を引き継がせるという提案があります。 何度か尋ねられたのは、最初のリリースで画面のエディター部分を単純に置き換えることができず、時間の経過とともに編集領域を引き継ぐようになった理由です。 これにはいくつかの利点があります。

1)ユーザーは、限られた便利な方法でブロック編集エクスペリエンスに慣れることができます。 同時に、作業範囲が縮小され、この最初のフェーズを比較的迅速に実行できるようになります。
2)メタボックス(およびその他?)の問題を今すぐ把握する必要がなくなり、多くの既存のサイトが壊れないようにするために、ACFなどのプラグインもGutenberg用に変更する必要がなくなります。
3)#1に続いて、UXに関するチームの実際のフィードバックと、実際のエンドユーザーがブロックエディターをどのように受け取るかを取得します。 これは、多くのことが行われる前に、将来の設計作業を指示するのに役立ちます。

次のフェーズでは、たとえば、メタボックスの問題を取り上げて、機能セットを拡張することができます。 これは、ビジョン全体が実現されるまで続く可能性があります。

最終的に、グーテンベルクは編集画面全体を置き換えますが、正しく行われると、このアプローチは、すべてまたはまったくのリスクを回避

最後に、これをより広いタイムラインで検討する必要があると思います。 今から5年後、どちらのアプローチでも、完成した堅牢なグーテンベルク体験がもたらされる可能性があります。 その時点が今から2年後か3年後かは本当に重要ですか? WPのような支配的なプレーヤーについて話しているとき、それは問題ではないと思います。 実際、ある程度の注意が必要です。WPはマーケットリーダーであるため、マーケットリーダーに追いつくためにスクランブルをかける必要はありません。 悲惨なことは、サイトを破壊し、最前線の機関が堅牢なソリューションを提供する能力を損なうソリューションを急いで出すことです。これらはすべて、チームが変更を検討しない厳格な設計ビジョンのサービスです。

まず第一に、 @ lkraav 、私は応答に感謝し、グーテンベルクチームが引き受けた巨大な仕事に完全に感謝します。 影響が大きいということは、私たち全員が同意していると思います。

私があなたの結論と異なるところは、これが「オールオアナッシング」バイナリであるということです。 @rickgregoryが述べているように、編集者に焦点を当てることは別の方向に向かっているわけではありませんが、チームが自分で設定したビジョンを達成するための一歩です。 現時点でFAQやその他のドキュメントで特定されているWordPressユーザーにとっての唯一の具体的なメリットは、管理画面全体ではなく、コンテンツエディターのみに集中していることを考えると、これは特に適切だと思います。

「オール・オア・ナッシング」と聞いたとき、それは私にとって少し赤い旗だと言います。カットして乾かすものはめったにないからです。 管理画面の他のすべての側面も中央のReactインスタンスの制御下にない限り、コンテンツブロックエディターがスタンドアロンコンポーネントとして機能できないという仮定は、これをさらに厄介にします。

WordPressが壊れているというこの仮定があるようで、生き残るためにはこの変更を加える必要があります。 もしそうなら、WordPressを完全に作り直す必要があるのなら、なぜプラグインを試すことにもっと興味がなかったのですか? プラグインエコシステムは、WordPressが特定のニーズに対応していないと感じているユーザーが、自分のサイトにプラグインを追加することを躊躇しないことを示しています。 それでも、今日の時点で3000回のインストールがあります。 あなたは「人々が彼らのサイトにベータプラグインを入れたくないからだ」と言うかもしれません...そしてあなたはおそらく正しいでしょう。 しかし、WordPressを根本的に変える何かの周りで、ベータプラグイン(せいぜいマイナーな本番環境での使用)からすぐにコアにジャンプすることを心配している理由を理解できれば幸いです。

タイムラインを指定できないという事実は、これをさらに混乱させます。 グーテンベルクの開発者が挑戦してくれたことに感謝します。「すべて」が唯一の受け入れ可能な解決策であり、それを正しく行うために必要な時間がかかると私に言った場合、それは問題ありません。 ただし、5.0はすでに次のリリースとして予定されているため、マージの準備ができているか、「すべて」を「すべて」で機能させることができるかどうかを明確に理解せずに、人為的に設定された期限に向かって進んでいます。 WordPressユーザー。 あなたのプロジェクト計画の中で、グーテンベルクがいつ開発者がプラグインとテーマにどのように影響するかを検討し始めるのに十分安定するのか興味がありますか? グーテンベルクの準備をするために、開発者にどのくらいの時間が提供されますか? これらの質問にまだ答えられない場合、今後12か月でこれをコアに統合する方法がわかりません。

「オールオアナッシング」と聞くと、それは私にとってちょっとした赤旗だと言います...

私はグーテンベルクの方向を設定することとは何の関係もないので、私が書いたもののために旗を立てる必要はありません。 ここで他の皆さんと一緒に世界を解釈するだけで、数十年のソフトウェア開発のバックグラウンドに刺激を受けます。 私には実際のクライアントや個人的なビジネスがWordPressでハミングしていて、壊れたVisualHTML編集パラダイムはもう少し前に限界に達していた。 グーテンベルク(または今日私たちが知っているモデル)が私のプロセスにどのような改善をもたらすことができるかを正確に理解し、オープンアームでそれを歓迎し、コアとグーテンベルクプロセスに私ができることを貢献します。

トピックについては、私を含め、誰もが望むすべての「反復」または「包括的」について話すことができますが、言葉と願いは安価であり、方向選択の実現可能性を証明するのに十分な品質のプルリクエストを考え出すことが重要です。

私は、これらの代替方向のアイデアに十分な速さで取り組むために必要なリソースを他の誰かが投入しているのを見たことがないので、結局のところ、リソースを提供する人は何らかの方法で電話をかけます。 理解できるのは、非常に(コードレベルの)詳細に参加するのは非常に高価であり、必要な専門知識レベルであるためです。

そして、それがどうなるかを見て、選択した戦略的方向性の範囲内で要件に影響を与えようとする必要があります。 確かに、私は毎日PRリストを追跡していません(大きすぎます)が、グーテンベルクチームはすでにすべての貢献を歓迎していると公に主張しています。 方向転換は、誰かが技術を理解するという大変な作業を十分な速さで行った場合にのみ発生します。 「年」は、おそらく、断片をまとめるのに妥当な時間枠ではありません。

そのため、私は「すべての」方向性が続くと予測しています(提案も具体的にも望んでいないなど)。 ここでの個人的な仮説は、現在のモデルでさえ十分に有望に見えるので、何が起こっても、自分のものと私がサービスを提供するクライアントのために物事を理解することができるということです。 それは確かに間違っていることが証明される可能性があります。

私は、これらの代替方向のアイデアに十分な速さで取り組むために必要なリソースを他の誰かが投入しているのを見たことがないので、結局のところ、リソースを提供する人は何らかの方法で電話をかけます。 理解できるのは、非常に(コードレベルの)詳細に参加するのは非常に高価であり、必要な専門知識レベルであるためです。

それはまさにこの種のプロジェクトが失敗する場所です–そしてこれは特にそうです。 優れたソリューションに貢献する能力が、コードを書く能力に比例していないことを理解できないこと。 一方、コーダーが自分のコードが応答しなければならない用途について幅広い感覚を持っていない場合、優れたコードを書く能力は(危険ではないにしても)役に立たないと言います。

WordPressは、その柔軟性と拡張性のおかげで、その機能を拡張できる開発者にとって魅力的であり、独自の方法でそれを形作るために高度な知識を必要としない作成者や作成者にとって魅力的です。 これが、ブログやストーリー中心のサイトだけでなく、WordPressがさまざまな方法で使用されている理由でもあります。

コンテンツを作成および編集する新しい方法を考案する場合、このプロジェクトに貢献するすべての人が、この柔軟性と拡張性、カスタムフィールドの使用、カスタム投稿タイプの使用、およびその他のフォームを見逃すことはできないという考えを持っていることが重要です。 WordPressのコンテンツとの管理と相互作用のそれは二次的なものではなく、その成功の中核です。

この新しい編集エクスペリエンスにこの包括的な用途を組み込むことができない場合は、リリースする準備ができていないため、リリースしないでください。

@ lkraav-心配は無用です...「オールオアナッシング」バイナリに何らかの責任があることを示唆しているわけではありません。 グーテンベルクに関連する他のスレッドや記事で同様の声明を読んだので、私はその特定の結論についてコメントしていました。 そして、あなたのように、私はビジュアルHTMLエディターの代わりとしてグーテンベルクを歓迎します-私からの意見の相違はありません:)

これは、 @ kevinwhoffmanがこのスレッドでの最新の応答で提起した問題を

ここにwordpress.org/gutenbergとreadmeが更新されていることを追加するだけです。 作業は進行中ですが、正しい方向への一歩です。

私は単に知らないので、私は仮定するつもりはありません。 しかし、AutomatticやWordPress com / orgの他の誰かが、WordPressがどのように使用されているかを正確に言うことができるように、市場調査を依頼したり、利用可能な指標を調べたりしたことがありますか?

ブログ形式で記事を伝えたり記事を公開したりするためにそれを使用する割合は何パーセントですか?また、会社を紹介したり、eコマースストアで販売したりするためのCMSとして使用する割合はどれくらいですか? そして、それはどのように成長/縮小/予測されていますか?

これはこの議論への有益な貢献であり、各モダリティに対するグーテンベルクの適切な性質を理解するのに役立つかもしれないと私は考えるべきでした。

これが利用可能かどうか誰かが知っていて、ここで私たちにリンクを撃つことができますか?

タミーありがとう! wordpress.org/gutenbergおよびwordpress.org/gutenberg/handbook/セクションは非常に役立ちます。 しかし、今週WPTavernポッドキャストでMattMullenwegがそのコアとして出荷されることを確認したので、WordPressバージョン5への完全なロードマップはありますか。 私がwordpress.org/about/roadmap/を見ると、与えられているのは次のとおりです。

バージョン:5.0
予定:2018
リリースの1か月前に新機能が凍結され、バグを排除してパフォーマンスの問題についてコードをプロファイリングすることにより、リリースの品質を確保することに完全に焦点が当てられています。

この問題の核心は、開発者が特にタイムライン、サポートの廃止、および非推奨について懸念していることです。 例として、Drupalは明確なLTSタイムラインを提供します。
https://www.drupal.org/core/release-cycle-overview

テレンス、私は今年、Make WordPressMarketingプロジェクトの市場調査を調査しました。 WordPressに関するデザイナー、開発者、代理店の非公式の世論調査がいくつかありましたが、使用法について正式でも決定的なものでもありませんでした。 私たちのプロジェクトは、WordPressをクライアントに販売するためのエージェンシー向けのサポート資料を開発し、企業の採用を検討することのみを目的として、WordPressの使用に関するエージェンシーの非公式調査に焦点を当てました。

あまり注目されていませんでしたが、ボランティアのリソースしかなく、現在の「WordPress 2017の調査はもう受けましたか?」のような露出はありませんでした。 WordPress.orgのリンク—しかし、私たちはいくつかの貴重な洞察を得ました。 ご覧ください:
https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

@David Skarjune-ありがとう、それは私が想像していたことをほぼ確認しています。
ほとんどの組織は、対面するため、このステップを控えています。
彼らにやりたいことや何をさせるのではなく、現実に
さらに悪いことに、彼らが腸の反応と過去に基づいて何をすることに決めたか
経験。 したがって、問題は残ります。 持っていくための最良の方法は何でしょうか
後ろから前へのグーテンベルクプロジェクトのこの物語へのいくつかの現実。 に
ちなみに、私が正しく覚えているかどうか、夢を見ただけかどうかはわかりませんが、
しかし、グーテンベルクはマットの赤ちゃんの一人ではなかったのですか? もしそうなら、私は何だったのだろうか
動機とそれはどれほど「本物」でしたか?

午前16時54デビッドSkarjuneので金、2017年12月1日に[email protected]書きました:

テレンス、私は今年、MakeWordPressの市場調査を調べました
マーケティングプロジェクト。 デザイナーの非公式の世論調査がいくつかありました、
開発者、およびWordPressの代理店ですが、正式でも決定的なものでもありません
使用法について。 私たちのプロジェクトは、
WordPressの使用法、
WordPressをクライアントに販売し、エンタープライズを検討する機関
可決。

あまり牽引力はありませんでしたが、ボランティアのリソースと
現在の「WordPress2017を使用しましたか?
WordPress.orgの「まだ調査しますか?」リンク—しかし、私たちはいくつかの貴重な洞察を得ました。
ご覧ください:

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


コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348547816
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AD0dztdHtoNFHDbK2mNc_yma5n8O1GFpks5s8C8zgaJpZM4QTl13

>>

https://qloudpress.com/
カイプサイド厩舎、ネザーカイプサイド
デッドウォーターズ、サウスラナークシャーML11 0JL
電話番号:+44(0)141-416-3322

PGP Key ID:18D7884E29597525
http://keyserver.pgp.com

@ Skarjune-興味深い情報、リンクをありがとう。 WPコミュニティへのガイドとしてのその調査に関する私の主な関心事は、人々が彼らの役割をどのように説明しているかの内訳です。 開発者... 30%。 コンテンツ作成者... 1%。 管理しているサイトの数を尋ねたところ、46%が25以上と答えました。 そのオーディエンスは、コンテンツの作成と管理にWPを使用する人々ではなく、エージェンシーの典型です。

これは、エージェンシーの視点を理解するための優れたリソースですが、私たちが構築したソリューションを使用する人々の視点も理解する必要があるように感じます。

@rickgregory @TerenceMilbourn調査は、WordPressマーケティングを導くために、WP-org、WP Tavern、およびソーシャルメディアで宣伝された公募に対応する小さな自己選択のフォーカスグループでした。 以下で説明するように、これは幅広いWordPressの調査手段として意図されたものではありません。 回答者の内訳は次のとおりです(会社=クライアント):

代理店:58 69%
__servicing WordPress for Clients 46 — 55%
__WordPressをクライアントに提供する12— 14%
会社:18 21%
__WordPressをホスト14で使用— 17%
__WordPressをエージェンシー4で使用— 5%
エンタープライズ:8 10%
__Enterprise WordPress(ネットワーク/クラウド)4 — 5%
__Host提供WordPress4 — 5%

話題から外れることはありませんが、現時点でグーテンベルクプロジェクトを中心としたWordPressロードマップの必要性についてコメントさせてください。

この調査は、WCUS 2016コントリビューターデーのスタートアップマーケティングチームによって生成されたアイデア、特に現在議長を務めているクライアントとエージェンシーのサブグループに対する私のアイデアでした。 私の興味は、WordPressをより多くのエージェンシーに宣伝する前に、WordPressの使用についてエージェンシーに確認することでした。

回答者は、WordPressを使用する理由について、それに対する障壁ではなく肯定的な評価を持っていましたが、ロードマップ(その欠如を意味する)が主要な障壁でした。そのため、この問題のスレッドに投稿しています。

はい、WordPressの使用法について広い視野を持っているといいのですが、それには真剣なリソースとスポンサーシップが必要になります。 残念ながら、グーテンベルクの背後にある議論は、ブロガーが今後ブロック構築システムを必要としているということのようですが、その証拠は見られませんでした。また、膨大なユーザーとユースケースベースを考えると、なぜそれが主要な要因になるのかはわかりません。

個人的には、さまざまなプラットフォームでエンタープライズCMSプロジェクトに数年間取り組んできましたが、ワークフローの問題は複雑になる可能性があります。 エディターに関しては、通常、ワークフローに合わせてカスタマイズされ、ユーザーの役割ごとに異なり、バッチ処理も使用されます。 どのエディタが最適かについて、どちらかまたは両方の質問を見たことがありません。 これに関する最良の参考資料は、RickYagodichによる「AuthorExperience」です。 私は過去数年間にいくつかのWordCampsでこのトピックについて話しましたが、率直に言って誰も気にしませんでした...今、あなたはそれが重要だと思うでしょう。

@ Skarjune -OK、私は今レポートを読んで考える時間がありました、そして
それは本当に素晴らしい文書です。 大変な作業が行われたことがわかります
それとそれは明らかにいくつかの実質的なフィードバックと検証を提供します。

それに対する私の反応は、たとえば、レポートを依頼したクライアントとして、
それは本当にだけなので、私たちが今欲しいものの範囲があまりにも限られていること
代理店や開発者コミュニティからのフィードバックを収集するために着手しました。

グーテンベルクがどうあるべきか、そしてそれがどのようにあるべきかを正確に理解しようとするために
うまくいくはずですが、もっと外向きのアプローチが必要だと思います。
エンドユーザー市場の反応、意図、ニーズを理解し始め、
彼らが作成および管理したいコンテンツの種類に関しては。 と
彼らがそれをどのようにしたいか。

少なくとも好奇心が駆り立てられていないのは驚きです
WordPressまたはAutomatticは、市場調査を委託します。
少なくとも、業界の細分化の明確な内訳を与えることができます、
数百万のエンドユーザー組織タイプ、ユースケースの内訳など
エンドユーザーの。

つまり、誰が誰なのかわからない場合、誰が何を構築するかをどのように決定できるのでしょうか。
のためにそれを構築していますか?

これらの基本を理解していない場合は、引き続き話し合います
私たち自身、本質的に、そして実質的な現実世界の入力を放棄します。 と
つまり、本当に必要なものがわからないということです。
開発者がきちんとしたものだと思うものを構築することを押してください
解決。

しかし、何に対する解決策ですか? それが本当の質問です。

を介して何百万ものエンドユーザーにアンケートを「プッシュ」する機能を備えています
たとえば、WordPressダッシュボードは、本当に必要な場合は可能です。
このツールを日常的に使用する人々が何を必要としているかを理解する
基礎〜WordPressエコシステム内のニーズに対抗して〜
真にグローバルな意見のサンプリングと市場の定義の開発、
将来の目標を構築するためのセグメントサイズとその他の指標
計画。

巧妙に考え抜かれたアンケートと方法論は非常に可能性があります
プロジェクトがあまりにも遠くまで忍び寄ることが許されない限り、役に立ちます。

どうやってそのようなことをするのでしょうか。 私たちは次のようなことをすることができますか
それ?

20時01分rickgregoryで金、2017年12月1日に[email protected]書きました:

@Skarjune https://github.com/skarjune-興味深い情報、ありがとう
リンクのために。 WPへのガイドとしてのその調査に関する私の主な関心事
コミュニティは、人々が自分の役割をどのように説明しているかの内訳です。 デベロッパー...
30%。 コンテンツ作成者... 1%。

だけでなく、視点を理解する必要があると感じています
ソリューションを構築する人々ですが、私たちが構築するソリューションを使用する人々。


コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348600347
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AD0dzqdI4q0CIp4ViLLF6duied048AhEks5s8FsugaJpZM4QTl13

>>

https://qloudpress.com/
カイプサイド厩舎、ネザーカイプサイド
デッドウォーターズ、サウスラナークシャーML11 0JL
電話番号:+44(0)141-416-3322

PGP Key ID:18D7884E29597525
http://keyserver.pgp.com

@TerenceMilbourn Gutenbergのユーザビリティテストがあるので、より明確なロードマップの要求とと​​もに役立ちます。 テレメトリはWordPressで議論されてきましたが、大規模な研究と同様に、それは複雑になります。 したがって、グーテンベルクに関しては、ユーザビリティとロードマップに現在焦点を当てているため、バージョン5で2018年初頭にリリースするのが適切かどうかを判断するのに役立ちます。

追加の考えや提案がある場合は、Make WordPress Marketing Slackチャネルに参加してください: https

2018年の2つの目標は

グーテンベルク編集グーテンベルクのカスタマイズ

元の問題に関する更新はありますか? 具体的には:

説明する単一のリソース
a)グーテンベルクが存在する理由( @mの投稿の簡略版?)、
b)それが向かっているところ(最終目標+壮大なビジョン)、
c)プロジェクトが現在エディターに焦点を合わせている理由、および
d)編集者の焦点がより大きな計画の最初の構成要素であること

今日、ロードマップドキュメントを探していましたが、見つかりません。

@ mor10、これはされたレビュー私たちがあなたのフィードバック取得したいのですが、今日のグーテンベルクのバグスクラブ中にwordpress.org/gutenbergと、このレポのREADME.mdを、彼らはあなたの懸念をカバーするかどうかを確認します。 そうでない場合、どのアイテムが不足していると思いますか、またそれらはどこに属していると思いますか(wp.org/gutenbergまたはreadme)?

@jeffpaulまず、ロードマップはありません。 グーテンベルクが最初にリリースされたときにどの機能を備えているか、および/またはその後のリビジョンでどの機能が使用されるかについて、誰も明確な答えを提供しません。

はい、グーテンベルクは優れたドキュメントを追加しました。 しかし、一部の人が指摘しているように、たとえばDrupalと比較すると、有用な開発ロードマップはありません。 詳細な開発追跡がありますが、高レベルのロードマップはどこにありますか?

大きな懸念の1つは、長期的なサポートです。 5.xのリリース後に4.9.xにパッチが適用されると言われていますが、これは歴史的に当てはまります。
https://codex.wordpress.org/WordPress_Versions

コミュニティが5.0で前進するよう強く勧められていることを考えると、レガシーバージョンにはパッチが適用され続けますか?また、どのくらいの期間ですか?

レガシーパスが混乱する可能性があるという恐れがあります。 Classic Editorプラグインは部分的なソリューションとして提供されていますが、Gutenbergといくつかの追加構成も必要です。 LTSの目標は、新しいテクノロジーへの完全なアップグレードが保証または予算化されていない場合に、数年間安全なパスを確保することです。

@maddisondesigns @Skarjuneは、あなたが求めているロードマップドキュメントが不足しているため、少なくともグーテンベルクの今後のマイルストーンのリストがあります。

@Skarjuneは、WordPressコアのボランティアとして2年も経っていませんが、パッチは3.7.xに戻りました。 はるか昔のパッチ適用が永遠に続くことはないと予想するのが現実的だと思いますが、それに関する決定は、Make / Coreに更新が投稿されたSlackでの公開会議中に行われると予想するのがさらに現実的です。

@jeffpaul正直なところ、それはほとんど役に立たない。 基本的には、タグ付けされたさまざまなグーテンベルクマイルストーンへのリンクを提供するだけです。 マイルストーンで実際にタグ付けされた問題のごく一部のみが含まれているだけでなく、誰でも簡単にマイルストーンを変更することができます。 プロジェクトがリリースされる前日にすべてのマイルストーンを簡単に変更できる場合、ロードマップのポイントは何ですか?

適切な(平易な英語の)プロジェクトロードマップが必要であり、WP5.0の時点でグーテンベルクで利用できるようになるすべての機能と、次のリリース(5.1、5.2など)にプッシュされる予定の機能の概要が示されています。 ..)。 現時点では、グーテンベルクプロジェクトの外部の誰も、これが最終的にコアになると、彼らが期待できる機能について何も考えていません。そして、尋ねられたときに誰も答えを提供しません。 「_GutenbergはWordPress5.0に同梱されますが、リリースはGutenbergの準備ができたときにリリースされ、その逆ではありません_」と言われています。

グーテンベルクがいつ「準備ができている」かを決めるのは誰ですか? 彼らはどのようにその決定を下しますか? どの機能をコアにリリースするかは誰が決定しますか? どの機能が最初のバージョンに組み込まれ、何が次のバージョンに組み込まれるかは誰が決定しますか? グーテンベルクのコア開発者以外の誰もこの決定に関与しないことは明らかです。 スコープやロードマップが定義されていない状態でプロジェクトがこれほど長く続いたことはばかげています。つまり、人々が実際にこのことでどの機能を見たいかについて、WPコミュニティとの話し合いはほとんどまたはまったくありませんでした。

@jeffpaul情報をありがとう! これは役に立ちますが、システムアーキテクチャとサポートを短期的および長期的に計画している外部の関係者にとってはそれほどではなく、内部の開発プロセスと関係者にとってはなおさらです。

たとえば、DrupalバージョンのマイルストーンとLTSは非常に具体的です。
Drupal開発ロードマップ
Drupalコアリリースサイクル:メジャー、マイナー、およびパッチリリース

一方、Joomlaは、新しい4.0フレームワークに少し手を加えています。これは、過去のバージョン管理の問題を考えると、プロジェクトの前兆にはなりません。
Joomla!

したがって、グーテンベルクについての議論の混乱にもかかわらず、「プロジェクトの範囲、方向性、および目標のわかりやすい概要を提供する」という精神で、詳細なロードマップとLTSスケジュールは、特にエージェンシーキャンプとエンタープライズキャンプにとって大きな違いを生むでしょう。 ご協力いただきありがとうございます!

プロジェクトのREADMEには、多くの情報と、グーテンベルクのミッションステートメント(すべてがブロックです

この問題にはいくつかの良いアイデアがあると思いますが、この問題は、さまざまな声、さまざまな質問、さまざまな目的/目標で非常に圧倒されています。

この問題に関する多くのフィードバックは、グーテンベルクチームによって対処されました/引き続き対処されます。 ここでよく見られるスレッドの1つは、ロードマップ/互換性に関する懸念です。 WordPress 5はGutenbergに同梱される予定ですが、ユーザーは引き続き「クラシックエディター」にフォールバックできるため、ユーザーを立ち往生させておくべきではないことを覚えておくことが重要だと思います。

実行可能な問題ではないと思うので、これを閉じます。 これは、ここにあるすべてが間違っている、または実用的なアイテムがないということではありません。 一般に、この問題を「クローズ」と簡単に見なすには多すぎます。

WPタバーンで何をしましたか!! ?? 私はWPニュースを読むようになり、ポータル全体がグーテンベルクの宣伝に役立っています。 休憩してください。

はい、私は答えを知っています。 あなたはそれらに関連付けられていません。

このページは役に立ちましたか?
0 / 5 - 0 評価