![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Brainstorming specification: granular community permissions
Community admins frequently want to delegate specific tasks to specific users; for example, I'm generally responsible for tagging ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
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
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
no subject
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?
no subject
Individual permissions that could be granted include at least:
Probably "can grant administrator status" gets tied strictly to the current concept of "administrator" rather than being a separate priv.