Respond to GitHub Issues in a Timely Manner

GitHub Mascot Octocat

Recently my coworker, Coen Jacobs, wrote a great post about the Art of Commit Messages. And there's a lot for a developer to learn there. The part that we don't hear much about the art of maintaining a repo on GitHub. Do they have any duties? Is there any etiquette when it comes to maintaining a GitHub repo?

I have one tip – be timely with your repos.

Why Be Timely?

I can't think of a single developer that has oodles of time. If you do happen to have some extra free time you're probably going to pick up another project. That's just the nature of most of the developers I've met. But regardless of how busy you are you still need to make time for people who are interacting with you on your GitHub repos.

People Lose Motivation

If you take too long to respond to an issue or a pull request there's a good chance you'll never hear from the developer again. The other developer might have needed it for a client project and now that you're asking them for more information after they've finished the job there isn't much incentive to help.

I once had someone ask for an updated pull request on (you're going to love the irony here) GitHub's gitignore repo. An entire year after I submitted the request to update something they ask me to update the pull request – I knew that it would still help me and the community down the road so I did it anyway. Were this a smaller project I don't know if I would have taken the time to update the pull request. I already have enough on my plate.

People Lose Context

The other problem waiting too long to respond to someone is that they'll lose information on the project. They might have had a test site they could use to replicate the problem. Or they might have switched systems and aren't even using your project anymore.

Respect

The biggest reason though is a simple one. Respect. If I'm submitting a patch to make your project better take a few minutes out of your day to tinker with it and pull it in. I'm not talking about troubleshooting here – that's a different issue. I'm just talking about managing real issues & pull requests. You never know when you'll need that developer's help down the road.

Say No

Disable Github Issues

Disable GitHub issues

If you can't help them because you're no longer maintaining the project then say so. Close the issue saying that you can't help them. Better yet – you can turn off GitHub issues and update the readme with a notice. This way you'll save someone else's valuable time and in this busy day and age that's one of the nicest things you can do.

24 Pull Requests

24 Pull Requests
  1. Blogging for Benjamin Competition
  2. Why I'm Grateful to Work on the Web
  3. 24 Pull Requests
  4. Update Downloadable Product's Expiration Date in WooCommere
  5. Get Lost in the Flow and Work for More Than a Salary
  6. Why A Plugin's Popularity Matters
  7. Why You Should (Or Shouldn't) Use Premium Plugins
  8. WooCommerce Terms & Conditions
  9. Only Ship to Continental United States with WooCommerce
  10. Just Talk
  11. Why I Love Jetpack
  12. Making Jetpack Better
  13. Remove Billing Address for Free Virtual Orders in WooCommerce
  14. Notify Admin of Customer Address Change in WooCommerce
  15. Open Your Self Up To New Possibilities
  16. 2013 Resolutions Review
  17. Create a Community
  18. Tips for Starting a Community
  19. The Intent of Goals
  20. Create The Ultimate Invoicing System Using WooCommerce
  21. Change From Address in Ninja Forms
  22. Work With People Who Inspire You
  23. Contact Form 7 & MailPoet Integration
  24. Monotasking
  25. Giving Back to The Community
  26. Adding Fuctionality to Lean Plugins
  27. Choose Stripe For a Payment Gateway
  28. A Dip Into Entrepreneurship
  29. Reward Yourself
  30. Blogging for Benjamin Plugin
  31. Blogging for Benjamin Wrap Up

Yesterday, in my post about why working on the web is so great I mentioned a tool called GitHub. While GitHub is only a tool it is a really awesome tool because it makes it unbelievably easy to version control your code and for another user to submit a patch (aka pull request) or report issues to you. Increased collaboration is important for any project but it's even more important for open source projects.

Software isn't Free

It should come as no surprise that software isn't free. It takes many programming hours to build new features, many hours to diagnose and fix bugs, hours to plan the roadmap, and many many hours of support helping your users.

There are some great open source projects that have highly efficient monetizations models. Just look at the totally free software WordPress; they have WordPress.com, WordPress VIP, Akismet, VaultPress, etc, that bring in money. But for many open source projects there isn't a good monetization model and without cash flow to support the hours of development the project dies.

Now what happens for projects that don't have a good business model? Well unless they have a dedicated community to keep it going these projects quickly become outdated and become security vulnerabilities. And the last thing that you want is an outdated piece of software that leaves your site ripe for a hack.

Continue Reading…

Show Me You’re Passionate

Coke Can on Ground

Last week I was lucky enough to be included in panel interview for a new WooCommerce Ninja. The potential ninja did very well and talked about how he got into WordPress, working with clients, and debugging code. But it wasn't these questions that really interested me – I don't care about coding style, programming languages, or the tools that he uses. All of those can be learned on the fly. The quality that I care about more than all of the rest is passion.

Continue Reading…