**ジェリーフィン LLM / AI 開発ポリシー**

Japanese Translation:

Jellyfin の貢献ガイドラインは、プルリクエストにおける大規模言語モデル（LLM）の出力の使用を厳格に制限しています。

LLM テキストの逐語的コピーは禁止 – LLM から直接コピーしたテキストは、イシュー、コメント、PR 本文、およびフォーラム投稿で禁止されています。

翻訳の場合は明示的なラベル付けが必要 – LLM が翻訳を支援した場合、その作業には必ずその旨をラベル付けし、できるだけ元の言語で公開してください。

LLM 生成コードはクリーンアップと説明が必須 – 貢献者はすべての変更点をレビュー・クリーンアップ・説明する責任があります。「ピュア・バイブコーディング」は許可されません。

簡潔で焦点の絞られた PR が推奨 – 各 PR は単一の機能またはバグ修正を含むべきです。関連性のない変更は拒否対象になります。大規模な PR は小さなコミットに分割すべきで、レビュアーはスクワッシュできますが、作業がレビュー可能であることを保つ必要があります。

コード品質ルール – 過剰なコメント、スパゲッティコード、空行、エディタ生成のメタファイル（.claude 設定など）は許可されません。

テスト要件 – すべての変更はコンパイル・実行が正しく行われ、機能テストでカバーされる必要があります。テスト不足は拒否理由になります。

理解しやすい貢献 – 貢献者は自分の変更を十分に理解しており、レビュー時に LLM テキストに頼らず議論できなければなりません。

LLM 生成プロジェクトのラベル付け – プロジェクトが主に LLM によって生成された場合、その旨をコミュニティ内で共有する際に明確にラベル付けしなければなりません。

ライセンスと帰属の遵守 – すべての作業はライセンスを尊重し、貢献者への完全なクレジットを行い、コード盗用や Git 履歴の改ざんを避ける必要があります。違反は拒否またはバンの対象となります。

モデレーションの焦点 – レビュアーは明確なルール違反にのみ対応し、LLM 使用自体を標的にはしません。

最終判断 – PR が複雑さ・サイズ・不明瞭さにより合理的にレビューできない場合、拒否され、より焦点の絞られた提出物へ分割する必要があります。

この改訂版要約は、元リストからすべての重要ポイントを明示的に扱いながら、明確性を保ち不要な推測を避けるよう設計されています。

Jellyfin LLM／「AI」開発ポリシー

過去一年ほどで、LLM（大型言語モデル）が開発ツールとして大きく進化しました。Claude CodeやChatGPTなどのツールは、経験豊富なエンジニアだけでなく新人にも強力な機能を提供しています。しかし、それにはトレードオフがあります。

Jellyfin のコア価値観は初日から「コード品質」—可読性・単純さ・簡潔さ—にありました。これは専任チームが手作業で行う大きな努力で、脆弱でスパゲッティのような過剰設計されたレガシーコードを堅牢で保守しやすいソリューションへと置き換える必要性に駆り立てられています。

Jellyfin エコシステム（サーバーおよびクライアント）内で AI を利用する貢献者が増加している一方、LLM に対する批判や懸念も高まっています。このポリシーは、LLM を含む可能性のある貢献・交流に対し私たちが期待し望む姿勢を明確化します。規則はすべて公式プロジェクトとコミュニティスペースに適用されます。

一般ガイドライン

LLM の出力は、直接のコミュニケーション（Issue・コメント・機能リクエスト・PR 本文・フォーラム／チャット等）でそのまま使用することを厳禁 とします。
要するに、上記のいずれかを投稿する場合は、内容が自分自身の言葉（説明・記述など）である必要があります。LLM の出力を逐語的にコピーしたものは許容されません。違反すると対象アイテムの閉鎖／削除処理が行われます。
例外：翻訳作業に LLM を利用することは許可されています。ただし、意図を英語で正確に表現できない場合のみです。その際は「LLM で MyLanguage から翻訳しました」と明示し、可能なら元の言語でも投稿してください。
LLM コード貢献 は以下の追加規則が適用されます。基本原則として「純粋に LLM に任せたコード」は却下され、コミットする内容について自ら責任を持つ必要があります。質の悪いコードは拒否対象です。

