「プラグインとしての機能モデル」は、WordPress コアに含めるための機能を開発する方法として3.7で導入されました。このモデルでは、機能を構築し、テストし、改良し、洗練されてから、マージ候補として検討します。進行中のプラグインとしての機能は、Make WordPress Core ブログの専用ページで追跡できます]。
コミュニティメンバーや新しい貢献者は、通常新しいリリースサイクルが始まるころに開催される機能プラグインチャットにおいて、新しい機能プラグインのアイデアを提案できます。
このチャットは、あなたが持っていて、開発に積極的かつ主要な役割を果たすことを計画しているアイデアを提出するためのものです。あなたのアイデアに興味を持った他の貢献者が、その取り組みに参加できます。チャットの日時は Make/Core ブログにおいて投稿で発表され、アイデアは短い提案書の形でコメントに追加されます。
- 提案する機能プラグインの概要 (一段落)。
- 現在のプラグインの状態 (アイデアの段階、計画の段階、開発中、既存機能のプラグイン、先行作業など)。
- あなたの機能プラグインに関係する、またはすでに興味を持っている人たちのリスト (あなたを含みます)。
- 手伝っていただきたいこと (スコーピング、プランニング、ワイヤーフレーム、開発、デザインなど)。
機能プラグインの開発期間は、プラグインの複雑さによっては、コアチームにマージ候補として提案する準備ができるまで、複数のリリースサイクルをかけて実験できます。
実験がなければ、アイデアは潜在的な機能として開発されないかもしれません。しかし、実験をすることで、完全に開発された機能がコアに入らないこともあります。なぜなら、詳細を検討した結果、その機能はコアにふさわしくないと分かったからです。
がっかりしないでください。試行錯誤はプロセスの一部であり、より良い機能、より良い WordPress を生み出すことになります。コアに含まれない機能は、すばらしいプラグインとして存在し続けることができ、エコシステム全体が恩恵を受けることになります。以前は、コアチームがプラグインとして始めることを提案することもありましたが、現在はこのプロセスが正式なものとなっています。
ある機能がコアに入るかどうかの決定は、最終的にコアチームの判断に委ねられます。あなたの方向性が正しいことを確認するために、リード開発者や次期リリースリードと連絡を取り合い、あなたが解決しようとしている問題や、あなたが選んだ方向性がその問題を解決するためになぜ適切なものであるかを理解してもらうようにしましょう。
タイムライン
機能プラグインがリリースに含まれるためには、リリースのキックオフ時に提案して、マージウィンドウの最初にマージできる状態である必要があります。その時点で、リリースリードは現在の機能プラグインをレビューし、コア開発者とともに、それらが完全なものでありコアにマージする準備ができているかどうかを判断します。
リリースリードは、強力で十分にテストされたユーザー体験、完成したデザイン、コミュニティからのポジティブなフィードバック、コア品質のコード、大きなバグや問題がないこと、その機能が WordPress コアに取り込まれるべきかどうかなど、さまざまなことを確認します (以下のチェックリストを参照してください)。すべての機能は異なるため、「準備完了」の意味は特定の機能によって異なります。最終的には、リリースリードがその機能について主要な責任を引き受けられること、そしてコアチームが長期的な責任を引き受けられることが必要です。
もしコア開発者がその機能をコアに搭載する準備ができていないと判断した場合、その理由と、将来のリリースに向けてその機能を準備するために何ができるかを、機能リードに知らせます。
組み込まれることが承認された機能は、そのコードをコアに取り込み、マージするための潜在的な問題に取り組むための約2週間のマージウィンドウを持つことになります。しかし、上に述べたように、機能はマージウィンドウの開始時にマージする準備が整っていなければなりません。
機能の責任者は誰ですか ?
機能がコアにマージされた後も、コアチームのサポートを受けながら、機能チームがその機能に対する責任を負います。WordPress の他の部分と同様に、コミュニティ全体からフィードバックが寄せられますが、機能がコアにマージされた後はより多く寄せられます。可視性が高まったことで、機能チームは機能をより確実なものにするために、より集中する必要があります。
チームはコアの機能に対して責任を持ちますが、最終的な意思決定はコアチームの手に委ねられていることを心にとどめておいてください。リリースリードは、機能リードやチーム全体と密接に連携して作業を進めます。
機能プラグインをマージする基準
以下は、プラグイン開発チームがコアにマージされるプラグインを開発する際に満たすべき要件のリストです。それぞれの機能は異なるものであり、要件も異なることを覚えておいてください。
- WordPress の公式プラグインリポジトリに存在し、定期的に更新され、コミュニティによって使用・テストされているプラグイン。
- ウィークリーチャットが Slack で行われており、機能リードが毎週行われる core dev チャットに参加している。
- キックオフに関する投稿と定期的な更新に関する投稿が公開され、機能プラグインの進捗と主要な決定事項を追跡している。
- 機能は、WordPress が公式にサポートしているブラウザのすべてで動作する。
- タッチデバイスに関しては、すべての機能を支障なく使用でき、Make/Flow に投稿されたすべてのデバイスにおいて、新しいインターフェースを通じた主要なフローについての視覚的な記録を持っている。Flow チームにレビューを依頼し、モバイルで正しく機能することを確認してください。
- 既存のインターフェースを変更したり置き換えたりする機能については、旧フローと新フローを比較する視覚的な記録を提供すること。
- WordPress コーディング規約に準拠したコード。
- 同様に、コードがよくテストされ、ユニットテストを備えている。
- コードは十分にドキュメント化されている (必ずインラインドキュメントチームにレビューしてもらいましょう)。
- コードはプラグインセキュリティのベストプラクティスに従っており、セキュリティ監査を受けている。
- ユーザーインターフェース・エクスペリエンスは、ユーザーテストによって検証され、適切なフィードバックが取り入れられている (必ずデザインチームにレビューしてもらいましょう)。
- デザインは、あらゆるモバイルデバイスで適切に表示される完全なレスポンシブデザインで、高解像度・レティーナディスプレイにも対応したグラフィックスを使用している。
- HTML が適切な doctype で検証されている。
- このコードには、ローカライズのための適切なフックがすべて用意されている (必ず Polyglots チームにレビューを依頼してください)。
- WordPress は引き続き機能し、JavaScript をオフにした状態でも、この機能は使用可能である。
- この機能は、キーボードだけで使用できる。
- (これらに限定されませんが) オフスクリーンテキスト、ARIA、JS-assisted など、必要なアクセシビリティのサポートが追加されている (必ずアクセシビリティチームに聞いてください)。
- プラグインの準備が整い次第、Make/Core ブログにマージの提案が公開されている。
機能プラグインをマージするためのチェックリスト
- 機能がマージされたら、機能プラグインがループしないことを確認してください。これは、プラグインからコアにコードがマージされた後に、プラグインが Fatal Error で壊れないことを意味します (たとえば
(class|function)_exists()
を使ってください)。 - 他のプラグインのコードを使用する場合は、機能がマージされた後にそのプラグインと衝突しないことを確認してください。