|
| 1 | +--- |
| 2 | +title: Bitcoin Coreにコードを貢献する方法 |
| 3 | +name: contributing-guidelines |
| 4 | +id: ja-contributing-guidelines |
| 5 | +permalink: /ja/faq/contributing-code/ |
| 6 | +layout: page |
| 7 | +type: pages |
| 8 | +lang: ja |
| 9 | +category: faqs |
| 10 | +version: 2 |
| 11 | +--- |
| 12 | + |
| 13 | +Bitcoin Coreプロジェクトは、誰もがレビュー、テストおよびパッチの提供といった形で開発に向けて貢献することを歓迎するオープンなコントリビュートモデルで運営しています。このドキュメントでは、貢献にあたっての実用的なプロセスとガイドラインについて説明します。 |
| 14 | + |
| 15 | +最初に組織について、特権を持つ人々という意味での「コア開発者」という特別な概念はありません。オープンソースは、よく長期的な貢献者が開発者コミュニティからより多くの信頼を得る実力主義を中心に展開します。ただし、実用的な目的である程度の階層が必要です。そのため、プルリクエストのマージを担当する「メンテナー」や、リリースサイクル、全体的なマージおよびメンテナーの任命を担当する「リードメンテナー」が存在します。 |
| 16 | + |
| 17 | +貢献者のワークフロー {#contributor-workflow} |
| 18 | +-------------------- |
| 19 | + |
| 20 | +コードベースは、例外なく「プルリクエスト」を使ったパッチの提案を行う「貢献者のワークフロー」によりメンテナンスされます。これは社会的な貢献を促進し、テストやレビューを容易にします。 |
| 21 | + |
| 22 | +パッチを提供するためのワークフローは以下の通りです: |
| 23 | + |
| 24 | +- リポジトリをフォークする |
| 25 | +- トピックブランチを作成する |
| 26 | +- パッチをコミットする |
| 27 | + |
| 28 | +[Developer Notes](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md)に記載されているプロジェクトコーディング規約を遵守する必要があります。 |
| 29 | + |
| 30 | +一般的に、[コミットはアトミックで](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention)、差分は読みやすくあるべきです。このため、フォーマットの修正やコードの移動を実際のコードの変更と混同しないでください。 |
| 31 | + |
| 32 | +コミットメセージはデフォルトで、短い件名（最大50文字）、空行、別の段落の詳細な説明文で構成されています。（「Corrected typo in main.cpp」のように）タイトルだけで修正内容が自明の場合はタイトル1行で十分です。コミットメセージは将来あなたのコード読む人に役立つはずなので、あなたの決定の理由を説明してください。詳細は[こちら](http://chris.beams.io/posts/git-commit/)。 |
| 33 | + |
| 34 | +あるコミットが別の課題を参照している場合は、`refs #1234`や`fixes #4321`のように参照を追加してください。`fixes`や`closes`キーワードを使うとプルリクエストがマージされた際に、対応する課題がクローズされます。 |
| 35 | + |
| 36 | +Gitの詳細については[Gitのマニュアル](https://git-scm.com/doc)を参照してください。 |
| 37 | + |
| 38 | + - あなたのフォークに変更をプッシュする |
| 39 | + - プルリクエストを作成する |
| 40 | + |
| 41 | +プルリクエストのタイトルにはプルリクエストが影響を与えるコンポーネント、領域をプレフィックスとして付与する必要があります。例えば、 |
| 42 | + |
| 43 | + Consensus: Add new opcode for BIP-XXXX OP_CHECKAWESOMESIG |
| 44 | + Net: Automatically create hidden service, listen on Tor |
| 45 | + Qt: Add feed bump button |
| 46 | + Trivial: Fix typo in main.cpp |
| 47 | + |
| 48 | +プルリクエストが（まだ）マージについて考慮されていない場合は、タイトルに[WIP]を付けるか、プルリクエストの本文の[タスクリスト](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists)を使ってタスクが保留中であることを示してください。 |
| 49 | + |
| 50 | +プルリクエストの本文には、パッチとその根拠/論拠について十分な説明を含める必要があります。（例えば他のチケットやメーリングリストでの議論など）議論への参照を含める必要があります。 |
| 51 | + |
| 52 | +この段階で、他の貢献者からのコメントやレビューを期待しましょう。全てのフィードバックを満たすまで、ローカルにコミットしあなたのフォークにプッシュすることで、プルリクエストにさらにコミットを追加することができます。 |
| 53 | + |
| 54 | +スカッシュコミット {#squashing-commits} |
| 55 | +----------------- |
| 56 | +あなたのプルリクエストのマージが受け入れられた場合、マージされる前にメンテナーからあなたのコミットをsquashもしくは[rebase](https://git-scm.com/docs/git-rebase)するよう依頼されるかもしれません。基本的なsquashのワークフローは以下の通りです。 |
| 57 | + |
| 58 | + git checkout your_branch_name |
| 59 | + git rebase -i HEAD~n |
| 60 | + # n is normally the number of commits in the pull |
| 61 | + # set commits from 'pick' to 'squash', save and quit |
| 62 | + # on the next screen, edit/refine commit messages |
| 63 | + # save and quit |
| 64 | + git push -f # (force push to GitHub) |
| 65 | + |
| 66 | +レビューに必要な期間は予測不可能であり、プルリクエスト毎に異なります。 |
| 67 | + |
| 68 | + |
| 69 | +プルリクエストの哲学 {#pull-request-philosophy} |
| 70 | +----------------------- |
| 71 | + |
| 72 | +パッチセットには常にフォーカスすべきです。例えば、プルリクエストは機能を追加したり、バグを修正したりコードをリファクタリングしたりできますが、混同してはいけません。また過度であったり、大きすぎたり、複雑すぎるスーパープルリクエストもレビューが困難になるため避けるべきです。 |
| 73 | + |
| 74 | +### 新しい機能 {#features} |
| 75 | + |
| 76 | +新しい機能を追加する際は、機能の追加後にその機能に必要となる可能性がある長期的な技術的債務および保守について考慮する必要があります。保守を必要とする新しい機能を提案する前に、あなたがそれを保守しても構わない（バグ修正を含む）と思っているかどうか考えてください。将来、機能が保守なく孤立した場合、それらはリポジトリメンテナーによって削除されるかもしれません。 |
| 77 | + |
| 78 | +### リファクタリング {#refactoring} |
| 79 | + |
| 80 | +リファクタリングはソフトウェアプロジェクトの進化に不可欠な要素です。以下のガイドラインはプロジェクトへのリファクタリングのプルリクエストについて説明しています。 |
| 81 | + |
| 82 | +リファクタリングには、コードの移動のみ、コードスタイルの修正、コードのリファクタリングという３つのカテゴリがあります。一般的にリファクタリングのプルリクエストは、リファクタリングプルリクエストのレビューを簡単にし、物議を醸さないよう、これら３つの種類のリファクタリングを混在させないでください。全ての場合において、リファクタリングPRはプルリクエスト内でコードの振る舞いを変えてはいけません（バグも現状のまま残さなければなりません）。 |
| 83 | + |
| 84 | +プロジェクトメンテナーはリファクタリングプルリクエストの迅速な解決を目指しているので、可能な限りそれらを短く、単純で検証しやすいものにしてください。 |
| 85 | + |
| 86 | + |
| 87 | +「意思決定」プロセス {#decision-making-process} |
| 88 | +------------------------- |
| 89 | + |
| 90 | +以下はBitcoin Coreプロジェクト（およびlibsecp256k1などの関連プロジェクト）のコードを変更する際に適用されます。全体的なBitcoin Networkプロトコルのコンセンサスの変更と混同しないでください。 |
| 91 | + |
| 92 | +プルリクエストがBitcoin Coreにマージされるかどうかは、プロジェクトのマージメンテナーおよび最終的にはプロジェクトリーダーにかかっています。 |
| 93 | + |
| 94 | +メンテナーはパッチがプロジェクトの一般原則に沿っているか、マージのための最低基準を満たしているかを考慮し、貢献者の一般的なコンセンサスを判断します。 |
| 95 | + |
| 96 | +通常、すべてのプルリクエストは以下を満たさなければなりません： |
| 97 | + |
| 98 | + - 明確なユースケースを持ち、明確なバグを修正するか、プロジェクトにより良い成果をもたらす（例えばモジュール化のためのリファクタリングなど） |
| 99 | + - よくレビューを受けている |
| 100 | + - 適切な単体テストおよび機能テストがある |
| 101 | + - コードスタイルガイドラインに沿っている |
| 102 | + - 既存のテストスイートを破壊していない |
| 103 | + - バグが修正されている場合、可能であれば、バグを実証しその修正を証明する単体テストがあるべきです。これは回帰を防ぐのに役立ちます。 |
| 104 | + |
| 105 | +Bitcoinのコンセンサスルールを変更するパッチは、エコシステム全体に影響を与えるため、通常よりもかなり複雑です。そのため、メーリングリストで広範に議論され、番号が付けられたBIPが必要です。それぞれのケースで異なりますが、レビューの増加とコンセンサスの要件により他の種類のパッチより多くの時間と労力を費やす準備をする必要があります。 |
| 106 | + |
| 107 | +### レビュー {#peer-review} |
| 108 | + |
| 109 | +プルリクエストのコメントで表現されるレビューには誰でも参加できます。通常、レビュー担当者は明らかなエラーについてコードをレビューし、パッチセットをテストし、技術的な利点について意見を述べます。プロジェクトメンテナーはプルリクエストをマージするというコンセンサスがあるかどうかを判断する際にレビューを考慮に入れます（議論はgithubおよびメーリングリスト、IRCに分散しているかもしれません）。以下の用語はプルリクエストのコメント内で使用されています。 |
| 110 | + |
| 111 | + - ACK は「コードをテストし、マージする必要があることに同意します」という意味です。 |
| 112 | + - NACK は「これをマージすべきではない」という意味で、適切な技術的正当性を伴う必要があります。根拠を伴わないNACKは無視されるかもしれません。 |
| 113 | + - utACK は「コードはテストしていませんが、レビューし、大丈夫のように見えるのでマージに同意します」という意味です。 |
| 114 | + - Concept ACK は「このプルリクエストの一般原則に同意します」という意味です。 |
| 115 | + - Nit は細かい指摘で、多くの場合ノンブロッキングな課題です。 |
| 116 | + |
| 117 | +レビュー担当者は、レビューしたコミットハッシュをコメントに含める必要があります。 |
| 118 | + |
| 119 | +プロジェクトメンテナーは、常識的な判断、また実力主義に基づいてレビュー担当者の意見を量る権利を保持します。プロジェクトについてより（時間の経過とともに）深いコミットメントや理解を示している、或いは明確なドメインの専門知識を持っている人は、全ての人生の歩みでもそうであるように、当然より重要性があります。 |
| 120 | + |
| 121 | +パッチセットがコンセンサスクリティカルなコードに影響を与える場合、間違いがあればそれはより広いコミュニティにとって非常にコストがかかることになる可能性があることを念頭において、議論およびビューの要件のハードルは高く設定されます。これにはコンセンサスクリティカルコードのリファクタリングを含みます。 |
| 122 | + |
| 123 | +パッチセットがBitcoinのコンセンサスの変更を提案する場合、それはメーリングリストやIRCで広く議論され、広く議論されたBIPと共にメンテナーの判断に基づいて価値のある変更であるという一般的に広く認識される技術的コンセンサスがなければなりません。 |
| 124 | + |
| 125 | +リリースポリシー {#release-policy} |
| 126 | +-------------- |
| 127 | + |
| 128 | +プロジェクトリーダーは各Bitcoin Coreのリリースのリリースマネージャです。 |
0 commit comments