Skip to main content
バグ修正、ドキュメント、翻訳、モデル移植の修正、焦点を絞った機能改善を歓迎します。初めての貢献向け issue、既存の issue と PR を確認し、Discordで範囲を相談できます。
1

問題と範囲を合わせる

小さな修正やドキュメント変更は通常そのまま提出できます。新機能、大きな UI 変更、モデル、プロバイダー、プラットフォーム連携、依存関係、公開 API、スキーマ、構造の変更は、実装前に issue で方向を相談してください。issue、動く実装、方向への合意があっても採用を保証するものではありません。
2

担当するコンポーネントに従う

該当 crate の README とリポジトリ規則を読みます。API やスキーマを変える場合は全利用箇所を更新し、互換エイリアスを追加しません。プロバイダー既定値はその実装に置き、安全な API を unsafe FFI や動的ロードから分離します。モデル移植ではチェックポイントに影響する構造を保ち、同じ入力の構造化出力を比較します。コメントは所有関係、不変条件、上流対応、意図した差異を説明します。
3

変更を確認する

diff 全体を読み、最小限の debug チェックか対象テストを一度実行し、整形して git diff --check を行います。UI にはスクリーンショット、性能変更にはデバイス・入力・基準・結果・正しさ、モデル移植には構造化比較を添えます。実行できなかったチェックも明記します。
4

焦点を絞った PR を作る

問題、解決方法、重要な挙動や所有関係の変化、検証を説明します。無関係なリファクタリングを避け、修正に対応し、不明な指摘は質問してください。
資格情報、モデルの重み、データセット、生成物、ビルド成果物、端末固有ファイルはコミットしません。

​
提案の判断基準

製品の方向性、利用者への価値と広さ、UX、構造、性能、安全性、プライバシー、OS 対応、テスト、ドキュメント、依存関係、運用の複雑さを検討します。 提案の見送り、延期、縮小、再設計、コア外での実装を提案することがあります。マージ後はプロジェクトが保守を担うため、貢献者が参加できなくなっても継続可能である必要があります。

​
AI を使った貢献

人間の貢献者が提出物の著者であり責任者である必要があります。設計や実装への大きな AI 支援は、範囲と目的を開示してください。通常の補完、文法修正、翻訳に詳しい開示は不要です。 提出前に diff 全体を自分で確認し、生成された主張をコードで検証し、報告した問題を再現し、変更と境界ケースを理解して修正できるようにします。他の貢献と同じ検証と証拠が必要です。
自律的・未確認の issue、PR、レビューコメント、セキュリティ報告は提出しないでください。生成出力は下書きとして扱い、説明と応答は自分の理解に基づいて書きます。
未確認に見えるもの、推測や捏造を含むもの、説明や修正ができないもの、価値に比べレビュー負担が大きすぎるものは、詳細レビューなしで閉じる場合があります。不明な場合は相談してください。 続いて開発環境を準備します。