Skip to content

Latest commit

 

History

History
351 lines (279 loc) · 16.6 KB

CONTRIBUTING_ja.md

File metadata and controls

351 lines (279 loc) · 16.6 KB
Raw

Node.js への貢献

(この日本語訳は 2016/10/16 a4d396d85874046ffe6647ecb953fd78e16bcba3 時点の https://github.com/nodejs/node/blob/master/CONTRIBUTING.md の翻訳です。)

行動規範

行動規範は、Node Foundationが貢献者に求める必要最小限の振る舞いを解説したものです。始める前にこちらを読んで下さい。

Issue 貢献

このレポジトリで新しい issue や既存の issue にコメントするときは、Node.js の具体的な技術的課題に関する議論であることを確かめてください。

Node.jsの利用に関する一般的な質問は、Node.js help repository に issue を出してく ださい。

知的財産権、登録商標や高レベルのプロジェクトの質問のような非技術的なト ピックスの議論は、Technical Steering Committee (TSC) で行ってください。

コード貢献

Node.jsプロジェクトはオープンガバナンスモデルを取っていて、新しい貢献者を歓迎しています。重要で価値のある貢献をしている個人は、Collaborators になっていただき、プロジェクトへのコミット権限を与えられます。 このガバナンスがどうなっているのか、さらなる情報はGOVERNANCE.md を見てください。

この文書は、皆さんにコード貢献する方法を伝えるものです。

ステップ 1: フォーク

GitHub上のプロジェクトをフォークして、自分のローカルコピーにチェックアウトします。

$ git clone git@github.com:username/node.git
$ cd node
$ git remote add upstream git://github.com/nodejs/node.git

どのブランチ？

バグ修正や新機能の開発には、master ブランチを pull してビルドします。

stability indexを尊重する

masterブランチに対する規則は、それほど厳しくありません。詳細は、stability index を見てください。

簡単に書くと、モジュールは様々なAPI stabilityのレベルになっています。バグ修正はどのAPIに対しても常に歓迎されます。stabilityレベル3(Locked)のモジュールに対するAPIやその挙動の変更は、禁止されています。

依存性

Node.jsは、deps/ と tools/ ディレクトリにプロジェクト固有でない依存ソフトウェアをバンドルして持っています。それらのディレクトリやサブディレクトリにあるファイルへの変更は、それぞれに対応するプロジェクトに送られるべきです。我々にパッチを送らないでください。受け入れることはできません。

わからない場合は、issue tracker に issue を出すか、project Collaboratorsの一人に尋ねてください。特に何か大きな作業をするつもりなら問い合わせをしてください。あなたの大変な作業がプロジェクトチームのビジョンと合っていないために無駄になってしまう程もったいないことはありません。 Node.jsは2つのIRCチャンネルを持っています。一般的な質問やヘルプに対しては、 #Node.js へ、 特にNodeコアに開発に関することは、 #Node-dev にお願いし ます。

ステップ2: ブランチ

ブランチを作成してハッキングを始めます。

$ git checkout -b my-branch -t origin/master

ステップ 3: コミット

git にあなたの名前と電子メールアドレスが登録されているか確認すること。

$ git config --global user.name "J. Random User"
$ git config --global user.email "j.random.user@example.com"

良いコミットログを書くことは非常に重要です。コミットログは何をなぜ(what and why)変更したのか記載するべきです。コミットログを書くときには次に挙げるガイドラインに従います。

  1. 最初の行は、50文字以下で変更点を短く記載したものを書きます。記載する文字は固有名詞、頭字語、関数や変数名などコードを参照するもの以外は全て小文字で書きます。変更するサブシステムの名前を文頭に記載し、続いて命令形にします。 例えば "net: add localAddress and localPort to Socket" の様に書きます。
  2. 2行目は空行にします。
  3. それ以外の行は全て72文字で改行して記載します。

良いコミットログは次のようなものです。

subsystem: explain the commit in one line

Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc. etc.

The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
72 characters or so. That way `git log` will show things
nicely even when it is indented.

ヘッダ行は意味ある記載にすべきです。他の人々が git shortlog や git log --oneline を実行したときに見るものになります。

どのサブシステムをあなたが変更したか git log --oneline あなたが変更したファイル の出力でチェックしましょう。

もしあなたの修正が、オープンされている issue を修正するものなら、ログの最後にその issue への参照を追加しましょう。 Fixes: を頭に付けて、issueのURLを追加します。例えば、

Fixes: https://github.com/nodejs/node/issues/1337

ステップ4: リベース

あなたの作業と同期する際は、毎回 git rebase を使いましょう。git merge ではありません。

$ git fetch upstream
$ git rebase upstream/master

ステップ5: テスト

バグ修正や新規機能追加は、必ず テストをつける べきです。 test/parallel/ ディレクトリにテストを追加してください。 Node.jsにテストを各方法のガイドは、この ガイドを見てください。他のテストがどういう風に作られているのか見ることも役に立つでしょう。

UnixやOS Xでテストを実行するには、次の様にします。

$ ./configure && make -j8 test

Windowsでテストを実行するには、次の通りです。

> vcbuild test

(詳細は、 BUILDING.md を見てください。)

linterが正常に完了し、全てのテストが通ることを確認してください。どちらかのチェックが失敗するようなパッチを送らないでください。

make test や vcbuild test は、テストが失敗しなければ linter も実行します。

テストをせず linter だけ実行したい場合は、make lint や vcbuild jslint を行ってください。

もしテストを更新して一つのテストを実行して確認したいなら、テストハーネスとして次のやり方ができるでしょう。

$ python tools/test.py -v --mode=release parallel/test-stream2-transform

nodeを使って直接テストを実行することもできます。

$ ./node ./test/parallel/test-stream2-transform.js

コアモジュールを変更したらテストを実行する前に make -j8 で再コンパイルすることを忘れないように。

ステップ 6: プッシュ

$ git push origin my-branch

その後 https://github.com/yourusername/node に行って、あなたのブランチを選びます。'Pull Request' をクリックして、フォームの記載を埋めます。

プルリクエストは通常数日以内にレビューされます。対処するコメントがあれば、別のコミットに変更を適応してあなたのブランチにプッシュしましょう。 その後プルリクエストにコメントしましょう。GitHubはコミットを追加しても通知をしてくれません。

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

  • (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

  • (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

  • (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

  • (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

（訳者注) DCOに関しては、 https://www.kernel.org/doc/Documentation/ja_JP/SubmittingPatches より和訳を引用します。

原作者の証明書( DCO ) 1.1

このプロジェクトに寄与するものとして、以下のことを証明する。

  • (a) 本寄与は私が全体又は一部作成したものであり、私がそのファイル中に明示されたオープンソースライセンスの下で公開 する権利を持っている。もしくは、

  • (b) 本寄与は、私が知る限り、適切なオープンソースライセンスでカバーされている既存の作品を元にしている。同時に、私 はそのライセンスの下で、私が全体又は一部作成した修正物を、ファイル中で示される同一のオープンソースライセンスで(異なるライセンスの下で投稿することが許可されている場合を除いて)投稿する権利を持って

  • (c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供されたものであり、私はそれに変更を加えていない。

  • (d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意する。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を含む)が無期限に保全されることと、当該プロジェクト又は関連するオープンソースライセンスに沿った形で再配布されることに理解及び同意する。