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

[kaberett]

denise has suggested that one possible solution might be to co-opting the concept of 'friend groups' for comm purposes -- so each comm has a "can add tags" group, "can remove tags", group, "can manage members" group, "can edit the comm profile" group, "can manage the comm style", group, "can screen comments" group, "can handle moderation queue" group, and so on, with the ability to move members in and out of those groups as needed.

Something I've been wondering about is massively increasing the number of checkboxes on /communities/$community/members/edit -- current tickies are "member", "posting access", "administrator". It seems to me that the obvious (but clunky and cluttered) way to get the desired functionality would "just" be to add more tickies for every set of delegable permissions -- but, as I say, that's decidedly cluttered, and won't be relevant for the majority of comm members (but the same is true of admin status...). If this were the route gone down, it would probably be helpful to have a master ticky for "let everyone tag posts" (e.g.), that's tied into the comm settings of tag permissions, but again that gets... gnarly and a bit unwieldy quite fast.

Admin console commands would be nice but wouldn't be terribly user-friendly.

So I am currently pretty much at *chinhands*...

[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.

[kaberett]

http://www.dreamwidth.org/support/see_request?id=31590