Build out membership system + augment invite system

[taoeffect]

Problem

Invites are not merely invites to individuals. GI supports arbitrary kinds of members, and arbitrary rules for adding members. The current system does not have this flexibility, and we must make sure not to move forward with invalid assumptions.

Solution

• Build out generic membership concepts, and implement three kinds of members/atoms/units (individual, group, unit), but perhaps make all three of those special cases of groups (e.g. group of 1, group of 2, group of 3... etc.). See related issue on "Cell abstraction" #207
• Create an invite system for these atoms that is totally generic and not solely based on voting.

[sandrina-p]

Could you better explain the difference between those 3 kinds of membership?

[taoeffect]

Could you better explain the difference between those 3 kinds of membership?

Sure, basically every group is composed of "slots" for its members.

Currently we think of a "slot" as referring to a single member — an individual.

In the future, however, we want these slots to be a fully generic abstraction, capable of supporting n members.

A slot could refer to an individual, or it could refer to a couple, or it could refer to an entire group that's plugged into an existing group. The rules for how payouts are handled for different types of slots can be different as well. Some of this info is on the gitlab wiki, and we'll organize more of our thoughts about the design there.

[sandrina-p]

Thank you for the clarification! Will those "slots" be part of the MVP or we will just start with the "Individual"?

[taoeffect]

@sandrina-p I think it should be part of the MVP... if it's not difficult to do. It's often a lot easier to create the right generic abstraction early on and add features to it later, than to work without the right abstraction and have to delete and rewrite everything you did.

[sandrina-p]

I agree with what you've said. So the step "add members" should be rethinked, since its no longer an "individual". Also, if you can add a "couple", how to I create "a couple account"? Wouldn't that be the same as a group but with only 2 members?

[taoeffect]

Wouldn't that be the same as a group but with only 2 members?

No, for now, don't worry at all about this. The prototype is not going to have this feature, and the abstraction is only important at the code-level, much less important at the UI/UX level. For now, just focus on taking what we've done with the dashboard and turning that into markup. Once we have that we can move forward with other details. :)

[mmbotelho]

@taoeffect I think this might have been solved in one of your pull requests, but I am not sure

[taoeffect]

@mmbotelho Nope, this is actually high on my priority list, one of the things I'll be working on next.