Required feedback from FreedomCoop admins for the migration-upgrade of the membership system

[bum2]

This is a recurrent message from me in the devs and admins chat, in order to receive some feedback from the FreedomCoop coordinators and maybe some of the OCP admins opinion, but still haven't found answers or points of view from nobody, and so I open that coordination task as a github issue to make again the explanation and give more visibility to it.

The old (but actually in prod) membership system for FreedomCoop was configured custom with a broad context agent named "Freedom Coop" and a nested 'child' project named 'FreedomCoop Membership Requests" (or similar name in testocp). The second sub-project is the one managing the memberships and the share payments, but then, when candidates became full members they are changed manually from the sub agent to the main FdC agent as active members, but this workflow is totally not implemented in the new generic system for membership, which expects the members to be always related the same project, both as candidates or as active members.

The only point here is to decide at least with the FreedomCoop coordinators (we can use FdC as an abbrev of FreedomCoop) what solution we give to this situation. The possible options, as explained in the chats without success, are:

• we want only one FreedomCoop agent in OCP: That means their admins must decide what to do with the diferent sub-projects existent in both agents, do we merge all as sub-projects of the same single FdC context agent? I thought they are separated as two groups for any reason that i don't know...

• we keep two agents (because thare are reasons to keep at least two sets of sub-projects), but i still don't know that suposed reasons, and my proposal was going in this direction, but this implies few big changes:

  • rename the actual agent named "Freedom Coop" as something like "Freedom Coop Network" or similar
  • rename the actual FC Membership agent into the real "Freedom Coop" agent, representing the cooperative, with the join requests, the payments and shares and keeping all the members in any state in that group.

Chosing the second approach we can keep some sub-projects as childs of the broader 'FdC network', and then put under the now main FdC agent the sub-projects we decide as more meaningful for the members to use.

If admins and coordinators prefer the first approach i can understand because is clean and clear, just one FdC agent in OCP, but then all sub-projects will be merged as childs of the same agent and perhaps they are not all meaningful for the members.

Please give feedback to decide on this one and keep on going ahead with the super needed migration of the FdC membership process...