Adding pre-report bug discussion

It is true that: 1. good bug reports are an invaluable contribution to open source projects and 2. bad bug reports are a drain on maintainers. These two ideas are in constant tension with each other. Part of the reason is that it’s not always clear what is and is not a bug. Some behaviors are very obviously bugs, but some are misunderstandings or user error. (I’d argue that constitutes a documentation bug.) Other times, it’s not clear at the beginning where the error lies: is it in the application, one of it’s dependencies, the operating system, or something else entirely? People who understand the software deeply can often tell, but most bug reporters don’t have the deep knowledge that a maintainer has.

Long-time Fedora Project Leader Matthew Miller told me the one feature he wished bug trackers had was the ability to start as a “this doesn’t seem right” conversation, do some collaborative troubleshooting, and then become a bug report if appropriate. This would, he theorized, simultaneously increase the willingness of users to enter the bug report flow (because it explicitly encourages “I’m not sure if this is a bug, but…” that can dissuade people from submitting a bug report) and also improves the quality of bug reports (because other community members can help diagnose and triage the issue before it ever hits the bug tracker).

When I read that Mitchell Hashimoto is doing something similar with Ghostty, I was intrigued. Although GitHub doesn’t offer a mechanism to enforce it, the project only allows maintainers to create issues. Users start with a discussion post and if it turns out to be actionable, it gets converted to an issue. It’s hard to say for sure if that has had an impact on the community, since the policy is basically coincident with the 1.0 release. But it doesn’t seem to be harmful. The total of commits in the four months after this policy is 80% of the commit counts in the four months prior, which is reasonable considering it was pre-release in the earlier period. The GitHub star history graph (yeah, I know) is basically vertical.

I do like the idea of keeping the issue list actionable and relevant. It’s off-putting when a repository has hundreds or thousands of issues that will probably never get touched. Something about this feels user-hostile to me, although fundamentally it’s the same amount of effort for users. Perhaps I feel that way because it’s such a marked change from how every other project I’ve interacted with works.

I’m not sure I’m ready to advocate for this sort of setup, but if you think it works for your project then go for it. If nothing else, it’s good to see fresh ideas in the challenging and unexciting field of bug tracking.

This post’s featured photo by Neringa Hünnefeld on Unsplash.