グループオーナーは必ずしもグループメンバーである必要はない

グループオーナーの追加は、現在と同様にほとんど可能ですが、@group add でオーナーを追加する機能が追加されます。

主な利点は、オーナーグループが、おそらく1人か2人のメンバーしかいない独自のオーナーを持つことです。

物事を整理するために、オーナーシップは1レベルのみ可能というチェックを入れると良いかもしれません。

つまり、グループAがグループBを所有し、グループAは両方のグループのメンバーとみなされます。

ここでグループCを追加し、グループBが所有するとします。グループBはグループCのオーナーです。グループAがグループBを所有している場合、グループAはグループCのメンバーとみなされるだけで、所有権の特権はありません。

「いいね!」 1

ダン、明確化してくれて本当にありがとう。グループからグループへの所有権を1レベルに限定することは、保守性と特権の肥大化の回避のために非常に理にかなっています。

以下のアイデアが好きです。

  • グループAグループB を所有 → A のメンバーは B のオーナー権限を取得
  • グループBグループC を所有 → B のメンバーは C のオーナー権限を取得
  • しかし、グループA は C のオーナーではなく、推移的に メンバー(マネージャーではない)になるだけ

これにより、無限のネストを回避しつつ、有用な委任構造をサポートできます。

また、所有権のネストレベルを group_ownership_nesting_level 設定(サブカテゴリのネストのように)で制限することは、サイトに柔軟性をもたらすという点にも同意します。デフォルトは 1 にするかもしれませんが、必要に応じてより深い制御をオプトインできるようにすることも可能です。

いくつか明確化のための質問があります。

  • あなたのモデルでは、所有グループはグループディレクトリUIで所有されるグループの メンバー として表示されるべきですか?それとも、メンバーシップは純粋に権限に基づいていますか?
  • グループに複数のオーナー(一部はユーザー、一部はグループ)がいる場合、UIでの競合や冗長性の解決はどのように考えられますか?
  • 所有権はカテゴリの権限に影響しますか(例:オーナーグループは、所有されるグループに関連付けられたカテゴリを管理できますか)?

これは、教育、組織、またはプロジェクトベースのフォーラムに多くの柔軟性をもたらすでしょう。このアイデアを進めてくれてありがとう!

「いいね!」 2

この場合、グループオーナーグループは、オーナーラベルなどを付けてメンバーとして表示される必要があります。私の意見では、オーナーグループはカテゴリ権限の目的でベースグループメンバーシップを継承する必要があり、公開されている場合はすべてのメンバーを表示する必要があります。カテゴリモデレーターがサイトの「サイトについて」ページにモデレーターとしてリストされているのと似ているかもしれません。おそらく、オーナーグループを「オーナー/管理」としてリストするだけで簡単なかもしれません。そうすれば、メンバーは単にオーナーグループをクリックして、そのグループのオーナーを表示できますか?

私の意見では、グループをオーナーとして使用している場合。それは、グループ内のメンバーオーナーであるか、グループによって管理されているかのどちらかです。両方の混合ではありません。

カテゴリモデレーターのようなものですか?もしそうなら、1つのカテゴリを管理するために複数のグループを許可するように変更されました。ただし、前の質問の例を使用する場合。オーナーグループが管理グループの権限を継承するようにすることもできます。したがって、カテゴリ権限、この場合はカテゴリモデレーターにもなります。カテゴリモデレーターでは、他の例と同様に、より多くの管理レベルが得られます。必要に応じて、スタッフ全体が介入することなく、下位ティアのオーナーを削除できるコアのメインセットのオーナー。つまり、2人のオーナーが競合しています。マネージャーグループのヘッドオーナーは、必要に応じて降格できます。


これは、アイデアを練り上げるための素晴らしい思考実験です。したがって、多くの議論は、アイデアの根本原因を明らかにするのに役立ちます。

「いいね!」 1
Heliosurgeによる所有権の可視性とカテゴリ権限について

