手順に近い解決策を維持するには、ガイドまたは手続き型記事のトラブルシューティング セクションを使用します。 サポートおよび製品マネージャーと協力して、一般的なエラーを明確にし、それらをドキュメントに含めます。
既知の問題
既知の問題は、バグ、UX/UI の問題、および大量のサポート チケットを生成するその他の製品の特性に対応するために特別に設計されたトラブルシューティング コンテンツのサブセットです。 トラブルシューティング コンテンツで、ユーザーが直面する ''可能性のある'' エラーを説明できる場合は、既知の問題で、ユーザーが直面 ''する'' 問題について説明します。__ __
すべてのトラブルシューティング コンテンツと同様に、既知の問題は、記事内のセクションまたはスタンドアロンの記事にすることができます。 既知の問題が特定の記事に適用される場合は、その記事で文書化します。 既知の問題が特定の記事のセットまたは機能の概念的なグループ化に適用される場合、あるいは製品または機能にグループ化する必要がある複数の既知の問題がある場合は、専用の「<名前> に関する既知の問題」という記事を作成します。
製品または機能の既知の問題のコンテンツは、包括的である必要はありません。 他のトラブルシューティング コンテンツとは異なり、一部の既知の問題には回避策がない可能性があります。 回避策なしで問題を文書化する目的は、その問題が存在することをユーザーが確認し、GitHub で既に回避策がないと判断された後にまだ存在しない回避策を検索する時間を節約することです。
製品と機能所有者 (PM と EM) は、既知の問題のコンテンツの計画と確認を支援する必要があります。
既知の問題を使用して、次の状況を説明します。
- 通常はユーザーの期待と矛盾するものの、修復のためにまだ優先順位付けされていない製品の動作。
- 通常は一般的な目的で製品または機能の使用を防止する動作。
- GitHub でまだ修正の優先順位が付けられておらず、製品や GitHub Docs の既存のコンテンツで説明されていない、まれなまたは深刻なバグ。
トラブルシューティング コンテンツの記述方法
- GitHub Docs コンテンツの種類を使用して、トラブルシューティング セクションを作成します。
- 可能な限り、手続き型コンテンツまたはガイドに含まれるトラブルシューティング コンテンツを維持します。
- 特定のトピックに大量のトラブルシューティング コンテンツがある場合など、個別に維持することが理にかなっている場合は、トラブルシューティング記事を作成できます。
- 製品または機能に「SSH のトラブルシューティング」などの多くのトラブルシューティング記事がある場合は、トラブルシューティング マップ トピックを作成できます。
トラブルシューティング コンテンツのタイトル ガイドライン
- トラブルシューティング機能
- エラー: エラー名
- 製品の既知の問題
トラブルシューティング コンテンツの例
- 「SSH のトラブルシューティング」
- 「GitHub Enterprise Server でロードバランサを使用する」
- GitHub Enterprise Server リリース ノートの「既知の問題」
- 「Error: We're doing an SSH key audit」