Home GitHub Issues: Let's Take Action
Post
Cancel

GitHub Issues: Let's Take Action

As a development team, you’re probably tracking your work somehow – whether it’s GitHub issues or some other application or system. Which is great! Things are being documented, worked on, and completed.

However, for various reasons, sometimes issues don’t get worked on and completed. This isn’t necessarily a bad thing – perhaps the issue just didn’t matter enough when compared to other more important issues.

These unhandled issues can pile up. When issues pile up important and unimportant work is mixed together. And, after enough time passes you’re questioning if some issues are still relevant at all.

Taking action

I suggest manually (or, automatically) closing issues for inactivity. If it hasn’t been important enough to be completed in a short amount of time – perhaps it’s not important enough to ever be completed.

For a business environment, this is probably best done manually. You may need to constantly reevaluate the situation and be honest: If you can’t see the issue being completed, maybe it should be closed. I believe Khalid Abuhakmeh has mentioned something like if it’s important enough, it’ll come back up again aloud previously. And, it makes sense. You’ll probably continue to remember an overdue oil change until you take care of it – even if you don’t write it down or plan it out.

For an open source project (especially a popular one), automatically closing issues waiting too long for the issue reporter to reply using a bot or similar may be a great course to take. I don’t have current experience here, but it seems like https://github.com/twbs/no-carrier might be something to evaluate.

In closing

Having carefully pruned issues that always matter enables team members and contributors to know what’s important enough to act on. Without this discipline, it’s easy for issues to become a sea of uncertainty. Should we implement this? Should we fix this? Does this still apply? Hmm, it’s many months old…

Let’s take action! Even if the action is simply deciding to not do something and closing the issue, at least we’re making a decision and moving forward. It’s easy to change your mind later and reopen an issue, if the need arises.

This post is licensed under CC BY 4.0 by the author.

Copying App Settings and Connection Strings Between Azure Web Apps

Can We Make Some Changes First? Pull Requesting a GitHub Pull Request

Comments powered by Disqus.