Group Ownership

maybe it would be better if there are also moderators.

And the differences between admins and moderators would be the following:

A moderator can:

• create sub-groups
• delete other's comment
• accept or decline membership requests to sub-groups
• and anything else usually do the moderators

An admin can:

---> can do everything

How about that and not just ownership?

What if groups could vote in another admin (or moderator). So, someone starts a proposal that says "make X an admin," and then if that person gets enough votes, they become an admin.

Hmm... I understand the intent here, but as a general design principle we tend to only try to solve the most immediate problems.

Personally I haven't seen this problem yet so it's hard for me to imagine a solution without getting into too-theoretical territory.

I wonder if others have an experience of a Loomio group that got into difficulty because of this problem?

I can make a suggestion on this issue..... You can have one owner and one "vice-owner" the latest without administration permits. The owner has to have a 3/4 positive feedback within its group, meaning that every group has a "loomio type" vote poll (with secret vote) permanently ongoing for the judgement of the owner, if the positive feedback of the owner drops below 3/4 automatically the vice-owner is named by the system owner and the former owner a plain member of the group. I think that will work.

It can also be another solution. To have 1 owner and 1 or 2 alternative owners and if something can happen to owner the alternative/s can claim it but and the owner puts the alternative owners.

But we must find a way not to false claim the group an alternative owner.

