Draft specification: more granular community permissions

[kaberett]

This outline is based on previous discussion about how this might work. Currently the best option seems to be a pretty unwieldy matrix: if you've got further suggestions please do let me know. Because it's unwieldy, the rest of this is going under a cut.

THE CURRENT SITUATION

Community permissions are scattered over a number of pages and offer a limited set of options. To here summarise the current situation:

Under ?authas=comm: Profile, Style, Settings, Tags, Tracking

Settings

Membership is: open/moderated/by invitation only
Posting access: anyone (even non-members)/all members/select members
Entry moderation: [ ] All entries must be approved by a moderator before they will be posted to the community.

Tags
Who can create new tags, add tags to entries, and remove tags from entries? Anyone/Members only/Administrators only
Who can add existing tags to entries? Anyone/Members only/Administrators only/Entry author and administrators

Edit Community Members

Community members page
select all  [ ] Member  [ ] Posting Access  [ ] Administrator
username1   [x] Member  [x] Posting Access  [ ] Administrator 
username2   [x] Member  [ ] Posting Access  [ ] Administrator
username3   [x] Member  [x] Posting Access  [x] Administrator
username4   [x] Member  [x] Posting Access  [ ] Administrator

PROPOSED CHANGES

Move all permissions governing how user accounts can interact with the community to the Edit Community Members page. Tweak the Edit Community Members page in two respects:

1. instead of a single row of master tickies as the headline, introduce separate master tickies for members and non-members (support request); and
2. move all permissions governing how user accounts can interact with the community to a new Additional Privs page.

The Edit Community Members page checkbox matrix would then look something like this:

                Member      Posting Access      Moderated       Additional Privs
NON-MEMBERS [-] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
MEMBERS     [x] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username1   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username2   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username3   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username4   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs

Note that it is not possible to make all non-members members of the community (!); I suppose you might want the "remove all members" ticky, so that should be checked by default (rather than greyed out/unavailable as for non-members). The "Additional Privs" checkbox does not autofill anything on the Additional Privileges page; it merely means that the username(s) in question show up there.


The Additional Privileges page would also be a matrix of checkboxes, again with NON-MEMBERS and MEMBERS as the first two rows, with MEMBERS acting as a master influencing all username rows.

The privileges for which checkboxes should exist are (taken from the Community Maintainers wiki page):

... with a matrix where the tickies are:
[ ] ADMINISTRATOR (master ticky, selects all)
[ ] MODERATOR (master ticky, selects appropriate subset)
[ ] add tags to community list
[ ] delete tags from community list
[ ] add tags to community entry
[ ] remove tags from community entry
[ ] edit community style
[ ] edit community memories
[ ] can change comm settings at /manage/settings/?authas=comm
[ ] can change the settings at /manage/profile/
[ ] can un/screen comments
[ ] can un/freeze comments
[ ] can delete comments
[ ] can un/ban users
[ ] can report spammers
[ ] can add/remove posting access to community
[ ] can remove community membership
[ ] can invite people to the community
[ ] can approve requests to join the community
[ ] can manage the moderation queue
[ ] can edit, delete, or flag posts made to the community
[ ] can upload userpics for the community
[ ] can wear the mod hat
[ ] can access community's recent_comments.bml page
[ ] can add other owners
[ ] can remove other owners
[ ] can add people to groups on Manage Community Members
[ ] can remove people from groups on Manage Community Members
[ ] can add people to groups on Additional Privs page
[ ] can remove people from groups on Additional Privs page

Points for discussion

1. This is going to be enormous. Suggestions for how to minimise scrolling?
   
2. It is possible to duplicate settings between the various pages mentioned in section 1 and the proposed new privs management interface; however, I suggest that's prone to error and confusion and might therefore be better off not happening.
   
3. I'm not convinced that we actually want the last two tickies on my big list there; I'm not convinced there's any point in letting people who aren't administrators have the ability to grant and revoke administrator status :-p
   
