ナレッジベースのワークフローの進化に伴い、コンテンツリクエストをコミュニティ貢献者に割り当てることができる場合の境界線をより明確にしたいと考えています。

私たちはあなたの専門知識を深く評価しています。コミュニティ内での長年にわたる製品知識は非常に貴重です。同時に、製品リリースや部門横断的なコラボレーションに関連するコンテンツ作業には、明確な所有権、予測可能なタイムライン、構造化された調整が必要です。これにより、Mozilla のグローバルなユーザーベースをサポートするための正確で役立つコンテンツをタイムリーに提供できるようになります。

これらのガードレールは、以下の目的で設計されています:

• リリースのタイムラインを守る
• 所有権と説明責任を明確にする
• 健全なコラボレーションを維持する
• 不明確な期待によって生じる摩擦を避ける

これらの変更は、スタッフと貢献者の間に持続可能なコラボレーションを築くためのものです。

作業を始める前に

作業を進める前に、マイナーアップデートとメジャーアップデートでは異なるワークフローに従うことに注意してください。

各カテゴリーに該当するものを理解するために マイナーな変更とメジャーな変更 を確認し、マイナーアップデートを直接提出するためのガイダンスとして ナレッジベースの記事を編集する を参照してください。

これらのガードレールは、新規コンテンツリクエストまたはメジャーアップデート にのみ適用され、ナレッジベースに直接提出されたマイナーリビジョンには影響しません。

新規コンテンツリクエストとメジャーアップデートのコンテンツプロセス

以下のプロセスは、Bugzilla を通じて提出された新規コンテンツリクエストおよびメジャーアップデートに適用されます。

• ステップ 1: 提出

すべてのメジャーコンテンツアップデートは、Bugzilla のチケットを通じて提出する必要があります。

• ステップ 2: トリアージと割り当て
  • トリアージ: すべての新規コンテンツリクエストは、優先順位と割り当てを決定するためのトリアージプロセスを経ます。リクエストが以下のセクションで概説されている割り当て基準に合致する場合、貢献者の参加が奨励されます。関心を示すには、Bugzilla のチケットに直接コメントしてください。
  • 割り当て: CX チームは、製品の所有権に関わらず、コンテンツリクエストプロセス全体に責任を持ち、バグを貢献者またはテクニカルライターのいずれかに割り当てます。CX スタッフメンバーが割り当てを確認するまで、下書きを開始しないでください。割り当てられると、コミュニティマネージャーまたは別の CX チームメンバーがプロセスを案内します。
  • 期間の目安: トリアージは週次で行われ、貢献者は最初のリクエストから 5 営業日以内に返信を期待できます。
• ステップ 3: コンテンツ作成
  • コンテンツの下書き: チケットを注意深く確認し、リクエスト、範囲、期待される成果を完全に理解してください。製品チームから下書きが提供されている場合は、それをたたき台として使用してください。そうでない場合は、Google ドキュメントでコンテンツの下書きを開始できます。Google ドキュメントが利用できない場合は、下書きをレビューのために Bugzilla のチケットに直接添付してもかまいません。下書きへのリンクを Bugzilla のチケットに投稿し、関係者がコメントできるようにドキュメントの権限を設定してください。
  • コンテンツの承認: 記事が完全かつ正確であることを確認するために、リクエスト者または製品の関係者と緊密に連携してください。作業を完了するために必要な情報が不足している場合は、Bugzilla の「Request information from…」オプションを使用して追加の詳細を収集してください。
  • エスカレーション:
    • リクエスト者から必要な情報を得られない場合は、CX プロダクトサポートマネージャーまたはコミュニティマネージャーにサポートを依頼してください (誰に連絡すべきかの参考として こちらの記事 を確認してください)。
    • リクエスト者が期待する締め切りに間に合わない場合は、Bugzilla のチケットを更新するか、CX スタッフメンバーに直接連絡して、できるだけ早く CX チームに通知してください。
• ステップ 4: コンテンツの公開
  • コンテンツの公開: 下書きが完成し、関係者によって承認されたら、実際のナレッジベース記事の新しいリビジョンとしてコンテンツを提出できます。私たちの KB はカスタム Wiki 構文を使用しているため、Google ドキュメントからコンテンツをコピーする場合は、コンテンツが正しくフォーマットされていることを確認してください。
  • コンテンツのレビュー: 貢献者は、品質保証とマークアップの適切性のために、スタッフメンバーまたは (著者以外の) KB レビュアーによる KB レビューを待つ必要があります。
  • チケットのクローズ: KB 記事が公開されたら、Bugzilla のチケットを Resolved — Fixed としてマークしてクローズできます。

コンテンツの承認とコンテンツのレビュー

コンテンツの承認 の主な目的は、製品の関係者とともにコンテンツの実質と意図を検証することです。これには、コンテンツの下書きが以下のようになっていることを確認することが含まれます:

• 技術的に正確で、意図された製品の動作を反映している
• 承認された製品の用語と命名規則に沿っている
• Mozilla のブランドボイスとメッセージングと一致している

