We are introducing hierarchical groups as part of Dgroups 2.0 to help structure relationships among groups that sometime exist. Sometimes one communicates on a topic that has both general and specific components that are naturally organized in a hierarchical relationship.
Our migration team is using this hierarchy to simplify communication. Our top-level group, ‘Migration to D2’ deals with general communication around migration. This group also serves as the entry point for all people we’re involving in the work around the migration process. Yet, we have some specialized topics, like data analysis, observations on the behavior of the new platforms, meeting coordination, and similar. For these specific topics that include only a subset of people involved, it makes sense to treat them separately. This is where the hierarchy comes in: we dedicated a sub-group for each of the specialized topics.
The interesting part is how the platform deals with hierarchy membership: all members of the sub-groups are always members of their parent groups, all the way to the top. If we invite someone to a sub-group, that someone is automatically a member of the parent groups (but not the sibling groups). Membership always propagates upwards.
Conversely, an administrator of a group is automatically administrator of all sub-groups. Of course, one can assign a new administrator of a subgroup, who in turn can administer all sub-groups of that group, but is only a member of all parents. 🙂 Quite a mouthful to say, yet simplifies user management greatly.
There is no limit how many levels of sub-groups one wants to create, except maybe in practicality of writing an URL that is 1000+ characters long. Each group still gets its own mailing list and a document library, and outside of the URL and membership rules, it behaves like a top-level group.