4. Are there privileges missing off that list that you can think of? Are there points you think should be subdivided? (I am thinking particularly of edit/delete/flag posts made to the community, and un/screening comments: I can see a scenario in which you want people to be able to screen comments until someone with more seniority comes along and drafts a response and only then unscreens it, to minimise flamewars; ditto un/freezing.
   
5. Terminology: "Additional Privs" is a placeholder; suggestions for something clearer/more user-friendly enthusiastically welcomed.

Comments

[azurelunatic]

My first reaction is an excessively nitpicky visual/spatial thing, in that I would want some small but noticeable separation for non-members, but I think the top placement works well.

[denise]

Rather than "should we subdivide any of those", I think we can probably compress some of those additional privs so it is less WALL OF OPTIONS:

-- add tags to community list/delete tags from community list
-- add tags to community entry/remove tags from community entry
-- can change comm settings at /manage/settings/?authas=comm/can change the settings at /manage/profile/ (as just "can change comm settings"); maybe also "can change/customize style" belongs in here
-- can un/screen comments/can un/freeze comments/can delete comments/can report spammers/can access community's recent_comments.bml page (as "can manage comments")
-- can remove community membership/can invite people to the community (and possibly a few other consolidations there, I'm not sure)
-- all the "can add"/"can remove" at the bottom should be "can add/remove"

I'd much, much rather do this as broader categories of permissions and only break them down later if people request it.

[azurelunatic]

Freeze/screen/delete arms races are great fun! I will always propose logging of various community admin actions, viewable by owner & admins, as a technical umbrella which can be used to support accountability amongst the people who are let to do the thing.

[metawidget]

What happens to individual members' tick boxes when I start ticking and un-ticking 'MEMBERS' tick-boxes? Should all member tick-boxes get ticked when I tick them? Should members get granted whatever I specifically gave them plus general member privileges (and next time I open the screen, should this union of privileges be reflected, or should it always happen in the background)? Should MEMBERS just be a template for future members when they are added, and not affect current members at all?

[swaldman]

Please take everything I say with a pinch of salt, as I've never been a community mod and thus never used any of this. re the five points:

1. The additional privs page will be enormous if there are a lot of users with additional privs. Do comms give lots of people these privs? If so, it may be sensible to paginate it? How feasible to provide a search box (for username) at the top? Rah's contractions to reduce the number of columns make sense. I don't see another way to make it smaller without implementing a full-on roles system - which would be much more work and is probably overkill.

2. Please please please no duplicate settings. And yes, all the related settings should be in the same place.

5. "Administrative privs"? Because that's what they are, really. Might cause confusion versus who is named as an admin, though.

[metawidget]

I know this isn't one of the stated questions exactly, but what about allowing admins to create privilege groups and then assigning members and privileges to them? It would crack the huge matrix problem.

Every community would need a non-empty Admins sort of group with all the privileges and automatic membership in every other group, a Members group which contains all the members and a non-members group which contains the rest of Dreamwidth implicitly. Members could then be added to Admin or some custom group (e.g. a group that can screen comments and approve members or one that can adjust tags) You'd need a couple more privileges:

- Create community privilege group / change privileges
- Add someone to a group you are in (Admins are in everything, so they can seed new groups)

The interface could then be very much like filters, but with a long list of privileges (maybe even grouped, so that an admin could, for example, give a group all tag-related privileges or drill down for specific ones) in addition to the list of users.

This would be nice because it's relatively compact and because once the community admin describes a role, they can just assign users to it rather than click the same tick box pattern for each user doing that job.

[ninetydegrees]

I don't quite understand what the workflow/pages would be like so all I can say is that I wish admin privs were sorted into categories (tags, moderation, community control, etc.) so it'd be easier to find the priv you wanna edit.
Also +1 to the search username box.

[neighfeni]

Apologies for the character account, my phone browser is being a nitwit and won't switch.

I'm not an Admin of a game, but I am the main one for a few comms, and I can't see any point to non-admins having Admin privileges. If the comm has several types of admins (head, helpers, list, whatever), then different privilege levels there makes sense. But I don't see any reason to have the option for non-admins to get Admin privileges. It's too easy to abuse.

~lil_rebbitzen

[silveradept]

Late to the party, but:

Would it be less scrolly if the categories for each group of powers (tags, entries, etc.) had their own page? So instead of a big list composed of all the people and all the possible powers, instead the "member privileges" page first lands on "moderator/administrator/excluded" statuses, with navigation to sections (in supergroups that are the actual page names that make sense in my head but that I can't actually articulate) based on "entries", "tags", "style", "memories", where someone can set individuals to have our not have permissions?

What I'm curious about is how to avoid being in the middle of the grid and accidentally giving the wrong privileges to the wrong person because we couldn't remember what columns did what and which users are on which rows.