このガイドは、コントリビューターデイを開催するためのものです。このガイドには、グループが何をするのか、どのようにすればすぐに始められるのかの概要が含まれています。サポートが必要な場合は、コントリビューターデイのオーガナイザーに相談するか、Slack の #core チャンネルで質問してください。
これは進行中の作業であるため、特にあなたがコントリビューターデイに参加していて、何かを見落としていることに気づいた場合は、遠慮なくドキュメントを修正したり、コメントを残してください。
グループの責任
コアグループの責任は次のとおりです:
- コードのメンテナンスと、将来に向けての開発
- WordPress の新機能の開発
- デザインと UX の維持と改善
- デフォルトのテーマの設計、開発、保守
- コアの開発に使用されるユーティリティのメンテナンス
- デフォルトのプラグインのバンドルパッケージのメンテナンス
- コアで利用可能なバンドルライブラリのメンテナンス
- バグトラッカーのメンテナンス
共通のタスク
コアグループのメンバーとして実行する一般的なタスクは次のとおりです:
- パッチのテストとバグの修正
- 安定性とセキュリティに関する問題の処理
- 新しい機能のコードを書く
- ユーザーインターフェイスに取り組む
- 新機能のユーザーテスト
- WordPress の安定性を維持するためのユニットテストの作成
- バグガーデニング
- コーディング規約のパッチを確認する
- アクセシビリティとプライバシーの問題についてパッチをレビューする
予備知識
コアの作業に役立つ予備知識は次のとおりです:
- CSS、PHP、JavaScript、React など、手伝いたいコーディング言語を理解していること
- WordPress に精通していると役に立ちますが、始めるためにコアについて深く理解する必要はありません
ツール
- バージョン管理システム: SVN または Git
- ローカル開発環境。例: MAMP、WAMP、Vagrant、XAMPP、または WP-ENV
- ユニットテストの場合、PHPUnit
- アセットのコンパイル、リリースパッケージのビルド、JavaScript と PHP のテストのための Grunt
- Javascript テストのための QUnit
- PHP_CodeSniffer の WPCS ルール
必読書
- コアコントリビューターハンドブックの、取り組んでいる内容に関連するセクション
- コードを書いている場合は、WordPress コーディング規約
最初のステップ
最初のステップは、ローカル環境をセットアップすることです。
- SVN のインストール: バージョン管理システムのインストール
- ローカルサーバーのインストール: Mac | Windows | Windows (代替)
- SVN を使用して WordPress コードベースを確認する
その後に:
- WordPress で問題が見つかった場合は、Trac でチケットを開くことができます。
- バグの修正
- パッチを作成して適用する
他にも、次のような方法で手助けできます:
- バグガーデニング
- ベータ版またはリリース候補が利用可能な場合は、アルファ版またはベータ版のテストを試してみてください
- ユニットテストを書く
- UI 中心の機能を手助けしたい場合は、プラグインとしての機能に関する情報を確認してください
- 特定のコンポーネントにフォーカスしたい場合は、WordPress コアコンポーネントのリストを確認してください。
タスク
初めての貢献者が、コントリビューターデイで簡単に始められるタスクがいくつかあります:
- good first bug タグをチェックする
- インラインドキュメントを更新する
- ユーザーインターフェイスに取り組み、UI フォーカスを確認する
- 開発者フィードバックを提供する
- デザインに関するフィードバックを提供する
- コピーに関するフィードバックを提供する
- プライバシーに関するフィードバックを提供する
- 適用されていない、またはアップデートが必要な既存のパッチを更新する
- バグガーデニングに挑戦してみる (Helen が、始めるときに役立つ良い記事を投稿しています)
Gutenberg への貢献
前提条件
npm のバージョンが最新かどうかわからない場合は、以下のコマンドを実行してください:
npm install npm@latest -g
- Docker – https://docs.docker.com/install/
Gutenberg の GitHub リポジトリにある Contributing.md に、ローカル環境を構築するための便利なガイドがあります。そこには、ローカル環境の起動と実行に役立つコマンドが記載されています。
通常セットアッププロセスは、Gutenberg ディレクトリで次のコマンドを実行することで完了できます (Windows を使用している場合は、Powershell が有効です)。
./bin/setup-local-env.sh
スクリプトは、前提条件が満たされていることを確認するプロセスを段階的に実行します。何かが不足している場合、スクリプトはセットアップを完了するために何をする必要があるかを報告します。提案された変更を行った後、スクリプトを数回再実行するとセットアップが完了します。
ローカル環境で Gutenberg の開発版を起動したら、Gutenberg ディレクトリから以下を実行してください:
npm run dev
これは、あなたが行った変更を監視/更新します。
WordCamp コントリビューターデイでの膨大なダウンロードを避けるため、イベントの前に環境を設定することを推奨します。
Gutenberg の Good First Issues
Gutenberg への貢献に慣れるために、割り当てられていない最初の issue を探している場合は、こちらをご覧ください。
Gutenberg 最初の issue の手順
- Gutenberg リポジトリを自分のアカウントにフォークする。
git clone
を使用して、自分の「plugins」ディレクトリにフォークしたリポジトリをクローンする。- フォークの中に新しいブランチを作成し、ブランチ名のどこかに issue 番号を入れる
(例:fix-admin-align-center-12306
は、issue のブランチ名としてよいでしょう: “Latest Posts block “align center” has no effect in admin #12306”) - 最初のコミットを行う
- 以下を使用してブランチを公開する:
git push -u origin <branch name>
これで、ローカルで問題を修正する準備ができました。完了したら、変更をコミットしてブランチにプッシュします。
変更を Gutenberg にマージするためにレビューに出す準備ができたら、github.com から自分のブランチに移動してプルリクエストを作成します。プルリクエストを作成し、フォームに必要事項を入力してください。