In defence of GitHub Issues

I saw a Reddit meme recently showing Squidward losing interest after seeing the GitHub issue count on Photocraft, the new vibe-coded Photoshop competitor.

The assumption here seems to be 1,700 issues means 1,700 things broken, and thus the software isn’t really worth using. This may or may not be true of Photocraft in particular, but it does reflect a common misunderstanding of what issues are on GitHub.

Issues are, as any true software developer knows, used to raise not only bugs but feature requests, questions, and design decisions. A large number of issues does not inherently mean a project is in bad shape.

Issues are also not the only thing on GitHub that has a funny and counterintuitive name. Pull requests really should be called merge requests, and on competing development platform GitLab, they are. But “issues” is a surprisingly sticky term that is still used on both platforms.

At first blush, it seems like there should be an obviously better term for the functionality covered by “issues”. But it’s surprisingly hard to improve on:

• Tasks/work items: Implies that something needs to be done, which is not always the case.
• Topics/threads: Suggests discussion, but GitHub already has a separate (neglected) Discussions feature.
• Tickets/cases: This isn’t customer support.
• Matters: Reminds me of “matters arising” (i.e., the pretentious way to say letters to the editor/commentaries in some scientific publications). Too stuffy.
• Items: What does it mean? Nothing.

I’ve come around to thinking that “issues” is better than it sounds. It’s an unusually useful combination of vague and actionable. You can raise an issue without knowing what should be done about it, and you can close one without having fixed anything.