Dreamwidth Suggestions

Description:
Community moderation queues are one of the unfinished areas of the site that could use some sprucing up.

Currently there is no visible record of which community moderator took action in the moderation queue, nor exactly what that action was.

Keeping a record of the moderation queue from the beginning of time could conceivably take up a hefty chunk of space, especially in high-volume communities. Instead of keeping the records indefinitely, we could log them as they happened, and show up to a certain number of them (I suggest 200, as that is double the size of a paid community's maximum queue depth). Or, if hanging onto them indefinitely would not be a strain, they should be paginated maybe at 100 records at a time. They would be displayed on a special page that can be accessed only by users who have the right to see the moderation queue.

(While community moderators can see the moderation queue, administrators can grant themselves the right to moderate, and should probably be able to see the page whether or not they currently have that attribute turned on. Please do submit scenarios where an administrator should not be able to visit that page in the comments, if you can think of any, because I can't -- at least not until admin rights can be granted piece-by-piece, in which case we'll probably have owners by then, and owners should then be able to visit it without explicitly turning anything on.)

The page should log the following:

Username of submitter
Timestamp of submission
Title of submission
Escaped (plain-text with all HTML symbols displayed) version of first X characters of submission
Username of moderator
Action (disposition of submission)
Note (if any)
Timestamp of action
Link to entry (if posted)

It should log approval, rejection, and reject-as-spam.

It should display (by default) in the order of action, with newest actions on top, but it would be awesome if the page could be sorted by some of the other fields. Records would remain visible until pushed out of the active area.

This would be useful for community management tasks. Moderators could spend less time on communicating basic details to each other and more time talking about other community management needs. It would be easy to look up recent actions of other moderators even if they did not mention the incident. In case of problems on a moderation team, for example if moderators were taking actions by accident, by a mistaken understanding of the community policies, or out of malice, their actions would be visible to others and they could be spoken with based on a record of their actual actions rather than one person's word against another's.

Description:
Sometimes community administration requires staying on top of some issue or other, and sometimes that issue involves a poll. Sometimes vigorous refreshing of the poll votes page is just not efficient.

An all-poll subscription would mirror the all-comments subscription, and allow the administrator to get a more clear picture of activity in the community, albeit possibly a very high-volume one.

All administrator-created polls would likely be a little more difficult to implement, and might not catch older polls created by administrators, or polls created by people who were admins at the time but who are not now, but could be useful for situations where multiple people need to monitor the poll, but only one person can post it, or when a new administrator takes over but would like to continue using the previous admin's poll.

Specific polls would let the administrator pick and choose which polls are important to monitor. This might be easier to implement than an all-administrator-created-polls subscription, and serve many of the same important functions.

Description:
This tool would take inputs of single or multiple invite codes, probably on separate lines rather than a comma-separated list, and show which ones are still good.

Why? Because when you're helping assist in dw_codesharing, occasionally there will be entries with a lot of codes, and you want to test which ones work and which do not. The actual create page is rate limited, as it very sensibly should be.

To prevent abuse, this should only be available through granting privs, and should only display whether or not the code is good/unused, rather than showing more details such as the journal the code originates from, the username of the journal that claimed the code, and other things -- they would be useful to someone at a site owner level, but they're not needed at a dw_codesharing admin level.

For bonus shiny, the output could include a section with the working codes stuffed into a https://www.dreamwidth.org/create?code= link, for easy copying and pasting.