Azure Jane Lunatic (azurelunatic) wrote,
Azure Jane Lunatic

What I Do in Suggestions, a primer

This is cleaned up a little and elaborated upon some from an IRC discussion of what I do in Suggestions. Support, feel free to ask plenty of questions. This is, er, long.

Comment moderation

The most visible bit of what I do for Suggestions is enabled by the magic subscription (not available for the general population at this time). I read and review all comments to every suggestions entry ever. This means that my LJ inbox and personal email are deluged with every comment to suggestions ever. I review them all as soon as I can after they are posted.

I ensure that there is nothing that is a flame that needs to be addressed, is an issue that a staff member needs to address, or looks like it is headed to flame city. If it is any of these, I address it as fast as possible. coffeechica and marta are the two staff members who I usually tackle in IRC.

If there is a technical support issue, I either address it myself if it's quick and I know it, throw them at the FAQ(s) in question, or send them supportwards if I don't have the answer off the top of my head. If there is a misunderstanding, I endeavor to correct it.

If there is something that I don't think is clear, I try to probe it out of them, and clarify what they mean. If there's a suggestion that's just wrong in all ways, I still (when I have the time to) try to identify the underlying sociotechnical need into a form that others can understand. If I'm capable of doing so, I suggest an alternate implementation that is more in line with the LJ gestalt.

If there are two viewpoints that are mutually irreconcilable, I try to clarify both of the viewpoints as much as I can so that as many people as possible can see both sides of the issue, hopefully including both parties to the argument. People who have been around a lot learn from the process, and help out and are better able to state what they are thinking with practice.

Sometimes, if I am operating at a delay, someone else may have addressed a comments issue that needed addressing before me, in which case yay.

People will discuss related topics in suggestions. When I know that something does not already have a suggestion of its own, I encourage discussion of the issue to the point where it's nearly ready, and then suggest that this deserves a top-level suggestion of its own (then I try and link to it when it comes through).

People will discuss unrelated topics too. I don't interfere with this too much unless it's drifting way off topic and/or threatening to take over the suggestion, but some of that stuff can wind up getting screened after the conversation's over, like, in a year or two.

Suggestions Organization

I create links between related suggestions, particularly when someone suggests in comments something that's already come up as a top-level entry. When suggestions are implemented, I update that suggestion's tags, and link to the release notes when possible, or the FAQ.

When I am aware that a suggestion has been entered into Jira, I update that suggestion's tags, including the bug number in the comments, and leave a comment to Jira including a link to the suggestion. This helps for tracking implementation. Right now the suggestions -> implementation path is all kinds of unclear, and will need hashing out and documentation. Right now basically the link between suggestions and post-suggestion implementation notation is me recognizing a suggestion in release notes and scrambling to find it. This is not a good long-term solution. :D

There are a number of tags. Tags are due a shaking-down, so I'm not going to go into all of them. However, you've got topic-tags, which describe the area of the site or the task that is being discussed, and status tags, which show what part of the suggestions process the thing is in. Status tags are indicated with the special character '§'. Administrative posts are tagged starting with the '∞' character. Tags starting with '~' are tags that have been deprecated and furthermore involve a to-do process.

All new entries are tagged '§ no status' to start their journey through the lands of status tagging.

Some of the new ones are '§ withdrawn' and '§ duplicate'. In '§ withdrawn', after the user has heard the community feedback, they have decided that they really don't want the suggestion implemented after all. The 'duplicate' tag is used in favor of 'rejected' for when two approved suggestions accidentally duplicate each other. Someone with tagging permissions examines both (all) suggestions, and decides which one should remain. The tags on the suggestion to remain are not changed, but links are made in the comments to this entry that there are duplicate issues. The duplicate issue(s) have their status tag changed to '§ duplicate', and are linked in the comments to the remaining suggestion.

The Suggestions Queue

People submit stuff. Once stuff is submitted, the moderators review the submission. There are a number of different classifications. Everything except spam gets a rejection note. There is an array of pre-written rejections in the administrative community. I have some more tailored ones on my main machine in a Clippings file.

First, your stuff that doesn't belong in the queue no way nohow! Russian, which goes to lj_ru_support. Outright spam (rare). Things That Just Don't Make Any Kind of Sense Even Though They Are Using English Words. Things that are completely unrelated to Suggestions.

Things that are clearly support issues/bugs are sent to Support.
Things that are Feedback are sent to Feedback. In the case of certain Feedback-seeking questions, the question can be answered, but with a directive to contact Feedback if further information/clarification is necessary. In these cases, it may be advisable to sign including one's volunteer status.
Things that already exist are sent to the FAQ, often with a directive to contact Support for further information if the pointer to the FAQ did not answer all questions.

