機能のリクエスト

機能と機能強化のリクエストは、監視、投票、およびレポートのためにFiderインスタンスに送信する必要があることに注意してください。すべての機能リクエストはGitHubではなく、このページに保管してください。

排出ガイドライン

このページでは、Jellyfinプロジェクトのポリシーやテーマの処理に関する手順など、テーマを開く方法について説明します。

問題は ただ 詳細なソフトウェアバグレポート。

最初のトラブルシューティングを含む他のすべてのディスカッションは、ヘルプチャネルに転送する必要があります。

検索して投票する

番号を開く前に、既存の番号を検索して、同様の機能の問題またはリクエストが報告されているかどうかを確認してください。重複した問題は、預金を台無しにするので避けてください。

あなたの問題に一致する、または近づく問題を見つけた場合は、フィードバックを使用して、その問題があなたにも影響を与えていること、または機能リクエストをサポートしていることを確認してください。必要に応じて、問題のバージョンや機能の使用例を説明するコメントも追加します。

既存のトピックが閉じている場合は、それを読んで、承認された解決策が当てはまるかどうかを確認してください。そうでない場合は、コメントを残してください。トピックが再開されます。広報は最初に開発されますが、リリースはマスターから構築されるため、問題の解決策は公式ソースからすぐに利用できるわけではなく、次のリリースに含まれることに注意してください。

番号を開く

番号を開く準備ができたら、このページをご覧ください。

バグの報告

問題を書くときは、できるだけ関連性の高い詳細をキャプチャしてください。これは、問題のトラブルシューティングと追跡/調査を行う上で非常に重要です。いくつかの便利な要素は次のとおりです。

• Jellyfinをインストールした方法（アップグレード/新規インストール）
• 使用しているプラットフォームとオペレーティングシステム（Debian、Arch、Dockerなど）
• 問題が発生する原因となった操作
• 関連するログ出力
• 使用する非標準構成

バグには、タイトルの最初に[バグ]のタグを付ける必要があります。これは後でJellyfinチームがタグを割り当てることで削除されます。トリアージを支援するために、問題に適用する必要がある他のタグがわかっている場合は、[バグ]タグの後に追加してください。

バグは再現可能でなければなりません。つまり、トラブルシューティングを通じて問題を再現する方法を決定できるはずです。 1回限りのバグは無視すべきではありませんが、再現が困難または不可能な場合は、修正が非常に困難になる可能性があります。問題を提示する前にエラーを再現し、それを実証するためにできる限り小さなテストケースを含めてください。

問題の解決やトピックを開くのにサポートが必要な場合は、コミュニティに連絡してください。サポートを提供します！

排出ラベル

Jellyfinは、問題切り分けと問題管理に役立つ一連の問題ラベルを備えています。 GitHubの権限により、ユーザーは自分自身を割り当てることはできませんが、トリアージ中にチームメンバーによって追加されます。

カテゴリー

これらのタグは、コードベースの一部が影響を受ける広範なカテゴリです。

• ...後ろから：主にサーバーのバックエンドコードに関連する問題。
• ビルド：主に建設プロセスに関連する問題。

批判

これらのラベルは、問題の重大度を判断するのに役立ちます。

• リグレッション：前回のビルドからのリグレッションのため、早急な対応が必要な問題。
• ...バグ：通常の使用に影響するコードのバグ。

経営

これらのラベルは、プロジェクトと方向の管理に役立ちます。

• 良い最初の問題：非常に簡単で、開始するのに最適な場所。
• ヘルプ募集：プロジェクト内に明確な専門家がいないため、外部のヘルプを使用できる問題。
• ロードマップ：プロジェクトの将来のロードマップに関連するメタテーマ。
• 調査：コードに基づく調査タイプの問題。

抽出依頼

これらのラベルは、管理目的のプルリクエストにのみ適用されます。

• テストが必要：実稼働環境でまだテストされていないPR。基金に影響を与えるPRは、リグレッションを回避するためにマージされる前にテストする必要があります。