when they're used internally, within a company, they're project management tools, primarily about producing metrics for management—but when they're public facing, the bug tracker is functionally a CRM tool
rather than being a tool for programmers to communicate with each other, bug trackers primarily exist as a means to communicate with people outside the team—bug trackers don't really get used to track bugs
@tef IMO the best model is a bug tracker that is read-only for non-developers and some communications channel, like open group chat ir a mailing list where users can report issues to. That keeps the tracker clean and passively enforces triage.
@tef I feel sad when I see a bug / issue tracker used as a tool of control over the end user by the developer. Some amount of wrangling is fair, but there has to be empathy both ways, and the tool shouldn't serve only one party. They can be used and implemented in user hostile ways!
Add comment