concrete5 では、4つのタイプのバグが存在し、もしもバグが concrete5 コアのものであれば、報告や修正を GitHub でお願いしています。また機能要望などもあると思います。
今回は concrete5 の GitHub にどのようにして、バグ報告や機能報告をして、そしてできれば Pull Request を送ってしまいませんかという提案・解説記事です。
なお、この方法は、concrete5 のみならず、オープンソースプロジェクトで結構一般的な内容なので、他のオープンソースプロジェクトに関わっている人も参考にしてみてください。
STEP1: バグのタイプを見極める
バグのタイプ
状況を見極めて、下記の4種類のタイプのバグや不具合があるのを見極めます。
- パターンA. サーバーや、アドオンに関連したバグで concrete5 コアプログラムとは関係ないもの
- パターンB. リリース済みの concrete5 のバージョンで発生しているバグだが、最新の GitHub 上では解決しているバグ
- パターンC. 自分のカスタマイズ部分のバグ
- パターンD. concrete5 の開発中 GitHub の最新の状態でも再現できるバグ
- パターンE. 上記のどのカテゴリに属しているかわからないバグ
パターンE. どのカテゴリに属しているかわからないバグ
- concrete5.org の Bug Tracker フォーラム に投稿して原因を探る
- concrete5 日本公式サイトの バグ情報フォーラム に投稿して原因を探る
- コンクリートファイブジャパン株式会社の テクニカルサポートプランや、 concrete5 インテグレートパートナー の会社に頼めるか聞いてみる。（有償サポートなので確実に返答します。但し直す作業までの確証はなく、作業を行う場合は別途費用がかかる場合も）
以上の方法で 1~4 のどの問題なのかがわかるかも。
パターンA. サーバーや、アドオンに関連したバグで concrete5 コアプログラムとは関係ないもの
サーバー会社や、アドオンの作成者に修正・修復の依頼を行う必要があります。
パターンB. リリース済みの concrete5 のバージョンで発生しているバグだが、最新の GitHub 上では解決しているバグ
バグが修復された concrete5 の最新バージョンにアップグレード。もしくは、どうしてもアップグレードが出来ない場合、バグの修正部分のパッチを作成してパッチを当てる必要があります。
アップグレードやパッチあてを自分で行うのが不安な方は、コンクリートファイブジャパン株式会社の concrete5 保守サポートや、 concrete5 インテグレートパートナー の会社に頼めるか聞いてみる。
でも、一回、テスト環境を作って挑戦してみるのも価値あります！。
パターンC. 自分のカスタマイズ部分のバグ
ご自分のカスタマイズ部分のバグであれば、ご自分で直していただくことが基本となりますが、
- concrete5 日本公式サイトの 開発・構築フォーラム などに質問を投稿する
- コンクリートファイブジャパン株式会社の テクニカルサポートプランや、 concrete5 インテグレートパートナー の会社に頼めるか聞いてみる。（有償サポートなので確実に返答します。但し直す作業までの確証はなく、作業を行う場合は別途費用がかかる場合も）
というオプションがあります。
パターンD. concrete5 の開発中 GitHub の最新の状態でも再現できるバグ
是非とも GitHub の Issue に問題を英語で登録してください。加えて具体的な解決方法を提案してくれるとなおさら良いです。
機能追加を要望したい
concrete5 では常にコアの機能追加要望を受け付けています。
具体的なコードの変更方法などの具体先がわかっている場合は、GitHub の Issue に登録し、具体的なコードの修正案はわからないけど、機能追加したい場合は、concrete5 日本公式サイトの 機能要望 トピックに投稿してください。
もしかしたら、アドオンとして機能追加したほうが良い場合もありますが、需要がなければ供給されません。ぜひみなさんの機能追加要望をお願いします。
STEP2: GitHub で Issue を登録する準備
ということで、最新版の GitHub のレポジトリでもバグが起こっていたり、具体的なコードの変更方法がわかるような機能追加要望がある場合は、GitHub の Issue で管理を行います。
concrete5 の GitHub の Issue に登録していただきたいのですが、その前に必ず確認してもらいたいことがあります。
-
concrete5 の GitHub を Cloud9 で作って最新のベータ版をテストできる環境を作るを参考に、最新の develop ブランチでもバグが再現できるかを再確認する。
- 最新の GitHub の develop ブランチで直っている場合は過去のコミットログを探して、どこがどういう変更をされているのかを探してそのパッチを自分の concrete5 に当ててみる。
- わからない場合は concrete5 日本公式サイトの バグ情報フォーラム などに助けを求める
- バグが再現できれば concrete5 GitHub に訪問して、既に同じ内容の Issue が登録されていないか、検索してみる。
- デフォルトでは
is:issue is:openという、課題でまだオープンという条件が加えられているが、検索で引っかからなかった場合は、念のためにクローズ済の課題もないか検索してみる。 - 検索の単語は、シンプルなバグの問題に関連する単語を使って検索してみる。
- デフォルトでは
- また問題は、実は concrete5 本体の問題ではないかもしれません
- 日本語訳の誤訳の問題は Transifex で修正を受け付けます。
- Javascript や PHP のライブラリの問題であれば、concrete5 のレポジトリではなく
- Issue が見つからなかった時に初めて Issue を登録する。
STEP3: Issue を登録
さて、Issue を登録してもらいます。
- 右側の「New Issue」という緑色のボタンを押してください
- 具体的にバグの内容を説明してください。簡潔な説明を求められますが、下記のような説明が加わっていると良いかもです。
- concrete5 の動いている環境、サーバーなどの情報
- ページにはどういう設定がしているのか
- まっさらの concrete5 をインストールしてからバグが発生するまでのステップごとの手順
- どのようにバグが発生するか
- 可能であればスクリーンショットやエラー分のコピペ。ただし、個人情報やサーバーが特定できるような情報は必ず取り除いてください。この Issue は公開されます。
- Issue を書いたら投稿。
- コメントなどはに丁寧に投稿しましょう。
STEP4: Issue が受け入れられたら
議論のやりとりをして、Issue が受け入れられたら、可能であれば自分で Pull Request を作ってみましょう。
- concrete5 GitHub からレポジトリを自分のレポジトリに Fork
- その課題に取り掛かる専門のブランチを作成
- 修正コードを書く
- commit & push をする
- プルリクエストを作成する。
- プルリクエストのタイトルに、上記で登録した課題のものだということを示すために、 #9999 などと Issue の番号を入れる
オープンソースの良いところは自分のコードが数千、数万のサイトに使われるという喜びです。
皆さんも是非、 concrete5 への貢献をよろしくお願いいたします。
宣伝 & クレジット
この記事が役に立ったら、「 CMS は concrete5 が一番」と頭の中で10回唱えてください。
CMS は断然 concrete5で決まり。コンクリートファイブジャパン株式会社がサポートできます。