There are also things that belong to suggestions but are presented incorrectly. Some don't use the required template. Some have a really inappropriate userpic.
There are duplicates. There are a lot of duplicates. A duplicate addresses the same need, with the same or a very similar implementation. Often enough a new duplicate will not suggest an implementation, but the existing entry will.

Any duplicate within the last X years, where X is currently 3, is rejected and pointed to the duplicate entry to read the discussion and add to it if they wish.
Any duplicate of a historical or historical rejected submission must reference the old one and address issues brought up in the comments, to avoid rehashing old ground.
Features/changes that we know are already planned depend on the situation. If it has been publicly announced, it can be rejected with a pointer to the public announcement. If it is planned but knowledge of this plan is privileged information, the suggestion can be approved and left for discussion. If you do not know which this is, or the situation is ambiguous, check with staff.
When there are multiple suggestions addressing the same need or for the same thing in the queue, it serves everyone best to have the best-worded and most thoroughly thought-out suggestion posted. In these cases I will approve the best suggestion first, and then reject the others with a pointer to the one that was approved. I call the rejection note I use for this the "great minds think alike" note.
Any suggestion containing private information from the user will be rejected.
Some potential suggestions in the moderation queue will be taken particularly poorly by suggestions participants as a whole. Carefully weigh the user's desire to improve the service with the likely reaction. In some cases these suggestions are duplicates in any case, or have other flaws that would prevent them from being approved. In some cases it is best to explain what about the presentation of the suggestion that should be changed and ask for it to be re-submitted.
In some cases it is necessary to discuss the contents of the suggestions queue with other Support team members. Sometimes it is necessary to ask an expert whether the user's understanding of a feature is technically correct to determine whether their issue is a suggestion or a bug. Sometimes it is necessary to determine whether a user has an existing Support history. The contents of the moderation queue are not public information, and should be treated with the same sort of care as a private Support category.

When there's a near-duplicate that is approved, I link to it back and forth and explain why they differ.
There are suggestions that I know will be received poorly, from prior experience with the habits of the community watchers in general. When approving a suggestion with things that I know the whole crowd is going to pounce on, I will marshal all the stuff I have straight off before approval, and try for the first comment on it, addressing the issues tactfully. This tends to result in me collecting "+1" comments, and the original poster not getting quite such a harsh reaction from the usual participants.

Suggestions tend to come out on weekdays during US work hours, more or less. This isn't a rule, but a convention, to maximize the participation. Suggestions are also conventionally released in order of their entrance into the moderation queue, to reduce confusion and reduce later sorting problems in the community. (If there is a reason to wait on a particular suggestion's release, a note is generally made in the administrative community.) Suggestions are rarely released in batches larger than 12, to avoid flooding the friends pages of the community's watchers.

Administrative Community

There is an administrative community for the administration of suggestions.

Communication for other maintainers/moderators is left there, including notes on the queue and items in the queue.
Comment/community moderation notes, including documentation of banning, even for spammers.
Meta-commentary and planned changes, if any.
Drafts for anything that needs drafting.

What Other People Can Do To Help

Participate! suggestions doesn't generally need too much help getting people involved and engaged, but if you see a lonely-looking suggestion that has no comments, see if there's something you can say about it, whether it's supportive or constructively critical.

Check for implementation! If something has since been implemented and you happen to see it, point that out, including pointing out the FAQ(s) explaining how to use the kickass change, which will prompt me to update the status.

View suggestions in their best possible light. Many suggestions are awesome to start with and need no extra help. Some suggestions need a lot of refining before they would be able to be considered. Rather than responding with an immediate 'no', consider the underlying need that the suggestion demonstrates. Consider the circumstances under which you would be willing to have the suggestion around. Consider whether you would mind having the suggestion implemented if developer time were not a finite resource.

Address the concept, not the person bringing it up, if it's something you don't like. If you know you have a poor history with a particular other commenter, avoid engaging with them if you can.

If you can write the code to make something happen, that would be pretty nifty. That was one of the things that made suggestions great in the old days. It still has to be reviewed, and may not be adopted, but there may well be a better chance if the code's already done.

If you see a tag that should exist, or a tag that does exist that isn't on a particular post but should be, let me know.

For people with Jira access, if there's something that should be in Jira and is, commenting with the bug number would be Helpful. If it should be in there and isn't, if you can add it, commenting with the bug number would be Helpful. (You may also find it useful to cross-link the suggestion from the Jira entry, so when it's implemented it'll be easier to track down the suggestion to mark it implemented.)

Comments for this post were disabled by the author