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

[ninetydegrees]

Hmm. How about if I could do this in two different ways? Number one: pick a user and edit all permissions for them. That's nice for admin changes and other stuff which isn't relevant to most members as you pointed out (bonus points if this can be an ajax-y pop-up or a magic section like settings on the beta entry page). Number two: pick any setting (admin, add tag, etc.) or possibly several ones for bulk changes and have the table only display the settings I've selected. Could still be a big clunky table but hey I'm the one who picked too many settings... :)

[denise]

Yeah, I think that whatever we wind up doing, it will wind up being loads of sub-pages.

[silverflight8]

Maybe split into "admin-ish" and "non-admin" groups? The latter group stays with the current permissions (eg post without moderation). If you want to give specific privs to someone, tick a single box "give admin permissions" which you can then edit more finely on another page, which *only* addresses admin privs? The first tick should just sort the new-admin into the admin category, not suddenly give them all the privs.

[kaberett]

... I am actually really into this idea, huh. But okay, so, the current checkboxes are "member", "can post", "administrator". So do we want to add an extra checkbox for "additional permissions", or do we just want to replace "administrator" with "additional permissions"?

And then the Additional Permissions management page could do the thing where you do uh

username | administrator | permission 1 | permission 2 | permission 3 | ...

... where "administrator" is a master-ticky that checks all other permissions automagically, or you can grant a subset?

[swaldman]

Unless there are a very large number of new permissions being talked about, I'd simply replace Administrator with the new ones - perhaps in a visually seperate section. I'm against having an extra page to work through unless it's very unwieldy not to.

[silverflight8]

Two separate things:

I kind of agree with swaldman actually. How many separate privs are there going to be? This isn't really a feature that a lot of people will use early on, or necessarily at all - mostly for people who have large active comms, right? So maybe it's not necessary to split up the page. Though on second thought, all comm admins would have to look at a page of five million checkboxes. Now I don't know.

I would lean towards "this tick box allows you to start granting privs to otheruser" (and then right next to this option have links to "Now go here to choose admin privs"). Mostly because I'd rather initially under-grant permissions than over-grant.

Thoughts?

[kaberett]

Agreed that under-granting is better than over-granting.

Individual permissions that could be granted include at least:

• can add tags
  
• can remove tags
  
• can create tags
  
• can manage members (invite, approve, remove)
  
• can edit the comm profile
  
• can manage the comm style
  
• can screen comments
  
• can unscreen comments
  
• can freeze comments
  
• can unfreeze comments
  
• can handle moderation queue
  
• can view/make "admin-only" posts (would need to rethink this terminology!)

Probably "can grant administrator status" gets tied strictly to the current concept of "administrator" rather than being a separate priv.

[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!)

[kaberett]

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

[denise]

Approved you! (This is incidental to the discussion, but.)

[kaberett]

:D Writing up a spec now!

[denise]

I think we are probably going to need sketches or wireframes for this one, sigh.

[kaberett]

THE PRE TAG AND TABLES, YEP YEP