Issue: Adding sub-group members to the main group

We have a plan to fix these woes, but it's a slightly multi-phased plan :)

In the near future we're going to be rolling out a feature called 'Announcements', which I'm very excited about. This will allow us to have a single input box to invite basically anyone you know to anything you'd like on Loomio (that's the plan at least). Here's a mockup of that screen:

(that 'Fruit of the Boom' is the name of a test group with 3 members in it)

The next step from there will be to apply that form to inviting people to groups (the upcoming release will allow you to invite people to decisions, threads, and to notify them of outcomes). So the flow will be
1. Start a group
2. Open that screen
3. Type in the names of existing groups, individual loomio users, or email addresses that you'd like to invite to your group.
4. Send!

This fixes your particular UI nightmare by allowing you to open that screen at any time, type in the name of the parent group (or a sibling subgroup, or some other group, or some individual person you want involved), and we'll be smart enough about inviting only the people who aren't already in the target group to join.

You'll also be able to granularly control who's invited, so if you have a group of 10 people and you want to invite 9 of them (It's Brad's surprise party and he can't know about it), you can click on the group name and manually add or remove folks in the group you'd like to invite.

Soooo... we're working on it, stay tuned! :)

An "invited/pending members" option would be interesting for offline groups with members that haven't accepted their invitation yet ;-)

Thanks @gdpelican . The announcements feature looks really useful. I'd like to explain my use case a bit more to check if it fully resolves my issue.

Here was my experience as a new group administrator with the main group and subgroups each linked to their own slack channels.

• I invited my first set of users to join the main group - associated with a new #loomio channel in slack. Not everyone accepted the invitation.
• We tried using Loomio for a couple of discussions and decisions.
• After a short period of time, I decided to create sub-groups, each attached to a slack channel. I used the feature where Loomiobot posts an announcement in the slack channel with a link that people can click on to join the subgroup attached to that channel.
• Some people clicked on one or more of those subgroup links in slack, so wound up in one or more subgroups but not in the main group.
• I continue to add more subgroups associated with other slack channels. When I want to specifically invite people to a new subgroup and mention them in a subgroup discussion, it wasn't really easy to do if they weren't part of the main group. If they had accepted their invitations to the main group, I could have just selected them from the list so they'd be part of the subgroup and immediately available to at-mention in subgroup discussions. Since they didn't accept the invitation to the main group, I had to look up their email addresses and type those in to make sure they were invited to the subgroup - and even then they had to accept that invitation before I could mention them in the discussion.

So in short, my problem was that I wanted to ensure people who had accepted an invitation to any one of my subgroups could be easily added - without them needing to accept an invitation - to any other subgroup or the main group.

Also, I'd like it to be the case that if someone is invited to several subgroups and the main group before they have signed up for loomio, and they subsequently sign up for loomio - all of those invitations turn into group/subgroup memberships.

Does the announcement feature address these cases?

If the user has accepted an invitation to some other subgroup, can I simply add them by name ore email address to the new subgroup - skipping the part where they must accept an invitation to the subgroup to start participating? Presumably they should be able to remove themselves if they want, but can I add them without needing them to take action to accept an invitation?

If the user hasn't accepted any invitations and hasn't created a loomio account, but has been invited by email address to several groups or subgroups, when they sign up for loomio will they be accepting all of those invitations or do they have to accept each one individually?

Also, how will the "by name" part of that feature work when adding people to a subgroup? Which names will be available to add? All Loomio users across the world? All Loomio users who are members of any of the groups or subgroups that I'm subscribed to? Just users who are already part of the main group or any of its subgroups?

Thanks for the detailed feedback, it's always really great to hear from wranglers about how we can improve the onboarding, which has to be silky smooth for any group-related software to work.

We haven't written the code for the group invitation stuff yet (it's a bit hairy, which is why we're starting with invite to thread and invite to poll first), so I can only comment that we'll be looking at the experience you're describing very closely when that time comes. My gut reaction is that it's very tempting for the facilitator to want to overstep their power here, and we've had some user feedback that letting coordinators add people to other groups without confirmation is not behaviour that they like or want to encourage.

We may end up with a user setting for this ("Require my confirmation when being added to a group"), or more likely it'll be something like a user can be added to a subgroup automatically if they're part of a parent group, but they'll need to confirm that they wish to be added to a separate group unrelated to the one that you currently share; the experience we need to avoid is someone waking up to 1,000 unread threads overnight because someone added you to all of their groups that you don't care about [It's happened to me too :)]

The 'by name' currently has logic that amounts to "Users who are in groups that you're a part of". Those names will (in my current brainspace about the feature, which is occasionally fickle) continue to show up as invitation options, but instead of adding to the group instantly, will send an invitation directly to that user, which they can accept or decline in-app (or via email).

Re: multiple invitations to the same address, the intended experience there is that if you're logged in, and accept an invitation, that membership is associated with your user automatically. We can't simply accept all invitations associated with an email address because we only know that the user wants to accept invitations that they click on, and maybe they are ignoring the other invitations because they don't care. (IE, it would be a very nasty side effect if creating an account had the ability to add you to all of the groups you've ever been invited to).

I could imagine a screen which pops when you first log in and shows you all of the pending invitations you've received at that email address, and allows you to select which ones you'd like to convert to memberships; that would be cool and useful (and maybe we can talk @eddalley into building it :) ). But it's not on the immediate roadmap here.

Things that I didn't talk about because they're not as clear to me yet:
- Should you be able to get added to a parent group automatically just because you're part of a subgroup?
- Do you need be able to 'block' someone from sending you further invitations if they're being annoying?
- If you leave a group, should that prevent future direct invitations to that group?
- If you've participated in a thread in a group, without being part of that group (which you can do now with Invite to Thread, yay!), can the facilitator then add you to that thread?

My gut for all of these is that we want to default to the 'handshake' mechanism, ie, there is a request and a confirmation (an action from each side) to enter into the 'contract' of entering a group. The request is pretty clear (the facilitator has invited someone somewhere), but the confirmation on the user side has some edge and corner cases we'll want to root out, and I'd like to err on the side of 'You can't be added to groups unless you say you want to'.