Loomio

Parent group ability to remove sub-group

J
Joum Public Seen by 347

A few times now, I have encountered the situation where a trusted person creates a sub-group and is the only person with the ability to remove the group when it is no longer needed. Then this person then leaves loomio without giving others the ability to delete the sub-group.

I love that the parent-group-coordinators can restrict the creation of new sub-groups but I think they should also have the ability to remove one.

Is there a solution to this or is the only option to ignore the sub-group (which is annoying) or to create a whole new parent group and start again?

JK

James Kiesel Sat 29 Nov 2014

Seems like a permission that could be added; I can't think of a reason to not give parent group coordinators that ability.

Like everything else though, it'll be something that's looked at after 1.0 is stable. :)

WA

Wael Al-Saad Sun 30 Nov 2014

I think the creation of sub-groups should be the task of the group coordinators only. This will help them coordinating the flow of the group.

At the end loomio features should defines certain governance model, by choosing certain options.

Here is a nice story from the field about how groups governance model effects it's thrive and productivity

http://www.ic.org/radical-governance-changes-in-two-north-american-ecovillages/ ( http://www.ic.org/radical-governance-changes-in-two-north-american-ecovillages/ )

GC

Greg Cassel Sun 30 Nov 2014

I like that coordinators can allow all members to create subgroups, if they want that flexibility. However, the inability to remove subgroups created by inactive members is a real problem; thanks @lbjoum for pointing that out.

I suppose it might be ideal to allow inactive subgroups to be "Hidden" or archived in some reversible way. Generally speaking, I'm resistant to deletion of other people's content.

GC

Greg Cassel Sun 30 Nov 2014

@waelalsaad , I found that link about varied revisions of consensus and supermajority governing models to be very enriching; thanks for sharing!

BB

Ben Burton Tue 2 Dec 2014

Group owners absolutely need to be able to have some long term ownership over sub-groups, otherwise trolls could start absurd sub-groups that would be out of control.

AI

Alanna Irving Tue 2 Dec 2014

The tricky thing is that good permissions in terms of keep groups tidy and allowing needed admin sometimes comes into conflict with subgroup privacy and autonomy.

For example, I'm a coordinator of this Loomio Community Group. But there are subgroups I'm not even a member of (and don't want to be, because I don't need their notifications, etc), and shouldn't be (because they have sphere of decision-making stakeholding that doesn't include me).

So could we somehow give parent group coordinators the ability to delete subgroups without making them have to be a member of the subgroup?

J

Joum Tue 2 Dec 2014

Thanks @alanna

I would not interfere in an active subgrouo but in our case they are inactive and perhaps only have one member - the creator. We have tried contacting the creator with no success. In future we will try to embed an inactive member so that we have access if needed. Having obsolete subgroups in our loomio page structure is an inconvenience and a nuisance. We are working on consolidating our subgroups for a less fractured structure. ATM we have more subgroups than active members.

If we were able to gain access as coordinating members we could resolve the problem.

I raised the subject here because I thought others might have the same problem.

AI

Alanna Irving Tue 2 Dec 2014

@jameskiesel you mentioned a permission could be added to address this. How would that work? Would it mean that the parent group coordinator would also have to be a member of the subgroup?

JK

James Kiesel Tue 2 Dec 2014

I don't think so. It's easy enough to say

"is a coordinator of the subgroup or is a coordinator of the parent group" in the permissions file.

GC

Greg Cassel Tue 2 Dec 2014

@alanna , I mentioned some reticence regarding deletions in one comment above. I'd like to clarify that now.

The ability to permanently delete things is metaphorically like having a gun, regardless of whether one wants a gun or not. The ability to 'Hide' things, by contrasts, is like having a nice nonlethal weapon. The use of 'Hide' can be subject to subsequent group consensus discussion.

This relates a great deal to my personal experience administering a very active and feisty fb discussion group. While we barely ever delete or hide anything, the specter of deletion is always present. I prefer to minimize the chances of personal irreversible mistakes.

J

Joum Tue 2 Dec 2014

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

AI

Alanna Irving started a proposal Wed 3 Dec 2014

Parent group coordinators can hide subgroups Closed Mon 8 Dec 2014

Outcome
by Alanna Irving Mon 27 Feb 2017

There is not consensus that parent group coordinators should always have admin rights over subgroups, but on a practical level sometimes coordinators need to modify subgroups. This has sparked an interesting discussion about group hierarchies vs federated groups.

Just testing if this solution works for what people are talking about here. In this scenario, parent group coordinators would have the option to hide/archive (not delete) subgroups. They would not have to be members of the subgroup to do this.

Agree - 2
Abstain - 2
Disagree - 2
Block - 2
6 people have voted (2%)
GC

Greg Cassel started a proposal Tue 23 Dec 2014

Allow parent group coordinators to deactive visible subgroups Closed Sat 27 Dec 2014

Outcome
by Greg Cassel Mon 27 Feb 2017

I closed the proposal because its current form would not scale well with Loomio's expected growth.

Parent group coordinators should have an option to deactivate subgroups which are visible on their group page, but that action should be visible as a notification for all group members.

