Let's use GitLab's subgroups feature

https://docs.gitlab.com/ee/user/group/subgroups/

We aren’t limited to a single level of groups! As useful, we could have this effectively mirror whatever Sociocracy structure we have. We can also use this to have confidential subgroups within overall public groups.

I see lots of ways this hierarchy could be helpful. It would also be another way to organize issues and not get overwhelmed.

Update: added a relevant issue https://gitlab.com/snowdrift/governance/issues/59

3 Likes

This seems like a significant priority! - Could directly benefit (and potentially be blocker of) issue grooming and labeling (categorizing task management etc,)

1 Like

I think sociocracy structure is designed to be able to change very quickly depending on work load, outside circumstances, upcoming challenges, …

What does it cost to change the GitLab group structure? E.g. if URLs change, that would be very bad.

It sounds as if you had in mind different “issue lists” for different teams, i.e. every team has its own “personalized view” of what needs to be done – this way the issue list would only contain things that is relevant to you and that you can do right now.

What advantages would using groups have over tags + filtering for tags?

I think the primary benefits of subgroups generally are oriented for for contained permission levels & notifications, etc. for team members, which isn’t the most pressing issue for us - see gitlab docs. Definitely low priority imho until we have completely hashed out roles that fit.

That’s a good point - luckily gitlab has addressed this

1 Like