Sub-groups?

Here are some ideas for sub-groups that have emerged from the conversation. I'm sure there are more...

1. Fundraising and especially collaborative (vs competitive) fundraising.
2. List (could be generated) of pieces of infrastructure software for reference by devs and potential users.
3. Technical architecture document to start to see how the pieces of software do or could fit together.
4. Seal for projects to indicate they are part of the loose federation and accept certain principles

I think that areas of specific interest should be handled as often as possible with tag-based organization instead of hierarchical structures of group/subgroup. Hierarchies are however naturally appropriate for some aspects of personal group membership/permissions, and for task management structures.

@lynnfoster , perhaps your thoughts on "the actual work to be done" tends to parallel my thinking on goals/tasks/subtasks. Does that make some kind of sense? (I'm rushing here; sorry.)

I think that areas of specific interest should be handled as often as possible with tag-based organization instead of hierarchical structures of group/subgroup.

@gregorycassel Good thought, that makes sense. Didn't mean to imply hierarchy, just areas of interest that have emerged. People could follow and contribute to whatever they wish. And I'm sure a lot of people are equally interested in more than one thing. And some people will focus in one area, and follow other areas from a distance.

The core problem in my experience is that topics and their resulting discussions don't tend to neatly fit into a single category. Nonetheless, they will either exist in the general group or within one subgroup.

Ideally, discussions could be associated with more than one keyword/ metadata tag, and each discussion would show up for every tag which it was personally associated with. Each network member could easily follow whichever tags they were personally interested in.

I don't mean that hierarchical group/subgroup structures for areas of interest are inevitably going to do more harm than good. They can be useful if they're carefully mapped, and limited. However, if there is any good reason to develop task/subtask structures-- and I think there probably is-- then I think that that's a much better use of Loomio's group/subgroup feature.

I would suggest letting sub-groups make themselves apparent, rather than creating empty containers before knowing what's required