Subgroup coordinators, as well as parent group coordinators, should be able to send a request to Loomio to reactivate a deactivated subgroup.

Loomio should set reasonable limits on the frequency of deactivations and reactivations.

Subgroups should retain their current option to switch to the "Members only-- the group will not be listed" option.

Agree - 5
Abstain - 5
Disagree - 5
Block - 5
7 people have voted (2%)
RDB

Richard D. Bartlett Wed 3 Dec 2014

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).

JW

James Wilson Wed 3 Dec 2014

@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?

BB

Ben Burton Wed 3 Dec 2014

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

AI

Alanna Irving Sun 7 Dec 2014

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.

RG

Rob Guthrie Sun 7 Dec 2014

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.

JD

Josef Davies-Coates Thu 11 Dec 2014

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?

RDB

Richard D. Bartlett Thu 11 Dec 2014

@josefdaviescoates here's one real world example.

RG

Rob Guthrie Thu 11 Dec 2014

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.

WA

Wael Al-Saad Fri 12 Dec 2014

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.

J

Joum Fri 12 Dec 2014

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

WA

Wael Al-Saad Fri 12 Dec 2014

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

GC

Greg Cassel Fri 12 Dec 2014

@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.

GC

Greg Cassel Fri 12 Dec 2014

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.

RDB

Richard D. Bartlett Sun 14 Dec 2014

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'.

RG

Rob Guthrie Mon 15 Dec 2014

Nice outcome statement. Thank you @alanna.

RG

Rob Guthrie Mon 15 Dec 2014

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?

AG

Alberto García Mon 15 Dec 2014

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

CGG

Carlos Gallo Garavano Mon 15 Dec 2014

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

GC

Greg Cassel Tue 16 Dec 2014

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?

J

Joum Tue 16 Dec 2014

@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.

J

Joum Tue 16 Dec 2014

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.

J

Joum Tue 16 Dec 2014

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

GC

Greg Cassel Tue 16 Dec 2014

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!

RDB

Richard D. Bartlett Wed 17 Dec 2014

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

GC

Greg Cassel Tue 23 Dec 2014

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

GC

Greg Cassel Wed 24 Dec 2014

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. :)

AI

Alanna Irving Fri 26 Dec 2014

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

GC

Greg Cassel Sat 27 Dec 2014

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!

BB

Ben Burton Sat 27 Dec 2014

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

GC

Greg Cassel Sat 27 Dec 2014

@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'.

AI

Alanna Irving Sun 28 Dec 2014

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.

GC

Greg Cassel Sun 28 Dec 2014

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.

RDB

Richard D. Bartlett Sun 28 Dec 2014

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?

G

Gray Sun 28 Dec 2014

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.

AI

Alanna Irving Mon 29 Dec 2014

@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?

RDB

Richard D. Bartlett Mon 29 Dec 2014

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'.

CGG

Carlos Gallo Garavano Mon 29 Dec 2014

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.

CGG

Carlos Gallo Garavano Mon 29 Dec 2014

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

AI

Alanna Irving
Abstain
Wed 3 Dec 2014

I feel like we haven't quite got to the root of this issue yet. Let's keep talking.

BB

Ben Burton
Disagree
Wed 3 Dec 2014

I think it's important that we clarify and come to consensus on what the issue is before we develop and design a solution. Cart before the horse.

What problem are we solving and how many options are there to realistically solve that problem?

J

Joum
Agree
Thu 4 Dec 2014

In certain situations the list of subgroups becomes too long if you are unable to hide or remove old unused subgroups.

J

Joum
Agree
Thu 4 Dec 2014

In certain situations the list of subgroups becomes too long if you are unable to hide or remove old unused subgroups.

New role as suggested by Richard D. Bartlett would also solve the problem.

GC

Greg Cassel
Agree
Tue 23 Dec 2014

This is a 'compound proposal'. I currently think that all of the listed conditions should co-exist.

RDB

Richard D. Bartlett
Disagree
Wed 3 Dec 2014

I think we want to add a new role (see comment)

J

Joum
Agree
Tue 23 Dec 2014

GC

Gizem Candemir
Agree
Sat 27 Dec 2014

AI

Alanna Irving
Disagree
Sat 27 Dec 2014

Unfortunately anything relying on manual requests isn't going to be scalable. I agree with James.

JK

James Kiesel
Disagree
Sat 27 Dec 2014

I'd rather not have this process reliant on the Loomio team at all - it's not a scalable solution that way.

BB

Ben Burton
Agree
Sat 27 Dec 2014

This appears to be a simple addition that would allow for more organization of the data.

BB

Brandon Burns
Agree
Tue 23 Dec 2014

GC

Gizem Candemir
Agree
Wed 3 Dec 2014

BB

Brandon Burns
Disagree
Wed 3 Dec 2014

BB

Brandon Burns
Disagree
Wed 3 Dec 2014

Sorry, but I have to disagree.

GC

Greg Cassel
Abstain
Wed 3 Dec 2014

I greatly prefer for coordinators to have 'hide' options in addition to 'delete', for anything which they can delete. However, I don't yet understand the 'organisation coordinator' concept of @richarddbartlett .