コードによる貢献
Topics
WordPress への貢献に興味を持っていただきありがとうございます。WordPress コアへのコード貢献のためのこのクイックスタートガイドは、最初のパッチを提出するために必要なすべてのリソースを見つけることができる、中心的なハブとなっています。
このガイドは、新しい貢献者を対象としており、リソースにすばやくアクセスできるようにし、新しい貢献者が取り組む際によくある一般的な質問に答えます。新しい貢献者とベテランの貢献者のコラボレーションにより、開始にあたっての課題をより明確にし、改善されながら継続的に更新される予定です。
貢献する前に、なぜ貢献するのか、私たちがオンラインでどのように交流しているのか、その背景を少しだけ理解することが重要です。
なぜ貢献するのか
WordPress の将来の成功のためには、健全な貢献者のグループを持つことが重要です。すばらしいアイデアを含む多くのオープンチケットがあり、なぜこれらのすばらしいアイデアが実装されないのかと多くの人が尋ねます。その答えは、WordPress はアイデアを実現するために、あなたのような人々に依存しているからです。WordPress はユーザーとボランティアによって運営されているプロジェクトです。すべての改善や改良は、コミュニティによって支えられています。
誰もがみな人間です
WordPress に貢献するとき、誰もが人間であることを忘れないようにすることが重要です。私たちはさまざまな経歴を持ち、さまざまな言語を話します。コア貢献者のコミュニティには、バグを修正する人からコミッターまで、さまざまな役割があり、それぞれが開発プロセスを前進させるのに役立っています。貢献者は簡単に参加でき、その結果として高いレベルの敬意が求められ、コミュニティ全体に提供します。
前述したように、WordPress と他のコミュニティの大きな違いの一つは、WordPress の貢献者が非常に参加しやすいということです。リード開発者やコミッターをお探しですか ? Slack のパブリックチャンネルで質問してみましょう。恐れずにアプローチしてください。ただし、連絡は一方的にダイレクトメールを送るよりも、公開チャンネルで行ったほうが良いということを覚えておいてください。Slack では、コアについて質問するために最適な場所は #core ですが、コアの特定の部分について議論するいくつかのサブチャンネルがあります。他のチャンネルに誘導されても心配しないでください。私たちがお手伝いします。
貢献者を見つけるために最適な場所の一つは WordCamp で、躊躇せずにアプローチすることです。コントリビューターデイを開催している WordCamp もあり、貢献者を見つけ、助けを求めるには最適な機会です。
コミッター
コミッターは WordPress の貢献者の一種で、コミュニティから信頼を得て、WordPress コアにコードを「コミット」するための権限を与えられています。コミッターは、自分のコードだけでなく、他の貢献者のコードも判断してコミットします。
コンポーネントメンテナー
WordPress は、コンポーネントと呼ばれる、明確に定義された数十の機能エリアで構成されています。HTTP API のメンテナンス、エディターの改善、カスタマイザーの進化など、多くの貢献者が特定の分野に関心を持っています。
コンポーネントのメンテナンスを支援する貢献者は、論理的にはコンポーネントメンテナーと呼ばれます。メンテナーは、WordPress の開発を可能な限り円滑に進めるために重要です。メンテナーは、新しいチケットのトリアージ、既存のチケットの改善、タスクの指導、新しいアイデアの提案、ロードマップの管理、他の貢献者へのフィードバックなど、多くのタスクを引き受けることができます。長い間メンテナーを務めている人々は、コアのそれらの領域について深く理解しており、常に他の人たちを指導して知識を伝えるよう努めています。
手伝ってみませんか ? 興味のあるコンポーネントをフォローすることから始めましょう。ここで通知を設定できます。
リポジトリ
WordPress は、コードベースの変更を管理するために、Apache プロジェクトが管理するバージョン管理システムである Subversion (SVN) を使用しています。
開発リポジトリはダウンロードできます。このリポジトリには、コアとなるユニットテストとビルドスクリプトが含まれており、デフォルトで圧縮・連結されていない Javascript が使用されます。これらのリポジトリには誰でも読み込み権限があります。リポジトリの構造については、コードリポジトリ (SVN) を参照してください。
また、git を使用して WordPress コアに貢献することもできます。このプロセスについては、コードリポジトリ (Git) を参照してください。
GitHub を利用したい場合は、ハンドブックのgithub のプルリクエストを使用のページで詳細を確認してください。
パッチ
WordPress のコードベースを変更するには、コミット権限を持つ開発者 (コミッターと呼ばれます) が必要ですが、誰でもパッチという形で変更を提案できます。パッチとは、コードの変更点を記述した特別なテキストファイルで、追加、削除、変更されたファイルや行を特定できます。これは、(差分ファイルを生成する UNIX コマンドにちなんで) diff とも呼ばれます。パッチは .patch または .diff という拡張子を持ちます (.diff が望ましいです)。
パッチは、上記のリポジトリのいずれかからチェックアウトされた WordPress trunk の作業コピーを使用して作成されます。Subversion と Git はどちらもコードの履歴を保持し、コミッターが互いの変更を上書きしないよう、一元管理されたリポジトリを提供します (パッチがそれ以降に変更されたコードを変更した場合、コンフリクトが発生します)。このシステムが機能するために、各コミッターは同じリポジトリの作業コピーを保持します。コードは作業コピーとしてローカルにチェックアウトされ、中央リポジトリにチェックイン (コミット) されます。
貢献者も同じプロセスに従いますが、中央のリポジトリを直接変更できないため、自分の変更点を示すパッチを作成します。このパッチは他の貢献者やコミッターの個々の作業コピーに適用され、レビュー、テストが行われ、そしてコミットされる可能性があります。
パッチを書くときは、常に trunk の最新バージョンに更新することが重要です。パッチは、非常にまれな例外を除いて、タグやブランチのようなリリースされたバージョンに対して書かれてはいけません (例: ポイントリリースの準備中)。しかし、trunk は目標が移動するため、パッチが古くなり、更新を必要とすることがあります。なぜなら、中央リポジトリにあるコードが、パッチが変更しようとしている内容と一致しなくなったからです。重要な行やファイルを変更するパッチは、一般的に、遅かれ早かれコミッターに注目されます。[リンク: パッチをコミットさせる]
ローカル開発の概要
コアに貢献するためには、WordPress のローカルインスタンスをインストールすることを強く推奨します。WordPress があなたのマシンで動作していれば、稼働中のサイトに影響を与えることなく変更やパッチのテストを行うことができます。ローカルの開発環境を構築する方法はさまざまです。私たちは、VVV、DesktopServer、MAMP、WampServer、XAMPP のチュートリアルを用意しています。
どれを選ぶか迷った場合は、VVV (Vagrant と表記されることもあります) を推奨します。
Trac の紹介
Trac は、WordPress コミュニティがバグトラッカーおよびプロジェクト管理ツールとして使用しているオープンソースソフトウェアです。Trac を使用することで、開発者はソースコードの履歴を閲覧するだけでなく、バグレポートや機能開発を管理できます。
チケットはバグレポートと機能開発の両方に使用され、WordPress.org のアカウントを持っている人なら誰でも作成できます。
Trac のチケットはコンポーネントに分類され (上記の「コンポーネントメンテナー」を参照)、チケットの詳細を特定するためにキーワードが使用されます。もし、あなたのチケットが見慣れないキーワードでラベル付けされた場合、Trac ワークフローキーワードの完全なリストを参照してください。
グッド・ファースト・バグ
新しい貢献者の参加を容易にするために、いくつかのチケットは「good-first-bug」というキーワードを使い、はじめて取り組むことに適したバグとしてマークされています。これらのチケットは、必ずしも作業が最も簡単というわけではありませんが、自己完結しており、コアチームからのサポートがあります。通常、このチケットは調査され、進むべき道が決定されています。あとは最終的なパッチを作成し、コミットするだけです。このようなチケットは、新しい貢献者 (あなたのような !) が Trac と開発環境の両方で貢献し、作業するプロセスに慣れることを助けるものです。
チケットの提出
誰もがバグレポートや機能リクエストを直接 trac に提出することが推奨されていますが、特定のチケットは他のチケットより優れています。ここでは、あなたのチケットが適切であることを保証するためのアドバイスをいくつか紹介します。
- 要約 – 報告または要求している内容の要約をわかりやすく書きます。要約を書くと、関連するチケットのリストが表示されます。もし、あなたの課題や機能と重複するチケットがあった場合、新しいチケットを提出する必要はありません。現在のチケットを読み、提供できる追加 情報がないことを確認します。もし何か思い当たることがあれば、コメントを追加してください。
- 悪い要約:「メディアモーダルが壊れた !」
- 良い要約:「___ をクリックしたときにメディアモーダルが壊れる」
- 説明 – バグを報告するときは、できるだけ詳しく書いてください。詳しければ詳しいほど、コア貢献者があなたを支援することが容易になります。可能であれば、エラーを再現するために必要な手順をリストアップしてください。機能リクエストを提出する場合は、使用例やユーザー体験の改善など、あなたのアイデアに関する詳細な説明を含めてください。
- キーワード – チケットを提出する前に、キーワード「needs-patch」または「needs-feedback」(詳しくは Trac ワークフローキーワード [link] を参照してください) を使い、チケットが適用される適切なコンポーネントを設定したことを確認してください。これは、コンポーネントメンテナーがチケットを管理することに役立ちます。
セキュリティ脆弱性の報告
WordPress の開発者は、セキュリティの問題を防ぐために最善を尽くしていますが、時々問題が発生し、報告する必要があります。
セキュリティの問題は、責任を持ってベンダーに非公開で開示することが標準的な方法です。この場合、WordPress のコア開発チームです。WordPress の貢献者は、他のベンダーに問題を報告する際にも、責任をもって情報を開示します。公開前に責任を持って問題を報告することで、ベンダーはセキュリティの脆弱性を修正し、ユーザーへの被害を最小限に抑える時間をもつことができます。
つまり、セキュリティ脆弱性を含む可能性のあるチケットを提出する前に、丁寧な対応を心がけて注意することです。WordPress セキュリティチームに責任を持って問題を報告する方法については、ハンドブックのセキュリティ脆弱性の報告ページを参照してください。
最初のパッチ
WordPress の開発環境に変更を加え、その変更に満足したら、trac チケットに添付できるようなパッチを作成したいと思うことでしょう。これを行うには多くの方法があります。
SVN のルートディレクトリ (VVV インスタンスの wordpress-develop フォルダー) でコマンドラインから次のコマンドを実行すると、パッチが生成されます: svn diff > 00000.diff
他にも、UI ベースでパッチを作成する方法があります。SourceTree は、コマンドラインを使用する優れた代替手段です。Josh Pollock は、この方法を使ってパッチを作成する方法をチュートリアルに書いています。
WordPress の開発は、私たちの公式な SVN および Git リポジトリで行われます。そのため、GitHub からのプルリクエスト (PR) を監視したり、受け入れることはありません。しかし、Git リポジトリからパッチを作成し、チケットに添付できます。そのためには、
履歴を調べる
ときには、何年も前から開かれているチケットを発見するかもしれません。多くの場合、これらのチケットには更新が必要なパッチが含まれています。なぜコードが変更されたのか、そして更新がどのように処理される必要があるのかを知ることが重要です。trunk を閲覧すると、WordPress を構成する各ファイルのコードを見ることができるのがわかるでしょう。
たとえば、/wp-admin/media.php を見てください。リンクをたどると、ブラウザの上部に表示される url が WordPress のファイル構造に似ていることが分かると思います。URL に ?annotate=blame を追加すると、左側のサイドバーに色が付いたページが読み込まれます。��れらは、ファイルに加えられたチェンジセットです。これはコードが変更された理由を特定することに役立ち、変更にいたった議論をよりよく理解するために関連するチケットを見つけることを可能にします。(通常は Fixes:xxxxx のように表示されます)
ユニットテスト
パッチのフィードバック
チケットやパッチの作業では、フィードバックが常に推奨されます。もしチケットやパッチの方向性について質問やコメントがある場合は、チケットにコメントを追加してください。
このページの冒頭で述べたように、WordPress はあらゆる背景を持つ貢献者によるグローバルなプロジェクトです。そのため、フィードバックにはできるだけ敬意を払い、丁寧に対応してください。あなたの生活に適用される社会規範は、他の貢献者のものとはまったく異なるかもしれません。また、他人からどのようなフィードバックを受けるか気を配り、文化や言語の違いにより意図したものとは異なる印象を与える可能性があることに注意してください。
気にしないでください ! 時々、私たちは建設的なフィードバックを与えたり受けたりしますが、それを個人的なものとして受け取ってしまうことがあります。個人的なことではありません。貢献者の意図は、あなたと同じように、WordPress をより良くすることです !
パッチが適用されない
先に述べたように、古いチケットには、現在のコードベースにはもはや適用できないパッチが添付されていることがよくあります。チケットが古ければ古いほど、関連するパッチがきれいに適用される可能性は低くなります。もし、適用されないパッチが添付されたチケットを見つけたら、それを示すために「needs-refresh」キーワードを追加してください。
時間が経つにつれて、コードが移動し、ときにはこれらのパッチを適用するために少し再構成することが必要になる場合があります。また、リファクタリングされたコードが見つかり、提案されたバグや機能強化のために代わりの解決策が必要になることもあります。これが終わったら、きれいなコードで新しいパッチを作成し、チケットに投稿してください。
(コードのリファクタリングといえば、コアチームはコードのリファクタリングだけを行うパッチをほとんど受けません。詳しくはコードリファクタリングのページをご覧ください)
コミットの準備
パッチがコミットできる状態になったら、今度はそれをレビューして WordPress コアにコミットしてくれるコミッターを探します。あなたのコードに最も適したレビュアーは、通常はコンポーネントメンテナー [link] (上記参照) ですが、どんなコミッターでもあなたのパッチをレビューし、コミットできます。
パッチに関するフィードバックを得るもうひとつの方法は、毎週のコア開発者チャット (以下を参照してください) の最後に行われる「オープンフロア」でフィードバックを求めることです。この方法をとる場合、チャットの最中ではなく、ミーティングの終わりまで待つようにしてください。
時々、チケットやパッチが注意されず、trac に残ってしまうことがあります。このような場合は、コンポーネントのメンテナーやコミッターに通知を送り、フィードバックを求めてください。
ミーティング
最終更新日: