This week, I hit a nasty bug in my favorite email client, which just happens to be a fairly popular project from one of the oldest and largest open source development communities.

Actually, I've been facing it for months and just accepting it as the new normal, until I remembered "hey, this is open source! I can just file a bug report."

So, like any dutiful user of open source software, I found the official public-facing issue tracker of the project and filed a detailed bug report, complete with environment specs and steps to reproduce.

The response to my bug report floored me with its abrupt rudeness, implying that somehow the problem was either me or my obviously weird, non-standard operating system (because, seriously, what type of lunatic runs Ubuntu MATE with its default packages and settings?) The problem couldn't possibly be their software.

While I was initially bewildered and hurt by this stinging rebuff, I can see now that I've been doing software wrong my whole career. Clearly, the point is to alienate users and offend people! Just think of all the vapid ego-building opportunities I've missed by trying to write projects for people.

So inspired by these daring pioneers, and so many like them, I've compiled a few tips on how to run your issue tracker in such a way that you'll drive away all those pesky users and contributors, preserving the carefully curated clique your core developers have formed. Sure, a lack of users means your software is a fairly useless blip in the history of computers, not to mention a stain on the reputation of Free and Open Source software everywhere, but it's a small price to pay for that fleeting feeling of being smarter than everyone else.

Of course, if you're one of those weirdos (...like me, actually...) who actually want to build your project's community, and encourage your users to be active in the development of your software, you'll want to invert all these handy tips. (But why would you want that?)

NOTE: Read my "advice" below through a sarcastic lens.

Decentralize Issue Tracking

Naturally, if you can prevent bugs from even being reported in the first place, all the better. The fastest way to do this is to have multiple trackers, each with a special, dedicated purpose, and then bury the user-facing documentation about it (or, you know, just don't write any at all.)

Just imagine your users when they try to figure out which of these they should post on...

• The Slack channel where the developers all actually show up,
• The Discourse forum with a dedicated Bugs section that your team usually ignores,
• The GitHub Issues tracker that no one uses, and you forgot to turn off,
• The Launchpad issue tracker that few even realize exist,
• The ten-year-old Mantis bug tracker you never took down the website link for,
• The shiny, new bug tracker that you set up last year, but which only has a few dozen bugs listed on it.

Naturally, if they guess wrong, you and your developers should condescendingly inform them that they posted on the wrong tracker. Maybe you could tell them to go use a different one (bonus points for giving them the royal runaround with multiple redirections), or just shut them down with a terse "You should know this is not a good place to post bugs."

Above all, never assist them in moving their bug report to the correct platform! Referrals to another platform should be vague and preferably demeaning, and you shouldn't lift a finger to migrate any of the information over. They typed it once, they can do it again. And again.

Or they can just go away, and that's the point, isn't it?

Lots Of Hoops

Even if the user does somehow manage to find the right issue tracker, there are still plenty of opportunities to shut them down.

A favorite of many elitist projects is to create a long list of requirements for what a good bug report should be...and then punish offenders by dismissing the entire report out-of-hand for the slightest omission.

Now, even those nauseating, community-oriented projects have some guidelines for writing good bug reports, but they take the time to outline their expectations with a template or other prompt. When a user doesn't hit all the targets, they politely and gently ask for more information. And naturally, they keep such requirements to a minimum. They ask for such things as...

• Software version and environment details.
• What was expected.
• What happened, and
• Steps to reproduce.

Those are quite reasonable, and therefore insufficient to create fear and loathing in your users. You can obfuscate the process by expecting them to guess exactly what libraries you want the versions of, to include highly technical details that most users cannot understand (make them guess the command for finding their network card firmware version, for example!), or to have otherwise irrelevant information (e.g. compiler version, when bug reporting on a shipped binary).

You can make the process even more painful by asking the bug reporter to perform a number of other "fact-finding" tasks that are far beyond their technical ability. The threat of their bug report being marked "Closed, Insufficient Information" will push them to attempt things they have little hope of succeeding at, like asking a non-developer to perform a comprehensive git bisect to determine what commit number created the bug.

Of course, while any well-meaning project may ask if the user is willing to attempt these tasks with a good deal of guidance, your project can leverage this as an alienation technique simply by expecting the user to already be familiar with these tasks, forcing them to admit they don't know how, and then belittling them for the admission.

It Works On My Machine!

Let's assume your user described their environment perfectly, even including the library versions you wanted. What now?

Naturally, we don't want to waste a perfectly good opportunity to demean our bug reporter! They've just handed us a bunch of ammunition - we can now passive-aggressively mock them for using a system we don't personally spend time with. We can accuse them of tampering with the libraries, installing weird things, changing settings in bizarre ways, or just being too stupid to update things.

Above all, be sure you don't attempt to replicate the bug on the described environment! That might lend legitimacy to the bug report, and leave the user feeling like their efforts were appreciated. Instead, you can infuriate them endlessly by trying to replicate it on a different environment, or even an environment which is similar, but lacking some simple key commonality.

Obviously, it's impossible to replicate every system, but most users won't be expecting you to test yours software on a FreeBSD instance with a custom kernel image and a bunch of packages built from various Git repositories. So, if that's their environment, you're not going to have much luck alienating them on this point; they're probably going to take responsibility for the fact many things won't work right on their computer. If they won't, even the most soft-hearted developer would consider them unreasonable.

But for the majority of users who use major, supported, operating systems with default packages and settings - especially versions of Ubuntu - your refusal to take ten minutes and attempt to replicate the bug will feel like a slap in the face. You're effectively saying: "I cannot be bothered to load the Live image in a virtual machine and install our software. Your experience isn't that important to me."

Now, obviously, you have limited hours, but there's nothing actually stopping you from setting a low-priority task for investigating the bug. Your user probably knows this, so don't be vague about your dismissal. Cite how unreasonable they're being (even though they aren't). Make them feel like insects for even supposing anyone in your team would deign to replicate their environment.