Hi Chris, as I understand Loomio is about participatory democracy decisions, not group ownership ;) .
If you have a group which disagrees in 3/4 with the owner`s management and the group is not able to change it, the overall concept of the application is wrong on a consensus basis point of view.

@miguelpradosrodrig I agree.

But one question to all. How do we protect the group from overtaking from people with bad intentions???

@christaklis if 3/4 of the group want a different direction is not a takeover is deliberative democracy at work and it is fantastic !

@richarddbartlett the most pressing issue would be to agree a protocol/system for what happens if a person who creates a group disappears.

This could be as simple as suggesting that people requesting groups have a home on Loomio be asked to think about who else should have rights to administer the group, with a place on the form for 2 or 3 additional email addresses.

Having this in place is likely to save Loomio a lot of work in the future.

I have a question that concerns Loomio group ownership in terms of admin. Our group has an organisation team which selects from all members who volunteer for a position. If we adopt Loomio I understand an individual would register the group in their name / with their e-mail details. Should this group owner move on (in an amicable way), is it possible to transfer ownership of the Loomio Group to another person?

Having had an experiment, is it simply a case of changing the owner details of the group in the user settings page?

@stewart groups don't have 'owners' per se, there are coordinators. The person who created the group is the first coordinator, and can add other coordinators at any time. The person who created the group doesn't have any additional rights compared to any other coordinator.

If you click 'Members' on the bottom right of your group page, you'll be taken to the members page, where you can add/remove coordinators.

Make sense?

@richarddbartlett Is the person who created the group the only person who can manage members in this way? That would seem to be an additional right. I understand they also have the ability to delete a group? Am I correct? My concern is how to transfer ownership in those terms to an incoming member from a member who leaves the group. I'm not sure whether I have explained myself well. I envisage the Loomio group to be created with an e-mail that is unassigned to a specific person (therefore transferable between incoming and outgoing members) and wonder if that is possible.

@stewart lets say you start a group and then add some members. Because you created the group, you are the first coordinator. If you promote any of those members to be a coordinator, they will have all the same rights as you. This includes the ability to remove you from the group.

The transferrable account is an interesting idea, which you could certainly try. E.g. you might sign up for a new Loomio account using 'coordinator@mygroup.com', and create a new group with that account. Then when it is time to move on from that group, you could just pass the login details for that account on to the incoming coordinator.

Thanks @richarddbartlett . I'll give that a try and see how it goes.

@stewart, not sure whether this is entirely relevant to your comments but just thought I'd mention that it is not currently possible for the only coordinator of a Loomio group to leave. There must be at least one coordinator per group so if a coordinator intends to leave their group they need to promote another group member to coordinator beforehand.

Thanks @hannahsalmon, I think I understand it now and there doesn't seem to be any functionality added for me to achieve what we need.

very happy to see this discussion. we talked about this a lot in the Occupy NYC tech groups with the projects we were working on (that ultimately did not come to fruition).

i think the goal to ultimately shoot for should be one where group status (e.g., coordinator, or not) and group actions (e.g., removal of a member from a group, classification and closing of a discussion as off topic) are themselves tied to decision outcomes. this mirrors the way that many meatspace consensus-driven groups work.

of course, it's impractical to require a group decision for every little thing, so it also makes sense to allow the group to delegate/appoint an individual with powers - like managing group membership, or moderating discussions. such appointments could be permanent, or time-bounded.

now...i have yet to actually USE Loomio properly for something yet :) so i'm not sure how much of this is implemented; i'm just going off what @richarddbartlett has said here about 'coordinators.'

Cool.
My thinking is that we create an owner role, (but there could be more than one owner). An owner of a group cannot be removed by anyone else.

On the other side.. we create automatic privileging where users who become active over a period of time are granted administrative privileges automatically (this is optional per group) to encourage shared responsibility.

I do like the idea of a proposal to grant admin/coordinator rights. That's also super cool.

@samboyer I think that's a really good idea! Right now, we're making Loomio mostly for groups who want to work well together, since even if you're trying your best it's still really challenging to collaborate and it really shouldn't be this hard. For a group that acts in good faith right now, it would be easy enough to implement what you're suggesting with the existing feature set - just have a policy in the group that to add or remove coordinators requires a proposal.

Obviously, not every person in every group will act in good faith, so other solutions may be required. I think the feature that automates the process that you're suggesting is really good. I'd like to see some groups implement the practice with the existing technology and see how it works for them first, so we can validate if we really need a new feature and if so how it should be designed to best function.

@robertguthrie sure, i think what you've described there is a viable approach. i do generally prefer the idea of there never being an "owner," instead disaggregating that type of role into a set of discrete permissions that can be allocated through process - but an owner works too. i do think there's a lot of potential in the area of privileges that 'fade' over time - real-world groups decay without activity, and that's something worth mirroring.

one of the things we talked about a fair bit was the idea that the group model should change, perhaps even a little predictively, over time: when a group is first formed, it places all the permissions in the hands of an 'owner.' when it then reaches a certain size/age/combo of the two, those privileges are automatically broken away from the owner and placed in the collective hands of the group (to then be delegated). this sorta mirrors the way that groups change as they grow and mature, where it's kinda fast and loose at the beginning but (can) move towards a more distributed base of power over time.

@alanna - sure, architecting for the case where people aren't acting in good faith definitely makes things much, much more complicated. real-world consensus-driven groups often can be blown up by even a single person acting disingenuously - that's a good sign that insulating against that case online would be at least as much of a challenge.

that said, though, i think there's a benefit that comes from making "internal" group processes more visible - and more generally, making group implosion/death a more visible thing - is because of the benefit it has to people looking in from the outside. while some might prefer to avoid "airing our dirty laundry in public," i think there's a bigger risk: in self-organizing communities, it's generally a nightmare for people on the outside to find their way to the healthy, functioning conversation.

i observed this several times with Occupy in NYC (and elsewhere, but never as fast as with Occupy). we went through several mailing lists: they started small with just some core, central actors, then blew up to have tons of people. noise began to exceed signal, and the core, connected folks left the list and started a new one. this was fine for those in the know, but as time went on and the graveyard of dead lists (but still heavily trafficked by people just sending blasts to every email address they could find) got larger, it became more and more difficult for folks coming in from the outside to find their way to the center of what was really happening.

so, it's not just a question of building the software around assuming good actors. things happen, groups die - it's often a shame, but it's also a normal, natural thing. letting them die in a way that's organic (read: happens with minimal human intervention), but clear and clean is really important to keeping the signals strong for newcomers.

btw, i realize all this is pretty abstract - i'm not tryin to jam you guys up, or get in the way of immediate progress. not at all. just trying to paint a picture of the wider considerations as food for thought :)

I totally agree that as the group grows and dies and is reborn administration can be handled in more scalable ways.

I like all this thinking.

Really great thoughts @samboyer - looking forward to thinking together more on this. You're bringing up some really central aspects to how self-organizing groups succeed, or fail. One thing I've noticed time and time again on Loomio is that even with its super simple functionality, what it does is make the often implicit group structure (how information flows, who really makes decisions, where the action's happening) really explicit. Often that means it turns up all the dysfunction! But if a group is going to succeed, they need to become aware of and deal with that dysfunction proactively. So anything we can do to support that process happening is really important.

My experience with the global Indymedia network was somewhat similar to what @samboyer describes. In the early days, as people flooded in to get involved, a plethora of email lists was created to keep things manageable. Later on, as the number of people actively involved dwindled, many of those lists were orphaned. The important conversations took place on whatever lists still had a critical mass of users, which as @samboyer describes, made it hard for new people wanting to get involved to find them.

I think Loomio already offers a solution to this problem through the thoughtful use of Subgroups. It would be good if Subgroups could be 'closed' if they're no longer needed, so they're not listed under the active Subgroups list, but their contents are 'archived' somewhere for reference.