Every once in a while, someone raises a stink about how their WordPress plugin or theme got a bad review or comment on the forums and how the mods should delete it.
We rarely do.(We have, on occasion, done so, but usually only under sever provocation, and often that ends with the developers making the demands being blocked for being jerks.)
The issue at heart is not ‘OMG! Someone hates my plugin!’ but how do you handle the negative remarks. I mention this in passing (multiple times) in my ‘How to Support Plugins’ presentation, but text is really a terrible medium to communicate. You know there’s a difference between these two sentences:
“I want a unicorn,” she said, bubbling with delight and hope.
and
She jabbed a finger in my direction. “I want a unicorn!” Her voice pitched in a low, guttural, growl.
But the reason you know that the first one is nice and the second a little threatening is the context. Prose lends itself to this quite well, because authors take the time to explain what’s being felt and evoked. A help ticket, on the other hand, is pretty dry and plain stuff. And because we’re humans, we attempt to put meaning into the words, often ones the author never intended. We’re programed to look for the meaning, hidden or otherwise, and we always interperate based on our mood and our situations.
This means when you see a ‘complaint’ like this, you have a reaction:
Ipstenu’s Really Awesome Plugin has a security hole. If you go to
/wp-content/plugins/really-awesome/readem.php?=../../../wp-config.phpthen you can totally read the contents of your wp-config!
Obviously as a developer my first reaction should not be to yell at this user and remind them to email me about my plugin.(Protip, developers, always put your email or a contact link in your plugin! If they can’t find you, then you don’t get to bitch they didn’t contact you. At the very least, put it in your source code.) And even though people should email plugins@wordpress.org they don’t always know that, and it’s okay. You can’t know what you don’t know, after all. No, my first reaction, as a dev, is to plug the hole! It’s that obvious. Fix the problem, push a new version, and then come back to the post and reply:
Wow, thank you for letting me know. I’ve fixed that and released a new version. If you find things like this again, please email me at ipstenu@….. Again, thank you for reporting this.
Then in my plugin, you’ll see a credit in the changelog and/or the version history:
Version 2.0 – Security update thanks to RandomUser. readem.php let you read any php file on your install. Please upgrade ASAP.
That’s it.
The idea isn’t to hide any mistakes I make, or act out of fear and desperation, but to take a hold of the problem, resolve it, and move forward. Check out WPSecureNet and their list of plugins. Normally they’ll only post when an exploit is closed, but sometimes they report while vulnerable. There’s no shame in being listed there, unless you haven’t patched your plugin yet, and realisticly there’s no shame in being listed anywhere as having a bug.
Look, bugs happen. We can wish we’d never stub our toes, but we will. We can wish we’d never stab our toes, but someone will find a way to do that too. Humans are imperfect. We make mistakes, we don’t see things that are ‘obvious’ and it happens. Consider the number of books you get when typos: that’s after an author, an editor, and a test reader has proofed the book. With most code, you have fewer eyes than a book, and bugs still slip in. Clearly it’s going to be impossible to prevent any and all bugs, and once we accept that, then we can move on to taking these moments as less painful.
It is painful to get a security report, or even a bug report. Even if this is ‘just’ a hobby, you’ve spent hours of your free time banging away, trying to make something awesome, and now you found out it just wasn’t. No matter how experienced you are, you take this personally, even for just a split second. Getting over that hurdle, that fear that everything is ruined, isn’t easy. And this is why I keep saying that you shouldn’t worry as much about the bugs as how you handle them.
Your users, be they just the folks who use the plugin or people who pay you, will follow your lead. If you’re calm, collected, and honest, then they’ll value you and your product. They’ll appreciate you and what you can do. By taking the negatives and turning them positive (sorry, that’s cheesy) you will improve your relationship with users, clients, and the community.
But what about those angry ‘You suck!’ posts? Oh, they happen, and with a bit more frequency than we’d all like. Often people like to lump them with those posts where people complain about your plugin, only to have the wrong plugin… Look. The way you handle those negative people is the way you will set the tone for your entire online life. You can react aggressively, or you can handle it calmly and rationally. Personally, when I see someone rage on about how the original poster is a moron, and they don’t know what they’re talking about, I put them on my blacklist. I will never again use their plugins or themes or any code, if I can help it. I’ll sooner fork it than anything else, because the best way I can vote is with my feet.
What about you? How do you handle the angry unicorn lovers? And what do you do when the devs go postal on you?
It’s in beta, don’t nobody panic.
That sort of report is often called a ‘Shrug Report.’ Something you normally get with the words ‘It doesn’t work.’ It’s useless information that doesn’t help anyone debug. It just means we have to ask more questions and pester you, when you’re already clearly annoyed. In your inability to state what the issue is and what you’ve done, you make it harder for yourself.
Don’t say nothing. Something changed. Something happened. While yes, anything can ‘just break’ it’s not that common, so take the time to review. When was the last time you tried to do this? If, using our previous example, you last added a user in January, what’s changed since then? A lot, right? Well, we actually need to know what all changed. And when, that would be nice. In order to know what changed, you have to keep track of everything that changes, and when it happened. It’s work, I know, but you should make sure to add in “This is the first time since January I’ve tried to add a user, and since then, I’ve upgraded X component, add in feature Z, and removed function A.” Remember our Hecht! (Herbert Hecht wrote, in 
Writing code is rarely an act of support.
When you tell someone that something is ‘wrong’ there’s a reason you may get push-back like ‘Well what would you like it to do?’ or even ‘Why do you want to do that?’ It’s clear you have had that moment of clairvoyance where you can see a perfect future, and we want to see it too! That will help us either follow your vision and make it happen, or tell you that’s not going to happen right now. Your ‘bug report’ helps create better things.
I want to reiterate this, since apparently I can’t say it enough, 
This made the 3.2.1 upgrade really fast for everyone. If you look at the 
But what about when it’s your plugin plus someone else’s theme plus the new version of WordPress? Now it’s harder, because you get an IDIC epidemic(That is possibly my favorite Star Trek novel, by the way.) with WordPress. IDIC is a Star Trek concept. The Vulcans believed in “Infinite Diversity in Infinite Combinations” which I think is a perfect way to explain the problem.
A lot of the time, we complain “Don’t people look in the forums before they ask a question?” Sometimes we kvetch that these people are ignorant or lazy, and many times they are. But while a lot of questions are repeated, it’s really not as cut and dried as it may seem.
Okay, maybe it’s a hair splitting, but when you say “I want my code to do THIS and instead it does THAT.” you will often see yourself using very non-technical terms. First and foremost, that’s okay. In fact, I encourage people to use the terms they’re familiar with, that will make it easier to get help. But you need to know what you’re asking for, and that’s a problem.