mhoyeI felt this in my teeth.
Lemme lean into this a little harder: JIRA is what companies buy when they should have invested in manager training five years ago.
Benjamin Smedberg@mhoye very curious about this because I can’t tell if you mean jira in particular or bug tracking systems in general.
@bsmedberg Every project needs issue trackers, but describing Jira as an issue tracker is like describing McDonald's as a restaurant. It's a organizational culture and language least-common-denominator normalization tool whose endpoint happens to resemble an issue tracker.
A well-functioning issue tracker is a core part of making an org visible and legible to itself; adopting a tool that forces every part of an org to speak the same operational language is the lowest-trust path to that goal.
Josh TriplettI think I'd *prefer* the "McDonald's of issue trackers", because at least it'd be a consistent "meh" experience everywhere. Jira is different everywhere, typically encoding every random field someone once wanted so that prospective issue filers have 50 fields to fill out and "computer says no" is the response to anything that doesn't fit the presumed process.
Paul CoenYup. When we re-implemented, I made sure any project I had to deal with had far fewer mandatory fields and very few specific issue types. The previous iteration was insanely specific. The other projects were simplified as well.
@paulrcoen @josh @bsmedberg One of the challenges in issue tracker design is that the specificity in those fields is correctly believed to matter a lot. We know from SE research that the most important _predictor_ that a bug will eventually be fixed is whether or not it lands in front of the right team on first contact. In practice, bugs that get re-triaged 2-3 times are effectively gone, and overspecific fields are an organizational allergic reaction to that.
@paulrcoen @josh @bsmedberg When I say "allergic reaction", I really did mean that; it's an near-involuntary over-rotation on the fear of losing important bugs, without a critical sense of the org-wide cost of that specificity. A more level-headed approach is to realize that any bug that bounces twice is bouncing because it needs a _leadership decision_, not an engineering one. So, on the second bounce they should go into a manager's-triage queue, rather than engineering triage.
@mhoye @josh @bsmedberg Yup. We're relying on a controlled vocabulary of labels across projects for classification and making sure the right team sees it. It's its own overhead, but we've found it a bit easier to manage.