当社では、社内でのトピックに関するコミュニケーションにウィスパーを広く活用しています。
当社の組織のほぼすべての役割（営業、サービス、開発者、PM、コミュニティ管理、UX、ドキュメント）は、ユーザーコミュニティにおいて役割を担っています。これは、すべての従業員がウィスパーを見ることができる必要があることを意味します。
Discourseでは、ウィスパーを見るにはスタッフグループのメンバーである必要があります。これは、300人以上にモデレーターアクセスを付与する必要があることを意味します。これらのユーザーは、そうでなければTL4で問題なく対応できるはずです。
TLDR：すべての従業員がウィスパーを見る必要があり、モデレーターを必要とするのはごく少数です。
以下のような機能があれば非常に役立ちます。
どう思われますか？
確かに非常に興味深い問題であり、その点については非常に共感しており、この権限はグループベースであるべきだと同意します。
残念ながら、これは内部設計の多くの部分に影響を与える大きな変更です。
一見すると簡単な変更のように思えるかもしれません…これらの2つのメソッドを書き直すだけです：
しかし、Discourseにおける変更の内部はかなり深くまで及んでいます。
ウィスパーを含む最高の投稿番号を追跡するこの列さえありますが、それは highest_staff_post_number と呼ばれています。
ここでのもう一つの複雑さは、ユーザーがウィスパーを確認できるかどうかを判断するためにグループチェックが必要になることであり、現在はユーザーレコードに単純にアクセスするため、チェックがより安価になっています。
これを内部議論のためにブックマークしておき、何かできることがあるか確認しますが、残念ながら複雑さはかなり高いです。
別のアプローチとして、新しいレベルのスタッフメンバーシップを作成するのはどうでしょうか？
管理者 > モデレーター > チーム
彼らは「スタッフ」として資格を得ることができますが、「概要」ページには表示されません。
コミュニティでのほとんどのアクティビティをフォローしていない他の従業員を会話にタグ付けする機能があれば便利だと感じたことが何度かあります（例：関連フィードバックのために製品チームにエスカレーションする）が、他の特権のためにモデレーターにしたくはありませんでした。
おっしゃることは理解できますが、私たちの一般的なパターンは、ハイパーフレキシブルなグループベースの権限に移行することです。すでに「割り当て」と「解決済み」で実施しており、今後さらに多くの部分に拡大していく予定です。
私が考えた回避策は、トピック機能でチャットを使用し、そのチャンネルへのアクセスをスタッフとあなたのチームグループのみに制限して、実際のささやき機能の代わりにそれを使用することです。
@Colin_Mueller 変更はサイトで公開されるはずです 
ご提案ありがとうございます。これは確かに多くの人が望んでいたことです。ここには少し繰り返しパターンがあります。TLまたはStaffをゲートとして使用すると、グループベースの権限を許可するよりも柔軟性がはるかに低くなる傾向があります。
@サムさん
すごい！それは本当に素晴らしいです。これは私たちにとって非常に役立ちます。本当にありがとうございます。
このトピックは14日後に自動的に閉じられました。返信はもう許可されていません。
