jekyll/docs/jp/CONTRIBUTING.jp.markdown

5.5 KiB

コントリビュート

あなたは Jekyll に投じるすばらしいアイディアを持っています。 すばらしいことです!次の事柄を心に留めてください。

  • テストなしではコントリビュートはできません。
  • もし、既存の機能への小さな修正やパッチを作成したなら、シンプルなテストを行います。 現在のテストスイートの範囲にとどまり、そして ShouldaRR を使用してください。
  • もし、それが新しい機能の場合は、必ず新しい Cucumber の機能を作成し、 必要に応じて手順を再利用します。 また、あなたがフォークした site に 急ぎいくつかのドキュメントを用意し、一度マージを行い メイン site の jekyllrb.com に転送していただければ幸いです。
  • あなたのコントリビュートによって Jekyll の振る舞いが変わった場合、ドキュメントを更新すべきです。 それは site/docs にあります。 もし、 docs に情報の誤りがあった場合、遠慮なく追加してください。 すばらしいドキュメントはすばらしいプロジェクトを作ります!
  • Ruby のコードを変更するときは、 GitHub Ruby Styleguide に従ってください。
  • 小さなプルリクエスト に最善を尽くしてください。 簡単に提案された変更はレビューされ、マージされる可能性が高いです。
  • プルリクエストを送信するとき、プルリクエストのボディを賢明に使用してください。 変更されたかどうかの記述、変更の背後にある動機、 完了したかどうかのタスクリスト もレビュー時間を早めます。

テストの依存関係

テストスイートの実行や gem のビルドのために、 Jekyll の依存ツールをインストールする必要があります。 Jekyll は Bundler を使用しており、 bundle コマンドを実行すると全ての設定が迅速に行われます!

$ bundle

はじめる前に、テストを実行し、必ずテストが通ることを 確認してください(あなたの環境が適切に設定されているかを確認するために):

$ bundle exec rake test
$ bundle exec rake features

ワークフロー

これは、あなたの作業がプロジェクトにマージされるもっとも直接的な方法です:

  • プロジェクトをフォークします。
  • あなたのフォークプロジェクトをクローンします ( git clone git@github.com:<username>/jekyll.git )。
  • トピックブランチを作成し、あなたの変更を含んでください ( git checkout -b my_awesome_feature )。
  • ハックし、テストを追加します。必ずしもこの順番でなくてかまいません
  • rake を実行し、テストが必ず全て通ることを確認してください
  • 必要に応じて、エラーがないようにコミットを論理的な塊にリベースしてください
  • ブランチをプッシュしてください ( git push origin my_awesome_feature ).
  • jekyll/jekyll プロジェクトの master ブランチに対してプルリクエストを作成し、 あなたの変更内容と、なぜそれをマージすべきかを記述してください

ドキュメントの更新

私たちは Jekyll のドキュメントについて最善を尽くしたいです。 私たちはドキュメントをオープンソース化しました、そして あなたが Jekyll に欠けているものを見つけた場合、私たちはプルリクエストを歓迎しています。

あなたは、 GitHub.com 上の Jekyll リポジトリの [site]({{ site.repository }}/tree/master/site) で jekyllrb.comのドキュメントを見つけることができます。

全てのドキュメントのプルリクエストは master に向けられる必要があります。 他のブランチに向けたプルリクエストは受け入れられません。

GitHub の Jekyll wiki は、 自由に更新することができるように、プルリクエストなしで 全ての GitHub ユーザがアクセス権を持つことができます。

落とし穴

  • もし、 gem のバージョンがかちあった場合、コミットを分けてください。 この方法だと、メンテナが gem をリリースするときに制御できます。
  • jekyll/jekyll の最新コミットに基づいて(複数の)パッチを維持してください。 それは適用するためのあなたの仕事で、メンテナがしなければならないことを少なくするのは とてもよいことです。
  • あなたの GitHub issue で [fix], [feature] などのタグをつけないでください。 メンテナは積極的に issue を読み、彼らが問題に出くわしたらラベルをつけるでしょう。

最後に…

ありがとう! Jekyll のハックは楽しいものでなければなりません。 もし、あなたがこのハードを理解するための何かを発見した場合、知らせてください。 我々のプロセスやドキュメントを改善することができます!