Best Practices - Dealing with Problem Users on Your Drupal Site

One of my goals for this group is to offer best practices beyond the technical Drupal information. After getting Drupal up and running as something more than a brochureware site, everyone will run into issues managing an active online community. It's difficult to balance letting users communicate freely and protecting your organization's brand. The more control you give users the more staff time you can potentially free up, but more problems your users have the potential to cause. Those problems can quickly suck up any time you've saved.

By sharing best practices around community management, licensing, etc., I'm hoping we can save time by learning from what has worked and hasn't worked at other stations.

One of the issues that comes up running any website where users are encouraged to offer feedback and interact is eventually they do. At some point every active community encounters a troll. It is really amazing how much staff time a single problem user can suck up. The first response is usually trying to post logical responses, but this is the very type of attention most trolls are looking for so they just keep posting. Eventually you'll come to the conclusion that this person will never by happy no matter what you do and that the best course of action is to ignore the posts. When the troll stops getting attention, they will often escalate to attacks and posting derogatory comments about your staff and station often as an anonymous user.

Once a relationship with a user reaches this level, it's time for the Troll module. I wrote a patch for Troll to be able to show the blocked IP a message about why they are being blocked, how long the block will last, and include the Code of Conduct they've violated to get blocked. This was the best option we could come up with to adhere to our commitment to inform users in writing when they've been blocked. When we have a problem with an authenticated user we have an email address and often a phone number and mailing address, but the only method we have for communicating with anonymous users is displaying information when that IP address tries to access the website.

Since trolls aren't unique to public access, there are several modules that build on Troll's functionality including Cave and Misery. Cave hides user posts from other users so the user thinks they harassing you, but no one else see it. That works fine unless the caved user checks the site from a coffee shop and sees a different version of the site sans their comments. The downside to Cave is while a troll doesn't mind wasting your time, they tend to go ballistic when they realize they've wasted yours. Misery takes a different approach and simply makes your site work poorly for specific IP address. The hope being that after seeing errors, slow load times, and/or being sent to random pages when clicking links the user would decide to stop participating.

We're not using Cave or Misery on DOM, but we may consider those in the future if adding temporary blocks with the modified Troll module doesn't work.