In the admittedly short time I’ve worked in software development, I’ve rarely seen a site like GitHub have such a level of success especially for something as nerdy as version control.

Linktocat has always been one of my favorites.

Linktocat has always been one of my favorites.

Don’t get me wrong: Version Control is a must have for any serious software development shops – be it a single person or a team of people. But the fact the site works so well, has a variety of quality clients, and doesn’t  look like, y’know, developers built the site is such a huge plus.

And as much as I love open source and what GitHub has brought us, I often see development shops asking users to report issues on GitHub whenever they see them.

That’s never sat well with me.

The thing is, even though GitHub looks good, even though it works well, and even though it does its job well at doing what it’s meant to do, it’s still targeting an audience that’s very rarely going to be our core audience.

Report Issues on GitHub!

For those involved with building things for WordPress, it’s becoming common behavior to have our work hosted on both GitHub and in Subversion (such as the WordPress Plugin Repository). And a good read, right?

  • The WordPress Theme and Plugin directories use Subversion
  • GitHub has a nicer UI and more flexible project management tools

The thing I see many developers doing, though, is asking users to report issues, bugs, and general support questions to GitHub.

But think about that.


Many of the people for whom we’re building solutions are people who use WordPress for their blogs, for the content management, and/or for their web application. They aren’t developers. And though they may be tech-savvy, the idea of version control is just jargon.

Why would we expect our users or our customers to use our systems to report their problems?

Besides, first and foremost, GitHub is built with developers in mind. Remember, it’s the whole “social coding” thing, right? It’s not “Social Coding, Generous Support” or something like that.

If we want to reduce friction and frustration with our users and customers, we still need to make sure we’re giving them the easiest access possible to our support channels. To do so means using a tool that’s clear and easy to understand. Not something that uses terms like “issues” and “labels” and has an abstract name like “GitHub.”

People want help or the need support. Funneling them to a site like GitHub is not ideal. Instead, we should be taking the feedback we’ve received via our support system and then manually creating our issues.

That’s not their job.

As we continue to move forward with building our projects and our businesses, let’s remember our customers and users are not our development peers. And that’s fine.

GitHub is for developers, and we should leave it that way. Let’s make sure we take care of our users in the easiest, most streamlined, least frustrating way possible.