Dreamwidth Suggestions

Description:
Currently, tag permissions are:

Who may see the tag (determined by security level of the entries to which the tag is attached)
Who may add any existing tag to an entry
Who may remove a tag from an entry & who may create new tags to apply to an entry

Adding, removing, and creating tag permissions can be based on community membership or community adminship, or personal journal general access/access group membership.

This is useful as far as it goes. However, tags as they are actually used have developed some other interesting differences.

In some communities, there are often special tags that are reserved for marking administrative actions. Using dw_suggestions as an example, there are several. http://dw-suggestions.dreamwidth.org/tag/

"admin" and "admin: opinion post" are clearly administrative. All of the "bugzilla:" tags are also administrative, and are used one at a time by denise at various points in the suggestions process for very specific purposes. The rest of the tags are descriptive of the content of the suggestion, and can be usefully applied by any interested layperson with attention to detail.

Other communities do similar things with tags, and make things work by either restricting the application of tags to administrators, or trusting the sensibility and goodwill of the community to not apply tags that are clearly designated as administrative with reckless abandon.

To fit this need roughly and based on the use model I described above, tags could be divided into two baskets, one reserved for admins/journal owners, and one that uses the existing settings. However, that doesn't quite satisfy me.

What if it were possible to:

* Set default permissions for newly created tags (tags that already existed at the time of swapover would go with the current account settings for global tag permissions)
* (unchanged) Set permissions for who may create new tags
* Set permissions for who may apply this particular tag to any entry
* Set permissions for who may remove this particular tag from any entry

It should be possible to modify individual tag permissions either singly or in multiple selected groups, and should be possible to sort the tag listing based on permissions.

I defer to people with better UI experience than I have on how that should be accomplished, because it would add an extra layer of WTFery on top of an already complex interface.

When applying tags to an entry, a user should only have the tags that they are allowed to apply be in a list that can be selected from. This would add possibly significant processing overhead to every load of a tagging page, and could be a reason to restrict some of the fancy stuff to paid accounts/accounts that have under the legal limit of tags. (This would prevent me in particular from using this until I got my tags pared down, which I think is only fair.)

I can see arguments for and against displaying a second list of tags that exist and are visible to the current user, but cannot be applied by them.

For: they exist, it makes sense to show them so they know that the problem is not that the tag does not exist; the refrain of "Mods, can you [tag request]?" is familiar in communities with restricted tagging. Having the list on the page to modify an entry's tags saves a click.
Against: why show you something you can't use? Link the full tag list if need be.

The ability to specifically designate a tag as "can be applied by [more permissive group than community admins]" might also solve the problem where admins create tags but don't attach them to an entry, so the tags remain admin-viewable-only until they're used.

Description:
One challenge for community administrators is sometimes keeping track of various activities in their community. Different community populations require different levels of admin attention, and sometimes an administrator does not realize they need to know about a specific action in their community until something happens and they're left trying to sort out what exactly happened and who they need to talk to.

These are all community actions that currently leave little trace in the system, but can be crucial to sorting out what happened and why.

Entry deletion -- some communities ask that their members not delete their entries. Some communities ask that only one specific administrator delete any entries. Sometimes, as in the case of communities like dw_suggestions, a deleted entry means administrative work to track down the entry and reconcile the public-entry-to-private-admin-entry counts. Entry deletion should log the username of the entry owner, the server time the entry was initially posted to the community, the entry's subject and first ~100 characters (raw), the time of entry deletion, the username of the party who deleted the entry (and possibly their position: self or admin), and whether the entry was marked as spam.

Comment deletion -- some communities ask that comments with problems be left in place for an administrator to handle. Sometimes it is accepted for the person who left the comment to think better of what they said and delete their comment, but it is frowned upon for the entry poster to delete a comment even though they have the power to do so. Comment deletion should log the username of the comment owner, the subject and first ~100 characters, the server time the comment was initially posted, the entry (and thread, if applicable) in which the comment was posted, the username of the party who deleted the comment (and possibly their position: self, entry poster, admin), the time of the comment's deletion, and whether the comment was marked as spam.

Comment screening/unscreening, freezing/unfreezing -- I have seen entry poster vs. community administrator freezing and screening wars before, and they are not pretty. I did not know that I would want this logged until it happened to me. This should log the username of the comment owner, the subject & first ~100 characters, the server time the comment was initially posted, a link to the comment & thread (because sometimes you want to go straight there, sometimes you want the whole thread, possibly the direct parent too), what the action was, and the username of the person who did it (and possibly their position: entry poster or admin).

Entry editing -- I'm less concerned with editing of the entry text in this context as I am with things like editing to turn off comments, or that it would be really nice to log when community admins bump the NSFW setting or security. But other community admins may have different concerns. This should probably log the username of the entry poster, title & first ~100, server time of post, server time of edit, who edited it (and possibly position: entry poster or admin), and the attributes that were edited. Subject edits could probably display old subject & new subject. Body edits could display ... net change in character count? (Other community admins, please weigh in on what would be useful.) Entry attributes should display old value & new value if there was a change.

Tag editing -- this could be useful for mistaken tagging or tag vandalism, like if someone accidentally detags an entry, or selects all tags for an entry and saves it. Log should include information to identify the entry (username, server time of posting, subject & first ~100, link), the old tags, the new tags, and the username & position (non-member, member, entry poster, admin), and server time of change.

I'm not sure that comment editing needs to be logged, because there already exist notifications that can be emailed, admins from paid communities can subscribe to all comments (including all edits), and people edit comments a lot (and it could clog up the logs).

Anything else?

Description:
Community moderators may currently receive notifications for new submissions to their community's moderation queue.

It would also be useful for them to get notifications about moderation queue action, possibly from themselves, but definitely from other moderators.

The notification should include:

The username of the moderator who made the action, what the action was, what community this is in, the username of the user whose submission it was, the time the submission entered the queue and the time the action was made, the note (if any) the moderator left, the entry's title, contents, and possibly other relevant metadata (tags, location, mood); if this action was an approval, a link to the entry as posted.

(Should this be sent for items that are marked as spam? I can think of arguments in both directions: against: in case of legitimate spam it is useless overhead that will only bother the other moderators, emailing known spam may alarm email providers; for: if a moderator is marking things as spam that are not spam (either accidentally, mistakenly, or maliciously) the others should know, moderators who become accustomed to messages about queue action may be surprised when they see an entry come in but find it gone with no notification about why.)

This notification should only be available to people with access to see the moderation queue, which in practice is only moderators, but in terms of practical community oversight might need to include the community administrators.

The subscription should be separate for every community, and should (if possible for business reasons) not count against the subscription slot limit.

(Related: an on-site moderation queue log.)

Description:
Currently, when you load a page like http://www.dreamwidth.org/manage/tags you get a list of communities you can manage (if you administrate any) as well as your own journal, but you have to remember to click the "Switch" button to make it happen. I have more than once made changes for the wrong place and then been frustrated because I forgot to click that button (and I would consider myself a power user).

Also, if you're done working with your community and you want to go back there to see how it looks, sometimes there isn't a quick link.

Adding a "currently working as" notice would serve as a notice that maybe you need to click the button, a reassurance that you really are working on the right community, and a link to go back and check things out. It would probably save a lot of time and just look nicer.