それは理にかなっています。カテゴリモデレーターが表示されるのと同様に、「オーナー」または「管理」ラベルが付いたグループディレクトリにオーナーグループが表示されるというアイデアは気に入っています。

次の間の区別が役立つと思います。

  • フルメンバー(バッジ、メンション、グループの装飾を受け取る)
  • 別のグループ経由のオーナー(権限は継承するが、アイデンティティは継承しない)

UIで明確に保つと役立つでしょう。

レイアウト例

グループ @mentors

  • メンバー: Alice, Bob, Charlie
  • オーナーグループ: @mentor-coordinators

オーナーグループをクリックすると、そのメンバーリストに移動します。

そして同意します。カテゴリ権限の目的では、オーナーグループを所有するグループの「メンバー」として扱う(権限を手動で複製する必要を避けるため)のはエレガントです。

フォローアップの質問
  • オーナーグループのメンバーシップは、権限チェックのためだけに継承されますか、それとも、所有グループが公開されている場合、グループのメンションや装飾のようなものにも表示されますか?
  • 1つのグループが複数の他のグループを所有することは可能ですか、それとも安全上の制約として1対1の所有権ルールが必要ですか?


Heliosurgeによる排他的所有権モデルについて

ああ、わかりました。それは便利な簡略化です。

したがって、所有権は排他的であるべきだと提案しているのですね。

  • グループは個々のユーザーによって所有される
  • または、グループによって所有される(その中に所有者が含まれる)
  • ただし、両方を同時に許可しない

これにより、モデルは確実にクリーンに保たれ、UIの競合が回避されます。

ハイブリッドの回避策

ハイブリッドを望む場合は、いつでも所有権グループ(例:「@mentors-owners」)を作成し、個々のオーナーとサブグループの担当者の両方を含め、それを唯一のオーナーグループとして割り当てることができます。これにより、所有権モデルを直接混合することなく、物事を整然と保つことができます。

実装に関する質問
  • この排他性はデータベースレベルで強制されるべきですか(例:グループはgroup_owner_id または user_ownersのリストのいずれかを持つが、両方ではない)?
  • それとも、警告付きのUIレベルの規約ですか?
  • グループが複数のグループによって所有されることは許可されますか(ネストがないと仮定して)?


Heliosurgeによるカテゴリモデレーターの継承とオーナー階層について

それは有益な方向性ですね、ありがとうございます!

カテゴリ権限の継承について

はい。次のような状況を考えていました。

  • グループBはカテゴリ(例:「#mentorship」)への投稿/返信/作成アクセス権を持っています。
  • グループAがグループBを所有しています。
  • そのため、グループAも「#mentorship」へのアクセス権を継承します。カテゴリレベルの権限を明示的に設定する必要はありません。

これにより、所有権構造がすでに信頼境界を表している場合、アクセス管理が簡素化されます。

カテゴリモデレーションについて

Discourseが複数のグループでカテゴリをモデレートできるようになったことは知っておくと便利です。

グループBのオーナーグループも、グループBがモデレートするカテゴリのカテゴリモデレーターステータスを自動的に取得すると想像しますか?

これにより、階層的な制御モデルを実装するのに役立ちます。オーナーグループは「ヘッドモデレーター」または「グループスチュワード」として機能し、次のようなことができます。

  • 同じスペース全体でモデレーションを行う
  • 問題のあるグループレベルのオーナーまたはサブマネージャーを降格させる
フォローアップの質問
  • 継承された権限は、カテゴリへのアクセス/モデレーションにのみ適用されますか?それとも、他のグループリンク機能(例:メッセージング、イベント)にもカスケードしますか?
  • あなたの階層モデルでは、「トップ」グループは常にフラットであるべきですか?それとも、それ自体にオーナーを持つことができますか?

これは、学校、組織、構造化されたオンラインコミュニティに役立つ、非常に柔軟な委任モデルを構築しているように感じます。