Brainstorming specification: granular community permissions

[kaberett]

Community admins frequently want to delegate specific tasks to specific users; for example, I'm generally responsible for tagging dw_suggestions but for no other tasks; it's common in RP communities for a particular user to be designated the "coding admin", responsible for layout and styling.

In the case of tagging, there have been several suggestions about making tagging permissions more granular and for that matter more obvious to the user. However, even these suggestions end up breaking down permissions to a choice of: admins only, entry author and admins, members only, anyone.

In practice this means that either (a) work gets concentrated on a relatively small number of people who aren't necessarily best placed for the job, or (b) admin status gets given to a large number of people, none of whom need all the permissions they've been granted. It would be much better if it were possible for admins to grant specific permissions to specific users as required, rather than the broad-brush systems currently in place.

The difficult (as ever!) is designing a suitable system it in such a way that it avoids being overly confusing and leading to somebody giving somebody else powers that they didn't mean to delegate, and avoids decision fatigue.

The purpose of this post is to hammer out how more granular permissions might work, both back-end and front-end (in terms of what the options presented to community admins look like). Please do drop thoughts/suggestions/requirements/etc in comments; discussion positively encouraged.

ETA wiki page that triiiies to provide a list of what all community maintainers do

Comments

[swaldman]

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.

[silverflight8]

I just took a look at a comm I moderate. Even on a computer (though admittedly small screen), the checkboxes already fill up most of the screen. More importantly, though, is the fact that not only would there be a lot more checkboxes horizontally (scrolling sideways, yuck!) but also there's a lot of members. When membership starts to paginate and you have to keep scrolling down, that's a lot of people to scroll/click through horizontally and vertically to find the correct person and give them the right privs. I'd rather be able to say "I want to deal with these specific pool of people and only look at them now to give them privs".

[kaberett]

yep. that's pretty much where I'm at.

[swaldman]

Oh, wow, all members are on one page as a matrix? Sorry, didn't realise that (I don't admin any communities). Suspect that's unwieldy even at present.

So, take my thoughts above, and add at the top a proposal that only one user's permissions are edited at a time. This would get tedious if a lot of users were to have permissions, hence my thought about introducing a "roles" system as another layer.

Hope that's clear, but I'm really tired, so please ask for clarity if not ☺ (and if you care!)