I agree that on the back end, using friend groups - which aren't currently used for communities - makes sense. It's a bit of a kludge, but it's something for which most of the infrastructure is already on place.
The remaining functionality (rather than UI) decision, then, is whether there are fixed groups, one per permission, where somebody gets added to as many as appropriate - or whether groups are definable as "roles" with configurable permissions (github does something along these lines, I think). I think I'm in favour of the first for simplicity. I suspect that roles are an unnecessary layer of abstraction, but I can see how they might make management easier for comms with a large number of people with these permissions.
As for UI, others are better at that than me, but it strikes me that we shouldn't be afraid of having lots of tick boxes on a screen. This is an admin tool for communities, not something that we expect most users to be using every day. I would prefer to see a screen with many controls than multiple screens that take ages to work through.
no subject
The remaining functionality (rather than UI) decision, then, is whether there are fixed groups, one per permission, where somebody gets added to as many as appropriate - or whether groups are definable as "roles" with configurable permissions (github does something along these lines, I think). I think I'm in favour of the first for simplicity. I suspect that roles are an unnecessary layer of abstraction, but I can see how they might make management easier for comms with a large number of people with these permissions.
As for UI, others are better at that than me, but it strikes me that we shouldn't be afraid of having lots of tick boxes on a screen. This is an admin tool for communities, not something that we expect most users to be using every day. I would prefer to see a screen with many controls than multiple screens that take ages to work through.