公式プロジェクトへの LLM コード貢献

LLM をコードに使用することは論争的で解釈の余地が大きいため、知識豊富な開発者が責任を持って利用できるようにしつつ、低品質な寄稿の洪水を防止するためのガイドラインです。

範囲と焦点

貢献は簡潔で焦点を絞ったものにしてください。
PR が X を対象としていると主張しても、関連しない Y や Z に触れている場合は却下されます。これは不適切なプロンプトや過度に一般的な指示による副次的変更を防止するためです。
大規模 PR はレビューと履歴管理の観点から、複数の小さく管理しやすいコミットへ分割してください。

フォーマッティングと品質

不要なコメント、スパゲッティコード、空行に残るスペース等は「純粋な LLM 出力」とみなされ却下対象です。提出前にきれいに整えてください。
```
.claude
```
などの LLM メタファイルやエディタ生成の非コードファイルをコミットしないでください。

説明とレビュー

PR 本文（および該当する場合はコミットメッセージ）で、LLM を使わずに「何が変更されているか」「なぜそれが必要なのか」を説明できる状態にしてください。
他の開発者が理解しやすいコンテキストを提供することが求められます。
LLM が行ったことを説明できない場合、私たちはその変更に関心を持ちません。

テスト

変更は必ずテストされるべきです。コードはビルド・実行可能である必要があります。そうでなければ却下されます。
実際に修正対象の機能が動作するかどうかを明示的に確認してください。

フィードバック対応

レビューコメントに対して変更や説明を行う意思があることが必要です。
何が変わったか、なぜそれが重要なのか理解できない場合は、私たちはその変更を受け入れません。
機能追加やリファクタリングは、変更内容と理由について深い理解が求められます。開発者の所有感が薄い PR は却下されます。

判断権

最終判断はレビュアーに委ねられます。PR が複雑すぎる・大きすぎる・圧縮し過ぎて合理的にレビューできない場合、LLM か非 LLm の区別なく却下されます。
必要に応じて、1 つの PR を複数に分割し、それぞれが焦点を絞った変更セットであることを求められることがあります。

ゴールデンルール：曖昧なプロンプトで LLM にコードベース全体を任せ、結果をそのままコミットしないでください。これは怠慢な開発であり、私たちの視点からは常に低品質な貢献につながります。努力を払うか、もしくは取り掛からない方がよいです。LLM を援助として利用することは許容されますが、コード変更の唯一の源としないでください。

非公式プロジェクト

主に LLM で開発されたプロジェクトは明確にその旨を表示してください。
サポート的に使用した場合（例：ドキュメント作成・フォーマット調整）はそれを開示してください。
ライセンスを尊重し、既存の貢献者へのクレジットを完全に行いましょう。Git 履歴を改ざんしたり、第三者の変更を自分のものとしてコミットしたりしないでください。違反すると拒否・当組織およびコミュニティからのバン対象となります。

コミュニティ行動

LLM が生成したツールやクライアント等を単独で評価して報告しないでください。
anti‑LLM の「ウィッチハント」を避けてください。ツールを支持するか否定するかは完全にあなたの判断です。
モデレーターは第三者プロジェクトを細かくチェックする「LLM 警備員」にはなりません。ルール #1 は著作者側の責任であり、ルール #3 はその文脈で解釈されるべきです。ツールが LLM 生成でルール #1 に違反しているように見える場合は、明白な違反がない限り投票を控えたり無視したりしてください。ルール #2 は LLM の使用有無に関わらず常に適用されます。

ポリシー終了