Of course, if you leave the bug open for too long, some other Joe Schmoe will probably come along and confirm it on the environment originally described...or worse yet, on another environment altogether! So make sure you close the bug as "Cannot Replicate" or "WONTFIX" as quickly as possible. That sends a clear message to the rest of the world that you don't care if this bug is real; you just don't want to bother resolving it.

Blame Someone Else

There's another problem here, of course: the history of bugs changing behavior due to environment is vast and well-documented. Sure, you know that the bug reported probably does exist in your code, and it's probably some sort of insidious undefined behavior that's going to blow up in a nasty way someday, but don't let a desire for good code cause you to miss a perfectly good opportunity to tear down another person or group!

I was particularly impressed with part of the response I got on my own bug report:

Whatever interesting custom input method changes MATE or Ubuntu might ship, that does not necessarily mean that the bug exists somewhere in [our code].

Anyone familiar with Ubuntu MATE knows that this is an absurd claim, but that's not the point. You want to find someone else to blame for the bug, at any cost. By shifting responsibility away from your project, you save your team the effort of having to admit mistakes. It might even help prevent future bug reports!

The next step, of course, is to send the user over to the other project to report the bug there, where they will certainly be told "it's not us". Bravo! You created a royal-runaround situation that left your user feeling hopeless. Mission accomplished.

Blame The User

Perhaps the classiest form of "Blame Someone Else" is if you can shift the responsibility onto the user. Here's a few approaches to consider:

• "You should have known that the button marked [X] doesn't do X!"
• "Everybody knows you should have done A-B-C."
• "Do you even know how to use computers?"
• "What weird hack did you do to your system?"
• "RTFM n00b"

Naturally, you'll want to make your response a lot more passive-aggressive than the examples, but you get the idea. As long as you can imply that the user is the one at fault for the bug, you won't have to exert any effort changing code, clarifying the user interface, or improving documentation.

WONTFIX

The label WONTFIX is one of the most powerful in your whole arsenal, precisely because of its connotations. Unlike phrases like Invalid, Expected Behavior, or Cannot Reproduce, the dreaded WONTFIX implies "we know this is a problem, and we do not care!"

Some of those soft, community-oriented developers would probably encourage you to remove this tag from your issue tracker altogether, replacing it with more specific, reasonable sounding phrases.

But if you want to alienate users and contributors with your issue tracker, you should absolutely leave it in, and use it liberally!

By the way, don't forget that when you have an Expected Behavior situation, your users will still expect you to waste your time writing better documentation or improving the user interface to prevent confusion. Don't fall into their trap. Just slap a WONTFIX on the issue and move on. Creating people-oriented software experiences will only attract users and contributors, and that's exactly what you want to avoid.

Open Source, Closed Door

Just because your code is open source doesn't mean you need to be transparent about your development processes. You'll want to ensure your team never reports bugs and issues they discover on the public bug tracker; if they do, you'll have three problems:

