こんにちは。
ささやきへの特定のグループアクセスを許可できるようになり、ほとんどの社内ユーザーのモデレーターアクセスを削除できる状態に非常に近づきました。
そして、アクセスを削除し始めたとき、最後の1つのピースが欠けていることに気づき、変更を元に戻さなければなりませんでした。私たちは組織内で割り当て（ユーザーおよびグループへの）を多用しています。
これらすべては、コミュニティのユーザーからは「隠されています」。これは私たちにとって非常にうまくいっています。なぜなら、私たちは時々、グループにスレッドを割り当てるからです…
- フィードバックを渡しているだけ（参考情報）
- アクションが必要
- アクションが必要かどうか不明（グループが確認して判断する）
社内ユーザーは、組織内の他のグループにスレッドを割り当てることができると信頼されています。
モデレーターアクセスを削除し始めたときに気づいたのは、グループの可視性とグループへの割り当て能力は、「グループメンバー、モデレーター、および管理者のみ」までしか開くことができず、それ以上開くと、社外ユーザーにグループの表示と割り当てを許可しなければならなくなるということです。
これらの権限をグループレベルで定義できると素晴らしいでしょう。私たちにとって、これは最後の欠けているピースです。
私たちの推進力:
そもそもなぜこの取り組みを行っているのかを言及することが重要だと思います。
私たちのインスタンスには約170人のモデレーターがいます。これらのユーザーは、ユーザーのメールアドレスやIPアドレスにアクセスする必要はありません。特に組織が成長し続けるにつれて、この情報が誰にでも利用可能であることはリスクが高いと感じています。
「いいね！」 3
メインの機能リクエストとは別に、管理設定の「モデレーターはメールを表示する」は、この問題に役立ちますか？
「いいね！」 4
正直なところ、そのオプションが存在することに気づきませんでした。実際、私たちのインスタンスではオフになっています！インスタンスの別のモデレーターになりすましたところ、確かに彼らは電子メールアドレスを表示できませんでした。
「単なる」モデレーター（管理者ではない）だった頃は、電子メールにアクセスできたと誓います。当時、設定が異なっていたのかもしれません（私たちのインスタンスは過去8か月でかなりの変遷を遂げてきました）。
それを指摘してくれて本当にありがとう。
そうなると、緊急性はいくらかなくなります。そして一般的に、私はプラットフォームが、これらのより厳格なオプションではなく、柔軟なグループベースの権限に向かって進化し続けることを望んでいます。
「いいね！」 3
sam
(Sam Saffron)
4
すみません、もう少し詳しく説明していただけますか？
Discourseでも同様の問題に取り組んでおり、実際、開発インスタンスでは管理者/モデレーターアクセス権がありません。管理者/モデレーターの数を少なく保つことの大きな利点については、完全に理解しています。
問題を具体的に説明していただけますか？
考慮すべきいくつかの構成要素があります。
- カテゴリモデレーション：特定のカテゴリに対するモデレーションを特定のグループに定義できます。これにより、信頼度の高いユーザーはより柔軟に対応できます。
- 信頼レベルシステム：TL4（手動）では多くの機能がアンロックされます。
assign allowed on groups サイト設定（特定のグループへの割り当てをアンロックします）
承知いたしました。詳しく説明します。
当社には、製品の担当部分に関するSME（Subject Matter Expert）としてコミュニティに貢献するさまざまなチームがあります。各チームごとにグループが作成され、トピックについてチームの専門知識が必要な場合、そのトピックはチームに割り当てられます（通常は個人に割り当てられ、その個人は貢献を終えたら自分から解除します）。
この仕組みがどのように機能しているかをユーザーに明らかにすることは望んでいません。期待値を低く保つように努めています（オープンソースユーザーに提供している無料サポートなので）、ユーザーが「なぜこのトピックをすぐに_____チームに割り当てられないのですか？」と尋ね始めることは望んでいません。実際、これらのグループの存在をユーザーに知られたくありません。
通常、私は徹底的な透明性を支持しますが、この方法は私たちにとって非常にうまく機能しています。
そして、内部ユーザーがこれらのグループすべて、それらに割り当てられたトピックを確認し、他のグループに再割り当てできるようにしたいと考えています。
しかし、グループレベルのインタラクション権限：
- このグループは誰が見ることができますか？
- このグループのメンバーは誰が見ることができますか？
- このグループを@mentionできるのは誰ですか？
- このグループにメッセージを送信できるのは誰ですか？
- このグループに割り当てることができるのは誰ですか？
は、次の権限に限定されています。
これは、すべての内部ユーザーが必要な方法でグループを表示/操作できるようにしたい場合、少なくともモデレーターアクセスを付与する必要があることを意味します。これは理想的ではありません。
これで問題が明確になったことを願っています。さらに明確にできることがあればお知らせください。
「いいね！」 1
sam
(Sam Saffron)
6
なるほど、これは確かに困りましたね。このドロップダウンを以下のように変更することに100%同意します。
以下のように変更します。
Xを許可されるグループはどれですか？
[my-group/owners group1 group2 etc... ]
実際、これによりUIと内部実装が単純化され、列挙型などを考慮する必要がなくなります。
ポートで最も難しいのは、「グループオーナー」が実際のグループではないため、その意味を説明するための新しいプリミティブが必要になることです。グループIDだけでは不十分です。
「いいね！」 3
正直なところ、グループオーナーがグループオーナーであるという理由だけで、すべてのことを許可されないという実際のユースケースを思いつくのは難しいです。
その場合、その問題を無視して、グループオーナーに管理者権限を付与することもできるかもしれません。残りの権限は個々のグループに委任されます。
「いいね！」 2
sam
(Sam Saffron)
9
お気持ちはわかりますが、破壊的な変更を加えることについては非常に心配しています。単純な「グループオーナー」シャドウグループをサポートすることで、既存の機能ユーザーに何も影響を与えることなく、新しいUIに完全に移行できます。
「いいね！」 2
