Archive for September, 2011
Blog Post Roundup
There were a few blog posts last month that are particularly applicable to site moderation, so for those who haven’t seen them, here is September’s suggested reading list.
The suggested edits feature made community wikis rarely (if ever) needed. This blog post outlines when (and when NOT) to make questions community wiki.
Hint: If you’ve checked that “convert to wiki” button recently, you’re probably doing it wrong.
When tagging a question, descriptive tag excerpts now pop up as part of the tag completion. But for this to work, you need good tag wiki excerpts. Tag excerpts shouldn’t just define generic terms, they should educate users about when to use those tags!
“Gorilla vs. Shark” is about a subtle type of poll which appears far too often: the “which is better?” post. When users asks for “this v. that” comparisons, they rarely detail what problem they are actually trying to solve. Answers can only be a rough guess of what information would actually be helpful. “This v. that” questions would be better expressed as examinations of the underlying concepts without all the mock conflict.
Flags Too Often Marked [declined]
Marking a flag
[declined] was designed to deter serial abusers of the flagging system, but we find that this “slap on the wrist” is being used more often than is beneficial.
Flags should be closed as
[helpful] under most circumstances. If you feel strongly that a question was flagged in bad faith, it is okay to mark it
[declined]. But try to err on the side of clearing as
[helpful] whenever the user is trying to be genuinely helpful, even if you do not necessarily act on the flag.
Users are asked to flag posts to help keep the city street clean. Even if you feel the flag was not technically correct, you don’t want to continually send the message that their help is no longer wanted. That is not what the feature is about.
We clarified the guidance for when to dismiss a flags as
dismiss flag on this post as…
[helpful] the flags have merit but no further action is required
[declined] the flags are unhelpful or noise
Super-Ping to Reach Individual Users
The regular @ chat alerts only notify someone if they’ve been in the chat room in the last day or so (see chat notifications help). But did you know moderators can use a special @@ notification to contact anyone on your site, even if they have never been in the chat room? Moderators can use the @@ super-ping that will always put a notification in the user’s inbox. The syntax is
@@<user id on site>@site.stackexchange.com
So, for example, typing:
would generate an inbox notification to me, even if I’ve never been in that chat room.
With a nod to the famous Seinfeld sketch, users are no longer limited to two login credentials (OpenIDs, OAuth, etc), but can have as many as they need. In addition, logins are now stored at the network level (not per site).
This means a few changes to the moderator interface. To view a user’s credentials, use the “my logins” link next to the edit button on user profiles. Also, merging accounts now includes additional protections because the merge applies to every site network-wide. If a candidate has +2000 rep on any site, the merge requires developer approval. The additional notifications will all happen automatically.
For further discussions about multiple logins, this is a good opportunity to plug the weekly SE podcasts (SE Podcast #16, starting at 5:20).
That’s all I have for now. See you next month!