1. Your team will be admitting they're not perfect, which will invite more mamby-pamby contributors who will want to help improve the software,

2. It will be easy to connect bugs observed in the real world to ones your developers have already reported, making it harder to shut down external bug reports,

3. Users will get the ridiculous idea that you'll take their feedback seriously, or that you even want them there at all.

By tucking your internal issue tracker away from the prying eyes of your users and open source contributors, you create plausible deniability, and overall exude a feeling of being an elite, exclusive club. Don't you feel special now?

Don't confuse this with simply offering a different interface for external and internal bugs. Some do-gooder projects implement this approach to facilitate better vetting of outside bug reports; when done in a certain way, it leads to the project developers taking users more seriously! If you want to actually weaponize this separation, you should hide your internal board altogether.

Mind you, if you find yourself in a position where you can't excuse away making the development team's issue tracker private, you can still use the other tactics here to prevent any outside bug reports from leaking into it. When your users try to report a bug and find a closed door, they'll eventually leave you alone.

NOTE: This has nothing to do with hiding security bugs from unauthorized viewers, which any literally any experienced developer would confirm you should do.

Dupe-Flag Liberally

If you are working on a public-facing issue tracker with other, closed bugs, you have a new tool in your arsenal, the Duplicate label! Sure, everyone will use this feature of the issue tracker to combine related issues, but this is a whole different level.

If you reactively mark an issue as Duplicate because of any superficial similarity, you can prevent having to address many distinct bugs altogether! This is especially effective if you mark against an old, closed (or invalid) bug. When your user sees that you consider their issue to be "old news" (especially when it's very real and current), they'll go away.

Of course, you occasionally get a belligerent bug reporter who insists that the Duplicate label was inappropriate, and then goes and establishes a solid case. This doesn't mean you have to back down. You can always passive-aggressively question their logic and credibility. Ultimately, it doesn't matter what they say anyway. You can leave the Duplicate label in place, and let them shout into the wind until they get bored and leave, preferably forever.

Miscellanea

There are a few other tactics you can use in interacting with users on your issue tracker that will leave them feeling frustrated and hopeless:

• Ask clarifying questions that they've already answered, to make it clear you didn't deign their responses worth reading. You'll be surprised how many times you can get away with asking the same question!

• Use passive-aggressive language, especially the type that reads as incredibly hurtful, but can be denied later: "One cannot read tone. I was being nice!"

• When they get upset at your dismissive behavior, imply that they are being unreasonable, whiny brats. Double standards are awesome!

• Accuse them of being petty when they gripe about your dismissing their bug out-of-hand.

• Cite how unreasonable they're being to expect a busy person such as yourself to dedicate time to their concerns.

You don't need to use all of these techniques in this article. Sometimes, mixing-and-matching can produce even better results. If you can lure your users into a false sense of security by handling some things well, and then sticking it to them in another area, the resulting shock and bewilderment can be far more effective.

Actually...

Ahem

In case you haven't caught it, this entire article has been dripping with sarcasm. OF COURSE you should treat your users and contributors well! I would even go as far as to say most developers believe in this premise, in theory at least. I'd be surprised if anyone wanted to alienate users and contributors.

In practice, however, issue trackers have been the site of some of the most reprehensible behavior in the software development world, and it's high time we do something about it. You have a responsibility to the industry and your users, especially if you're working on free and open source software, to set the standard for polite, constructive issue tracker behavior.

Secondly, if you see this type of bad behavior, you should not excuse it! After that bug report incident I mentioned at the start of the article, I was outright mocked by a couple of long-time professional acquaintances for being hurt. I was actually informed that the belittlement and disregard with which I had been treated in response to a well-thought-out bug report was both acceptable and deserved. If I weren't intimately aware of the good side of Free and Open Source, I would have dismissed the entire community as hateful and elitist, left, and never come back.

Thankfully, I had a number of other fellow developers confirm that the way I had been treated was inexcusable. The only ones to defend the indefensible were themselves loyal to the project from whence the behavior came, and that is exactly why this behavior is propagated!

I am also glad to say that, in terms of the original bug report, someone finally responded with respect; even though my bug is proving to be nigh-on-impossible to reproduce, (it wouldn't be the first time I've encountered those in coding) I got a civil response nonetheless.

I wish I could say that this problem was limited to little, inconsequential projects, but I've encountered it in multiple major software communities, including several that were part of the GNOME community. When did alienating users and contributors become okay?

More importantly, what will you do about it?