@gregorycassel 'Hide' or 'Archive' is a suitable non-aggressive solution. That would work for our group. Thanks for raising that idea.

I think there are plenty of times when you want a parent group coordinator to not have any rights on a subgroup.

I wonder if what we actually want here is a new role, like 'organisation coordinator' (where organisation = parent group + all its subgroups).

@richarddbartlett suggestion is interesting but how to organise a organisation coordinator. Could the coordinator have some rights to delete a subgroup dependant upon a majority vote from the parent group?

What problem are we trying to solve by hiding or removing a sub-group?

Ok I'm hearing that the solution proposed doesn't quite cover it, but there seems to be a need for some kind of new set of permissions or role here.

I also think that thinking of "organisation" as the highest level owner of some set of groups is the right place to start solving these problems.

Over only skimmed this thread, but to me it is completely obvious that parent group admins ought to have the technical power to delete (and hide or archive if they prefer) sub-groups.

(just as it was completely obvious that one should be able to edit ones comments ;) ).

@richarddbartlett re your comment:

"I think there are plenty of times when you want a parent group coordinator to not have any rights on a subgroup. "

Such as? Could you give a few example of when that might apply. And in such cases, wouldn't it perhaps make more sense for the sub-group just start their own group as opposed creating a sub-group in the first place?

And, ultimately, whoever manages the server the software is running on has complete ultimate power over everything anyway, no?

@josefdaviescoates here's one real world example.

I tend to think that subgroups should always be adminable by the parent - it's super common and simple to understand. It makes it easy to move to the concept of "organisation with subgroups"

I wonder if there should be some other kind of relationship available for the usecase you've just posted @richarddbartlett. Like a "community" of autonomous groups with shared purpose... you wouldn't "join" the community as a user, but the group itself could become affiliated with one or more communities.

The discussion reminds me about my answer for the question "where are u from?" FROM MY MOTHER!
By choosing the term "parent"-group it means the parent group coordinators should be the one who create and manage subgroups to keep the overview about the group work flow and its efficiency. Otherwise it will end having many groups with similar contents don't know about each other.
I don't mind if some parents want to have it fully chaos. But for those who like to have the communication bit more organized should have the option in group settings to allow other members to create subgroups without being coordinators or not.

The ability of the parent to tell the child to leave when the child no longer plays by the house rules.

What about the proposal to change the term parent group into main group until we have new solution ?

@waelalsaad , the term 'parent group' is just an informal habit of discussion here, isn't it? Am I correct in thinking that the only technical terms are 'group' and 'sub-group'?

Group and sub-group are simple clear terms to indicate hierarchy. I think those terms are very appropriate for organizations in which the sub-groups (or committees, etc.) really are subordinate to the central group.

I greatly prefer a system which, basically, allows for federation and/or confederation models of organization. I will comment on this in some detail below.

I love a system which essentially allows group coordinators to choose between a federation and confederation model of organization. Better yet, it’s great to enable both modes of subgroup relationship to the same central group. This seems to be close to what Loomio already offers.

To be clear, I’m defining federation as an organization in which member entities are subject to central authority in some, but not all, ways. By contrast, the members of a confederation tend to be almost or entirely autonomous. They participate in the confederation as an ongoing act of free choice. (Of course, the use of those terms has been mixed up in actual politics.)

I see two current problems, despite Loomio’s great flexibility in group/subgroup relationships:

(1) Loomio group coordinators can only allow all members to create any type of subgroup, or no type of subgroup at all.

(2) Loomio group coordinators have no admin controls for any type of subgroup.

I think it is this combination of problems which creates the dilemma in our topic here. For instance: One group coordinator allows (all) members create any type of subgroup they want. So, someone creates the type of subgroup which is listed on the group’s page, and then that member disappears forever, leaving an unwanted group.

@richarddbartlett , I’m guessing you’re well aware of the combination of problems here. @alanna , I'll tag you too since I know you were concerned about these matters, with your creation of the poll here.

So, here’s what would seem ideal to me, in a world where software magically writes itself (haha):

(1) Group coordinators would be able to separately determine the ability of members to create each type of subgroup which is possible.

(2) Group coordinators would have the option to establish central control over at least some admin features for subgroups which are, indeed, listed on their page.

I suggest a big caveat to #2, however: as I’ve mentioned before, I am very anti-deletion when it comes to others’ content. I prefer for content to be reversibly hidden or deactivated.

