Don’t Report Issues on GitHub

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.

GitHub

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.

17 Replies to “Don’t Report Issues on GitHub”

  1. Ok. Guilty as charged…. but, in the interest of science.

    We have 4 plugins in the WordPress repo. All were released within the last 12 or so months. We decided to do an experiment about where and how people should report support issues. It’s a little nuts.. but I wanted to see what works and what doesn’t, as well as try different methods for soliciting code contributions.

    Postmatic – Our only premium product which is GPL but developed in a private repo for now. Email support only via Helpscout. Works great because we are 100% dedicated to offering outstanding support to all users. A few have complained though that there is not a history of tickets/issue on wporg for them to browse through. I can see their point but if we are going to offer the level of support we want to… we need a better tool than wporg.

    Epoch – GPL and publicly developed. We use Github issues to purposefully foster a community of coders and potential collaborators. Epoch is a complicated beast and until we get it right I want the user base to be as resourceful as possible. This has been a success. Issues get submitted and frequently solved by other community members in the form of a convenient pull request or patch. That wouldn’t happen on wporg.

    If someone submits an Epoch ticket to our Postmatic support we make a ticket in Github for them and at least shoot them the url to follow along. Half the time they create and account…which is a nice gateway to their own learning. Same with if they submit one via wporg.

    Crowd Control & Postmatic Social Commenting – wporg

    These two are both tiny so we just left them on wporg. We get tickets… but no contributions to the code base. It’s a lot of take take take and so far 0 give. Both plugins are less interesting and with super small installation numbers though…

    TL;DR:

    Github is great for turning issues into contributions.
    For projects with a large number of support requests we need something heavier duty like Helpscout.
    WordPress.org is alright for smaller projects but we don’t get a lot back from the community there. The entitlement factor is high… and discouraging.

    Tom, you’ve got a lot of plugins in the wporg repo. Do you do all of your support there?

    1. Thanks for such a detailed comments – I really did learn a lot and it makes me think more about some of the things I’ve written.

      To answer your points, I’ll just reply to the TL;DR you’ve provided:

      Github is great for turning issues into contributions.

      Agreed on this front. People also like to see props so this is more motivation to report issues and/or bugs and what not.

      For projects with a large number of support requests we need something heavier duty like Helpscout.

      Big fan of Help Scout. Used them back in the day and will likely be using them for something next year.

      WordPress.org is alright for smaller projects but we don’t get a lot back from the community there. The entitlement factor is high… and discouraging.

      I just avoid it.

      Tom, you’ve got a lot of plugins in the wporg repo. Do you do all of your support there?

      I do none. I have a sticky post saying as much and then I normally respond via email when someone contacts me.

  2. You’re assuming that all plugins used by users, are on WPORG. Most of mine are only on GitHub, and part of that reason is because I don’t want to handle SVN or the WPORG support forum. They are free plugins, with no ulterior motive of a premium product. For those who happen to install GitHub Updater, they get easy updates too, a feature that some primarily use the WPORG repo for.

    You make a fair point and may be correct for a vast collection of plugins, but the target audience of the plugin needs to be considered, rather that a blanket statement of opinion that GitHub is not for user support.

    1. You’re assuming that all plugins used by users, are on WPORG.

      That was never my intention, though I see (in retrospect) how the post would come off like that. The post genuinely was written in a way that made not assumptions to where the plugins were being hosted.

      They are free plugins, with no ulterior motive of a premium product.

      Sure! I’ve a few in the same position, though I’ll still get open issues or emails about them, as well. (FWIW, I find email to be fine for support. It has its limitations for things like FAQs but I digress.)

      rather that a blanket statement of opinion that GitHub is not for user support.

      Point taken. If the users are developer-types, then I think GitHub works fine, but I still stand by the idea that the average user of a plugin – if the plugin is not targeting developers – will have a hard time navigating GitHubs user interface and knowing where to ask their question, etc.

      This is why I’m a big fan of dedicated support solutions. They have clear intent and help guide users down the path of what they need to do when they have a question.

  3. Gary Jones makes a good point. Hosting on wp.org brings the implication that you will offer free support to all and sundry. Hosting only on GitHub or Gist pushes that back to, well, people who have at least signed up for GitHub and are not afraid of looking at code. Asking people to submit support requests for wp.org plugins to GitHub is kind of like the middle ground there, leaning towards the latter.

    Free support isn’t a right for free plugins, it’s a privilege, but hosting on wp.org gives people an instant expectation of free support. I personally think that if you host a plugin on wp.org then you are accepting that expectation, but I can see how others might view it differently and simply request that support tickets get posted on GitHub.

    1. Gary Jones makes a good point. Hosting on wp.org brings the implication that you will offer free support to all and sundry.

      True, but you can post a sticky post in the forums that say you aren’t going to use those support forums and point them to where they can find you (if you opt to provide support).

      …who have at least signed up for GitHub and are not afraid of looking at code

      But those who aren’t afraid of looking at code may be a huge bit of people depending on who your core audience is. Which is what it really all comes to, IMHO.

      Free support isn’t a right for free plugins, it’s a privilege, but hosting on wp.org gives people an instant expectation of free support.

      Agreed.

      I personally think that if you host a plugin on wp.org then you are accepting that expectation, but I can see how others might view it differently and simply request that support tickets get posted on GitHub.

      Since I tend to view it as a privilege that the may or may not grant, I think it’s okay not to offer it. Maybe I’m just defending some of my own choices. I don’t know. Regardless, I like dedicated help systems that funnel users down the easiest path for them to get help to whatever they are experiencing.

  4. My own personal view, and this may not be a view shared by many, is that users should report issues where ever is easiest for the developer. This is especially true for open source projects where the developer isn’t getting paid directly and has limited time. Everything under one roof consolidates the project and helps to get things done.

    Signing up on GitHub just to report issues is common and, in my experience, users who are prepared to provide qualitative feedback are very likely to do it if it means the bug will get fixed quicker.

    1. My own personal view, and this may not be a view shared by many, is that users should report issues where ever is easiest for the developer.

      I see the inverse as being true. The developer should expect users to report issues in whatever is easiest for said user (but I know that you said it’s one that’s not shared by many, so that’s cool :).

      This is especially true for open source projects where the developer isn’t getting paid directly and has limited time.

      I don’t disagree with this, really. I’d say the line is drawn when there is a premium payment involved. If it’s a free plugin, perhaps GitHub is just fine; otherwise, perhaps the cost should be built into the price the project.

      Signing up on GitHub just to report issues is common and, in my experience, users who are prepared to provide qualitative feedback are very likely to do it if it means the bug will get fixed quicker.

      I think there’s an implication here, though: The users are comfortable navigating GitHub. And if they are, great! Otherwise, I don’t know if it’s such a good place.

  5. I’m also a fan of Help Scout for the nice customer experience it facilitates. But this article and conversation now has me thinking about ways to easily create a GitHub issue from a Help Scout conversation for the best of both worlds. :-)

  6. “GitHub is for developers, and we should leave it that way”

    Aye.

    Why make our Joe Average users sign up on a developer tool site? They’re going to have a GitHub account solely to log issues, creating unnecessary and inactive users on GitHub.

    Is that what we GitHub users want?

    GitHub issues should be developer to developer.

    1. Is that what we GitHub users want?

      Some do as evident by the comments – and their use case isn’t totally off base. Plus, at least it’s reserved towards their repositories.

      Personally, I’m not a fan, but to each their own.

      GitHub issues should be developer to developer.

      Agreed.

  7. Ben Balter wrote Comment Card, which “provides a simplified interface for non-technical users — both authenticated and pseudonymous — to provide feedback for your GitHub-hosted project (in the form of GitHub issues)”: https://github.com/benbalter/comment-card

    There’s also a lot of options and workarounds here that might help minimizing the friction: http://ben.balter.com/2015/01/11/hacking-github/

    I know that’s a different conversation, but sometimes our support experience fits in one of the above cases. :)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.