Bug reporting and sociopath developers
Bug reporting reminds me a bit of customer service interactions. They can be easy matters where everyone knows their role in the process and does their fair share of the work, or it can be a lopsided affair with a whole lot of hissing and spitting. You might think I'm going to single out open source, but I'm not. This applies to internal corporate projects just the same.
Here's a bug report to consider. The title was something like "random crashes", and the body was approximately "The program crashed several times". That's the whole report. Imagine you're the developer and you see that pop up in the queue. Where do you even begin? You have a number of options now.
You could punt the report back as "insufficient data". I've seen places which set up an internal document or wiki page with a whole manifesto on "how to report bugs properly". Sometimes people set up shortcut links to these things, and while some of them might be "go/moreinfo", others might be downright hostile.
Let's say the program in question accesses a server, and you have access to those logs. Maybe it keeps track of every request, and you can filter it down to the ones which failed. Then you can correlate those failures with the time when the bug report was filed. Perhaps you have some kind of magic which lets you see the reporter's IP address, and you can see the same value in the logs.
At this point, you probably could dig in and try to figure it out from those log entries. The assumption here is that they are actually related to this bug and aren't coming from something else entirely. If you get lucky, you might be able to resolve this all without going back to the original requester for additional information. If nothing else, that removes a few more round-trips and interactions with this ticket. You still probably should remind them what happens when insufficient data is provided: it takes longer to resolve, and the actual problem might be missed entirely. There might also be a deprioritization penalty applied to "encourage" better behavior if it continues.
When it comes to being a user and reporting problems, I have to admit that I look at past interactions with a given set of developers. By that, I don't just mean my own interactions, but rather how things are handled in general. Many projects have bug trackers which make this rather easy. A few minutes of clicking around can give me a good idea of what will probably happen if I bother to report something.
There are many things which can be learned by reading past interactions. First, how quickly do things happen in there? This applies both to overall bug lifetimes and the general latency within a bug. If there are many bugs which have been open for years, you might not want to make plans involving your request being handled. Likewise, if it takes a week to get responses to any given update, expect it to take a very long time.
Then there's the matter of ability. Who's handling the bugs? Is it a volunteer who has the best of intentions and a lot of heart but not much knowledge? When they do get involved, do they understand what's going on, or is it like pulling teeth to make them see a genuine problem? How hard is it to get the attention of someone who will get it right the first time? Does such an individual even exist? It's possible that nobody like that exists on the team any more.
Worse still, it's possible that nobody like that ever existed on the team. Just because a project exists and sort-of works doesn't mean that anyone understands it, and that includes the creator. If they out-clevered themselves by writing code they can't even maintain later, then you might see this exact situation play out in the bug tracker.
Next, how about attitude? What is the environment like in the bug tracker? Are people generally civil? When it stops being civil (and it will at times, no matter how many rules are in place), who starts it? Who escalates it? Who ignores it? Who redirects things?
If bad attitudes and general hate tends to come from the developer side of things, that might be a cause for alarm, especially if there's no apparent reason for it. If it's an isolated case, perhaps between two specific individuals, that's one thing. But, what if it's a number of distinct bug reporters, and regardless of how they present things, they all get the acidic response from someone on the dev team? To me, that's a red flag.
Part of the attitude question is overall cockiness. When a problem is reported, does someone hop on it and immediately deny it? Do they do this even if the user presented a lengthy case?
Let's say the user is plucky and won't just give up, and they fight to make their point known. Then the cocky developer eventually gives in and patches the code -- in other words, there was a problem, since a patch had to be applied! What happens then? Do they mellow out a bit for next time, or do they stay just as cocky as ever?
I've seen that last one play out in a bunch of bugs which were handled by the same individual. The pattern is generally like this:
---
User reports problem and gives suggestions for ways to fix it.
Developer immediately declares it "impossible".
User comes back with hard data.
Developer asks "is this real or are you just looking for trouble?"
User says it's real and states a use case.
Developer says the user has a crap processor, Internet connection, operating system, hard drive, beryllium sphere, or whatever else might apply.
User says this kind of venom doesn't help and it doesn't matter since it's still a problem.
Developer points at a patch from a recent release.
User says it doesn't fix all of the problems, and their original report is a corner case not handled by that patch.
Developer patches the code and updates the bug with a pointer to it.
User goes away. Satisfied? Happy? Looking for alternatives, perhaps?
---
Notice the developer never says "Oops, I was wrong" or anything of the sort. The bugs tend to just get a notice of a patch being applied and then just go silent. There's never any sort of closure on a human level.
This happens over and over. I'm beginning to think that some people run these projects and maintain bug reporting systems just so they can (try to) play the part of an evil overlord. I bet these are people who would be shunned in the real world for such antisocial behavior, but the computer lets them have an endless supply of fresh victims. These are people who are at the mercy of the developer's delusions of power, and they have no idea what's about to happen.
Look at it this way. If someone at your local market starts treating you like garbage, you can tell a few people on your way out. You can directly influence people who are on their way to possibly deal with that same individual. This doesn't work quite the same way on the web because you probably can't intercept people on their way to the bug tracker. They're going to arrive without any sort of warning of the kind of sociopathic behavior which may lay ahead.
Sure, there are "out of band" venues for reporting such trouble spots like reddit or Hacker News, but they aren't in the direct path of traffic heading to the trouble zone. It's not like you can run a picket line in front of a web site, right?
...
I have a final point to make about this in the form of a thought experiment. Imagine a project with a belligerent dictator running the show. If you already know one, use that. Otherwise, make one up.
Got it? Okay, here we go.
Let's say the program manages to accomplish a few useful things. One day, a particularly talented user downloads a copy and tries to use it. It mostly works, but they run into a problem with it. They look into it and see that a fundamental mistake was made. It's no big deal to fix it, and they do exactly that to their local copy.
Now, this talented user knows about the reputation of the dictator running this project, and decides it's not worth the trouble to report it. Reporting it would be akin to saying "you suck at design" in the eyes of the dictator.
While it's probably true that the dictator does suck at design, the talented user wants no part of the drama which would follow such a report. There is absolutely no benefit to lighting that particular fuse. And so, the problem is never reported, and the patch is never conveyed upstream. It effectively becomes a private fork limited to the talented user's systems.
The real losers here are the ordinary users who are unable to fix this problem themselves. They are at the mercy of the dictator to do something about it, and that's unlikely to happen since it would amount to an admission of ignorance or incompetence. Status quo reigns supreme.
Pretty ugly, isn't it?