So, for instance, perhaps a group coordinator ought to be able to deactivate a subgroup which is listed on their page, as long as there are robust options for the subgroup members to discuss and perhaps deal with that action. Which brings me to one more point:

Wouldn’t it be best if subgroups have the ability to migrate? To become a group of their own, or (with the right permissions) to be moved to another group? And of course, if this option were available, people should be able to easily ‘track’ that action, as with someone moving a Loomio conversation.

Thanks @gregorycassel for taking the time to articulate that with precision. I think I basically agree with everything you've said, and the federation vs. confederation split is very helpful. It reminds me of what @robertguthrie has been talking about lately (offline), in terms of 'organisation' vs 'community'.

Nice outcome statement. Thank you @alanna.

I've just caught up with this discussion, I followed the outcome statement into it, and just read your comment now, @gregorycassel - I really enjoyed it, thank you.

Perhaps you would like to raise a proposal about it?

I agree with the votation, we have that problem, we trusted 2 guys and they created subgroups, now They are missing.

English translation with google translator

Interesting topic and propose a solution:

1) Create paragraph Sub-groups Historic (see picture), which are saved after a period of inactivity:
1a) empty Sub-groups,
1b) Sub-groups without activity,
1c) Sub-groups by decision of its coordinator,
1d) Sub-groups by decision of the coordinator of the group (in special cases).

2) The contents of paragraph **Historic Sub-groups" can return to its original position, indicating the coordinator of Sub-group or group coordinator.

Something similar to the group members and sub-groups members to avoid affecting the percentage of voting

Interesante tema y propongo una solución:

1) Crear el apartado Sub-grupos Histórico (ver imagen), donde se guardan después de un tiempo sin actividad:
1a) Sub-grupos vacíos,
1b) Sub-grupos sin actividad,
1c) Sub-grupos por decisión de su coordinador,

1d) Sub-grupos por decisión del coordinador del grupo (en casos especiales).

2) El contenido del apartado Sub-grupos Histórico pueden volver a su posición original, por indicación del coordinador del Sub-grupo o del coordinador del grupo.

Algo similar para los miembros del grupo y sub-grupos para evitar que afecte al porcentaje de las votaciones

Thanks @robertguthrie ; I really appreciate the positive feedback and suggestion. I'm kind of new to Loomio, and I don't feel 'up to speed' yet on creating a good proposal for most technical issues. However, I could speculate about permission options. First, I want to try to clarify something I'm not sure of.

The topic here refers to removing or deleting subgroups-- but, that's not how I'm currently perceiving the "deactivate" option. It reads:
"Wait!!! Are you sure you want to de-activate [group name]? You will no longer be able to view the group.
However, if you wish to get the group back you can ask us to reactivate it for you by sending an email to contact@loomio.org."

So, unless I'm missing something, that's a great setup: deactivation is not deletion, and is always reversible. @richarddbartlett , can you please indicate if I'm correct?

With that in mind:

If parent group coordinators got the power--or a switchable setting--to deactivate a subgroup which is visible on their page, then perhaps the subgroup coordinator(s) could get the ability to send a reactivation request, regardless of who deactivated the subgroup?

That, in itself, would seem to resolve the concern about abandoned subgroups.

However, I recognize that giving parent group coordinators and subgroup coordinators equal powers to activate and deactivate the subgroup would not be a sustainable solution for all possible conflicts of interest! So, this would naturally lead to suggestions regarding additional group setting options and permissions.

First, I'd like to focus on this idea of deactivation and reactivation abilities being shared by parent group and subgroup coordinators. This issue might, in itself, make for a good (little) proposal. Any opinions?

@gregorycassel you note some great existing features of loomio. I, too, discovered that the process of deactivating a sub-group is reversable (in theory, I have not tried to reactivate).

If parent group coordinators got the power–or a switchable setting–to deactivate a subgroup which is visible on their page, then perhaps the subgroup coordinator(s) could get the ability to send a reactivation request, regardless of who deactivated the subgroup?

I agree with this idea completely. The parent group should have the ability.

If a sub-group was fighting the parent group to stop its continual removal then I would argue that the sub-group does not get along with the parent group. So I would think that in this situation the sub-group would leave and become its own autonomous entity. Is a sub-group able to brake away migrate to become its own parent group? Being able to transport the members in the group and not the conversations might be enough but it would be fantastic if the conversations could go too.