コンテンツのレビュー は、記事の品質と表現に焦点を当てることで承認を補完します。これには以下が含まれます:

• 正しい構文とフォーマットの確認 (Wiki マークアップ を含む)
• 明瞭さ、読みやすさ、構造の改善
• 編集および コンテンツガイドライン との整合性の検証

コンテンツの承認とレビューを合わせることで、記事が公開前に正確かつユーザーフレンドリーであることが保証されます。

貢献者向けの追加ガイドライン

• 割り当ての公平性

製品チームと直接関係のある貢献者は、正式に提出される前に今後のリクエストを把握している場合があります。しかし、コンテンツリクエストが作成され、トリアージされる前に作業を開始したり、割り当てをリクエストしたりしないでください。これにより、すべての貢献者に対して貢献の機会がオープンかつ公平に保たれます。

• トリアージプロセスの尊重

CX チームが Bugzilla のチケットをレビューし、割り当てるために、5 営業日のトリアージ期間を設けてください。この期間が経過する前に、割り当ての決定をリクエストしたり、圧力をかけたりすることは避けてください。

• 対応可能状況の変更を伝える

予期せぬ状況が発生することは理解しています。約束した締め切りに間に合わない場合は、CX チームができるだけ早く調整できるよう、速やかに通知してください。

• Bugzilla チケットの再オープンに関するポリシー

元のリクエストに直接関係のないリビジョンのレビューをリクエストするために、解決済みの Bugzilla コンテンツリクエストチケットを再オープンしないでください。 関連する更新については、チケットを再オープンする代わりに、既存のチケットに新しいコメントを追加してください。 コメントする権限がない場合は、リクエストを kb-reviewers メーリングリスト (下記参照) にエスカレーションしてください。

この基準を満たさずにチケットを再オープンすると、リクエストが却下される場合があります。生産的で敬意のあるコラボレーションを維持するために、Bugzilla Etiquette に従ってください。

• レビューの迅速化リクエスト

緊急の製品変更、進行中のインシデント、または重大な不正確さなど、リビジョンがより迅速な対応を必要とする場合は、kb-reviewers@mozilla.com にメールでレビューの迅速化をリクエストできます。

どこで新規コンテンツリクエストを探すか？

貢献者は、機密情報を含まないコンテンツリクエストへの参加が奨励されます。新規コンテンツリクエストを探す方法は次のとおりです:

• 手動でのモニタリング

まだ割り当てられていない新規リクエストを こちら で確認し、新しいコンテンツリクエストのバグに注意してください。興味のあるものを見つけたら、バグに直接コメントして、リクエストを手伝いたい旨を CX チームに通知してください。

• 最新情報を入手する

新しいコンテンツリクエストに関する通知を受け取りたい場合は、Bugzilla で Knowledge Base Content コンポーネントをウォッチすることを検討してください。これを行うには、Bugzilla のプロフィール → Edit Profile & Preferences → Component Watching に移動します。製品選択で support.mozilla.org を選択し、Component フィールドで Knowledge Base Content を選択します。そして、変更を保存するために Add ボタンをクリックすることを忘れないでください。

割り当て基準

コンテンツリクエストは、以下の条件を満たす場合に貢献者に割り当てられることがあります:

• 機密情報を含まない

公開禁止情報や機密性の高いコンテンツ を含むコンテンツリクエストは、引き続きスタッフが所有します。

• 緊密な内部依存関係を伴わない

メッセージングの機密性、コンプライアンスレビュー、または進化する仕様 を含み、法務、マーケティングおよびコミュニケーション、セキュリティ、および外部パートナーとの積極的な調整を必要とするリクエストも、引き続きスタッフメンバーが担当します。

• 有料製品に関連しない

サブスクリプション製品および有料機能 に関連するコンテンツリクエストは、法務、コンプライアンス、テスト、および部門横断的な調整の要件により、スタッフが所有する必要があります。これらのリクエストは、契約、請求、またはリリースに関する機密情報を含むことが多く、一元的な説明責任が必要です。

• 時間的制約が厳しくない

納期が 5 日未満 のコンテンツリクエストは、タイムリーな提供とリリーススケジュールとの整合性を確保するため、スタッフが担当します。

• 貢献者のキャパシティ

貢献者は、一度に最大 3 つのアクティブな割り当て に制限されます。これにより、集中的な実行が確保され、作業負荷の不均衡が防止されます。技術的な依存関係により、一部のリクエストが遅延する場合があることを認識しています。リクエストが製品側の依存関係で 2 週間 以上ブロックされたままである場合、そのチケットは非アクティブ (stale) と見なされ、貢献者の作業負荷の期待から除外されることがあります。

追加の明確化:

• これは Bugzilla 経由のリクエストにのみ適用され、マイナーな KB リビジョンには適用されません。
• これは フォーラムのよくある返信 の作成には適用されません。
• スタッフは、公開されたコンテンツに対する最終的な説明責任を保持します。