scriptoriumadmin/Roo-Code
1
0
Fork 0
mirror of https://github.com/RooVetGit/Roo-Code.git synced 2026-10-10 03:28:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Roo-Code/locales/ja/CONTRIBUTING.md
Matt Rubens a368c2531d Updated roadmap (#3469)
2025-05-24 13:39:22 -06:00

16 KiB
Raw Blame History

English • Català • Deutsch • Español • Français • हिंदी • Italiano • Nederlands • Русский

日本語 • 한국어 • Polski • Português (BR) • Türkçe • Tiếng Việt • 简体中文 • 繁體中文

Roo Code への貢献

Roo Code はコミュニティ主導のプロジェクトであり、すべての貢献を大切にしています。みんながスムーズかつ効果的に参加できるように、「Issue-First」方式で運営しています。 つまり、すべての作業は Pull Request を出す 前に GitHub Issue に紐付ける必要があります（詳細はPRポリシーを参照）。このガイドをよく読んで、貢献方法を理解してください。 このガイドは、バグ修正、新機能追加、ドキュメント改善など、Roo Code への貢献方法を説明します。

目次

I. 貢献する前に

まず、コミュニティの基準やプロジェクトの方向性を理解しましょう。

1. 行動規範

すべてのコントリビューターは行動規範を守る必要があります。貢献前に必ず読んでください。

2. プロジェクトロードマップの理解

Roo Code には明確な開発ロードマップがあり、優先順位や今後の方向性を示しています。ロードマップを理解することで、以下のことができます：

  • 貢献をプロジェクトの目標に合わせられる
  • 自分のスキルが最も活かせる分野を見つけられる
  • 特定の設計判断の背景を理解できる
  • ビジョンに沿った新機能のアイデアを得られる

私たちはRoo CodeをAI駆動のコーディングツールを構築する開発者にとって最高の選択肢にすることに集中しています。以下がその実現方法です：

信頼性優先

  • diff編集とコマンド実行が常に信頼できることを保証
  • 定期的な使用を妨げる摩擦ポイントの削減
  • すべての言語環境とプラットフォームでのスムーズな動作を保証
  • 様々なAIプロバイダーとモデルへの堅牢なサポートを拡大

ユーザー体験の強化

  • 明確さと直感性のためのUI/UXの合理化
  • 開発者が日常的に使用するツールに求める高い期待に応えるためのワークフローの継続的改善

エージェントパフォーマンスの先導

  • 実際の生産性を測定する包括的な評価基準（evals）の確立
  • 誰もが簡単にこれらの評価を実行して解釈できるようにする
  • 評価スコアの明確な向上を示すRoo Codeの改善を提供

ロードマップの目標を推進する貢献は特に歓迎します。これらの柱に沿った作業をしている場合は、PRの説明でぜひ言及してください。

3. Roo Code コミュニティに参加する

Roo Code コミュニティとつながるのは、始めるのに最適な方法です：

  • メインの方法：
    1. Roo Code Discord コミュニティに参加する。
    2. 参加後、Hannes Rudolph（Discord: hrudolph）にDMを送り、興味を伝えてアドバイスをもらう。
  • 経験者向けの代替案：Issue-First アプローチに慣れている場合は、Kanbanボードを使い、GitHub上でIssueやPull Requestを通じて直接参加できます。

II. 貢献内容の発見と計画

何に取り組むか、どう進めるかを決めましょう。

1. 貢献の種類

さまざまな貢献を歓迎します：

  • バグ修正：既存コードの問題を修正
  • 新機能：新しい機能の追加
  • ドキュメント：ガイドや例の改善、誤字修正

2. 重要な原則: Issue-First アプローチ

すべての貢献は GitHub Issue から始めてください。 これは方向性の統一と無駄な作業を防ぐために重要です。

  • Issue を探す/作成する：
    • 作業を始める前に、GitHub Issues で既存のIssueがあるか確認してください。
    • 既存で未割り当てなら、コメントして担当希望を伝えてください。メンテナーが割り当てます。
    • なければ、Issuesページで適切なテンプレートを使って新規作成：
      • バグは「Bug Report」テンプレート
      • 新機能は「Detailed Feature Proposal」テンプレート。実装前にメンテナー（特に@hannesrudolph）の承認を待ってください。
      • 注：機能のアイデアや初期議論はGitHub Discussionsで始められます。具体化したら「Detailed Feature Proposal」Issueを作成してください。
  • 担当表明と割り当て：
    • 担当したいIssueにはコメントで意思表示してください。
    • メンテナーが正式にGitHubで割り当てるのを待ちましょう。重複作業を防げます。
  • 守らない場合の結果：
    • 関連Issueがない、承認・割り当てされていないPRは、完全なレビューなしでクローズされる場合があります。これはプロジェクトの優先順位を守り、みんなの時間を大切にするためです。

このアプローチで作業の追跡、変更の必要性の確認、効果的な連携ができます。

3. 何に取り組むか決める

  • Good First Issues：GitHubの「Issue [Unassigned]」セクションをチェック
  • ドキュメント：この CONTRIBUTING.md はコード貢献の主なガイドですが、他のドキュメント（ユーザーガイドやAPIドキュメントなど）に貢献したい場合は、Roo Code Docsリポジトリを参照するか、Discordコミュニティで質問してください。
  • 新機能の提案：
    1. 初期アイデア/議論：大まかなアイデアや初期の提案はGitHub Discussionsで始めてください。
    2. 正式な提案：具体的で実装可能な提案はIssuesページの「Detailed Feature Proposal」テンプレートでIssueを作成してください。これはIssue-Firstアプローチの重要な部分です。

4. バグや問題の報告

バグを見つけた場合：

  1. 既存Issueの検索：GitHub Issuesで重複がないか確認
  2. 新規Issueの作成：ユニークな場合はIssuesページの「Bug Report」テンプレートを使う

🔐 セキュリティ脆弱性：脆弱性を発見した場合はGitHubのSecurity Advisory Toolで非公開で報告してください。公開Issueは作成しないでください。

III. 開発と提出のプロセス

以下の手順でコーディングと提出を進めてください。

1. 開発環境のセットアップ

  1. Fork & Clone：
    • GitHubでリポジトリをフォーク
    • 自分のフォークをローカルにクローン：git clone https://github.com/あなたのユーザー名/Roo-Code.git
  2. 依存関係のインストール：npm run install:all
  3. Webview（開発モード）を起動：npm run dev（Vite/ReactアプリのHMR用）
  4. 拡張機能のデバッグ：VS Codeで F5（または Run → Start Debugging）を押して、Roo Codeが読み込まれた新しい Extension Development Host ウィンドウを開く

webview（webview-ui）の変更はHot Module Replacementですぐ反映されます。コア拡張（src）の変更はExtension Development Hostの再起動が必要です。

また、.vsixパッケージをビルド・インストールする場合：

npm run build
code --install-extension bin/roo-cline-<version>.vsix

（<version>はビルドされたファイルの実際のバージョン番号に置き換えてください）

2. コーディングガイドライン

  • フォーカスしたPR：1つの機能/バグ修正ごとに1つのPR
  • コード品質：
    • CIチェック（リント、フォーマット）を通す
    • ESLintの警告やエラーを修正（npm run lint）
    • 自動コードレビューのフィードバックに対応
    • TypeScriptのベストプラクティスを守り、型安全を維持
  • テスト：
    • 新機能にはテストを追加
    • npm testで全テストが通ることを確認
    • 既存テストに影響がある場合は更新
  • コミットメッセージ：
    • 明確で説明的なコミットメッセージを書く
    • 関連Issueを #issue-number（例：Fixes #123）で参照
  • PR提出前のチェックリスト：
    • ブランチを最新のupstream mainにリベース
    • コードがビルドできることを確認（npm run build）
    • すべてのテストが通ることを確認（npm test）
    • デバッグ用コードや console.log を削除

3. コード提出: Pull Request (PR) プロセス

ドラフト Pull Request

まだ完全なレビュー準備ができていない作業にはドラフトPRを使いましょう：

  • 自動チェック（CI）を走らせたい
  • メンテナーや他のコントリビューターから早めにフィードバックが欲しい
  • 作業中であることを示したい

すべてのチェックが通り、「コーディングガイドライン」と「Pull Request の説明」の基準を満たしていると思ったら「Ready for Review」にしてください。

Pull Request の説明

PRの説明は十分に詳細で、Pull Request テンプレートの構成に従ってください。主なポイント：

  • 対応する承認済みGitHub Issueへのリンク
  • 変更内容と目的の明確な説明
  • 変更をテストするための詳細な手順
  • 重大な変更点（breaking changes）のリスト
  • UI変更の場合はビフォーアフターのスクリーンショットや動画
  • PRでユーザードキュメントの更新が必要な場合は、どのドキュメント/セクションか明記

Pull Request (PR) ポリシー

目的

クリーンでフォーカスされた、管理しやすいPRバックログを維持すること。

Issue-First アプローチ
  • 必須：作業開始前に、既存で承認・割り当て済みのGitHub Issue（「Bug Report」または「Detailed Feature Proposal」）が必要
  • 承認：特に大きな変更の場合、メンテナー（特に@hannesrudolph）による事前承認が必要
  • 参照：PRの説明でこれらのIssueを明示的に参照すること
  • 違反時の結果：このプロセスを守らないPRは、完全なレビューなしでクローズされる場合があります
オープンPRの条件
  • マージ準備完了：すべてのCIテストに合格し、（該当する場合）ロードマップに沿い、承認・割り当て済みIssueに紐付けられ、明確なドキュメント/コメントがあり、UI変更にはビフォーアフター画像/動画がある
  • クローズ対象：CIテスト失敗、大きなマージコンフリクト、プロジェクト目標と不一致、長期間（30日超）フィードバック後に更新なし
手順
  1. Issueの確認と割り当て：@hannesrudolph（または他のメンテナー）が新規・既存Issueを確認し、割り当てる
  2. 初期PRトリアージ（毎日）：メンテナーが新規PRを素早くチェックし、緊急・重要なものを振り分け
  3. 詳細なPRレビュー（週次）：メンテナーがPRの準備状況、Issueとの整合性、全体品質を詳細に確認
  4. 詳細なフィードバックと反復：レビューに基づき、Approve/Request Changes/Rejectのフィードバック。コントリビューターは対応・修正
  5. 決定段階：承認されたPRはマージ。不適合や解決不能なPRは理由を明記してクローズ
  6. フォローアップ：クローズされたPRの著者は、問題解決や方向転換後に新たなPRを提出可能
責任
  • Issueの確認とプロセス遵守（@hannesrudolph & メンテナー）：すべての貢献がIssue-Firstアプローチに従うよう確認し、コントリビューターをガイド
  • メンテナー（開発チーム）：PRの初期・詳細レビュー、技術的フィードバック、承認/却下判断、マージ
  • コントリビューター：承認・割り当て済みIssueに紐付け、品質ガイドライン遵守、迅速なフィードバック対応

このポリシーは明確さと効率的な統合を保証します。

IV. 法的事項

貢献契約

Pull Request を提出することで、あなたの貢献が Apache 2.0 ライセンス（またはプロジェクトの現行ライセンス）で提供されることに同意したことになります。プロジェクトと同じです。