Thinking more. If the parent group coordinators got the power–or a switchable setting–to deactivate a subgroup which is visible on their page. But the switch wouldn't be instant. It would post a notice in the sub-group asking for objections with a period of a week(or so) to reply; after which the sub-group will deactivate.

This would give members of the sub-group the opportunity to: resolve the problem, stop the removal, or migrate to a new group.

Thanks @lbjoum for your extra thoughts! That's a great idea (in your last two comments) if it's considered a worthwhile programming feat. I suggest the same social feat/event could be accomplished without an added feature, by tagging one or more subgroup coordinators in comments to notify them ahead of time that a parent group coordinator will be deactivating the subgroup later. Does that seem to be sufficient for what you have in mind...?

I definitely agree it would be good practice to not deactivate any subgroup without warning!

Yep that's right @gregorycassel - deactivation is not deletion.

Hi guys, I figured I should just go ahead and try a proposal to 'reactivate' this discussion.

Hi guys, I don't know if there is any Loomio norm for encouraging participation in a new proposal. I guess I could tag some of the previous participants at some point, if that'll help things. :)

@gregorycassel feel free to tag people you'd like to hear from! I think right now things are quiet because it's the holidays :)

I'm going to tag all people who participated here, just in case they have time to consider the current proposal. (Thanks if you do!) :)

@jameskiesel , @waelalsaad , @BenBurton , @alanna , @richarddbartlett , @jameswilson , @gizemcandemirkilic , @CoolBalla15 , @robertguthrie , @josefdaviescoates , @carlosgallogaravan

Hope everyone's holiday season is great so far!

I took the request to be automated, not a manual request. Like a light switch. Am I incorrect?

@BenBurton , I should have checked on that before creating the proposal. I agree with @jameskiesel that relying on manual requests is problematic at best.

I will withdraw the proposal, but I'm hoping we might find an alternative possibility which would scale effectively. (Which is not to imply that it should be a top developmental priority. I try to be sensitive to the Loomio team's developmental needs and priorities.)

@alanna and @richarddbartlett , it would be helpful to know if Loomio has considered any ideas or plans to revise the deactivation and reactivation process. I'm going to guess, for now, that that hasn't been an area of much focus?

I tentatively suggest that fully automating the reactivation of groups would be okay. However, I may be 'missing something'.

Thanks @gregorycassel - I don't think this is something we've put any thought into solving yet, other than what's been discussed in this thread.

This is probably a good time to point out that I'm a huge fan of everything you guys are doing, @alanna , including your keen and pragmatic views on sustainable and scalable development. :) Thank you so much for helping us all to move towards a more positive and genuinely collaborative world.

FWIW I think there needs to be a third role beyond 'member' and 'coordinator'. I think there are plenty of cases where you want multiple coordinators, and you don't want to give them rights over subgroups.

How about this: let's say the person who creates the parent group is the 'organisation coordinator', and they have some special permissions, e.g. they can deactivate subgroups, they can choose whether subgroups can have members from outside the parent group, they cannot be removed by other coordinators, etc.

Would that work?

Comparison is something like Meetup (spitting out the vile taste in my mouth, hate saying anything +ve about M/U)

The overall curator can allow other co-ordinator/s with range of access/responsibility from peer to sub roles, with varying degrees of access to dashboard etc.

Can also allow several types of 'proposal' access ranging from - any member can set up 'event', any three members in agreement can create 'event, or no-one except designated organisers.

In combination, these provide quite a spread of possible configurations.

@richarddbartlett I think you're right about needing a third role. Host? Admin? I think a separate word will be important to differentiate. If you're clear on how you see it working, can you have a stab at a proposal?

I'm going to hold off on a proposal for now, as I'm not super clear on how it should work, what it should be called, or the relative priority of this as compared to other feature development. I just wanted to announce it so say 'this is on my mind and I have a hunch we'll want to design it properly soon'.

Although not the original topic of this discussion.
Moderator may be the third function, in addition to 'member' and 'coordinator'.
The coordinator must be an expert in the functioning of Loomio, therefore useful for the organization.
To moderate must have some special characteristics, in accordance with the characteristics of the group and therefore must be a special person.

It is true that in a group of beginners do not exist coordinator and moderator experienced. As time will be changed by two experts