With the small caveat that this is scale dependent. I can assure you that there absolutely are projects that require components. (If you prefer a different model, you can assign a different bug tracker for each component - but that makes collective metrics harder)
I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.
Yes, that's a lot of overhead. Unless you have 1000+ people working on your software, you won't need it. Up to ~100 people, you can probably assign fairly directly, depending on the range of problems the code base spans.
Similarly, there are reasons why you don't want to do task breakdowns for everything in the bug tracker. Global refactorings are a good candidate to skip that, because you will do that across teams, piece by piece, and tracking them in a bug tracker is not necessary. We got spreadsheets for that ;)
Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug. And really, the "flow" is just nine different priorities. (God, let me never work on something that has nine different priorities ;)
So, "season to taste". But there are definitely lots of good ideas in there. If there was just ONE I could enforce across all projects I ever work on, it'd be "Close the damn bugs if you're not going to work on it" - issue hygiene is incredibly important.
"Season to taste" I totally agree with, no way to capture the whole world in a signel post ;)
> I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.
I do agree it's about routing. My problem with components is alignment with teams and their stability over time and survival of existing tickets across those changes, which is why I think different routing mechanisms are better. But yeah, if it works...
> Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug.
I call those "an incident" and in every environment I've been at, everybody knew which one it is very well without any labels ;)
If you can share more about different routing mechanisms, I'd love to hear it. It's not that components are making me happy, per se ;)
As for the priority label - it makes sense if there's either a huge bug load (cf. bug hygiene ;) or in environments where you have automated workflows. I.e filing a bug with P0 alerts the responsible engineer, starts a log document for the inevitable post mortem, lets production know, whatever you need to do for P0s.
Not all fields in the database are for humans :)
I have occasionally thought it'd be nice if we ditched a lot of UI & status fields, and the IC view in the bug database is just "what is the most important thing for me to work on right now". One issue. Only comment history, no other fields. You still need the rest for reporting, analysis, workflows, but as IC, that's what you care about.
I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.
Yes, that's a lot of overhead. Unless you have 1000+ people working on your software, you won't need it. Up to ~100 people, you can probably assign fairly directly, depending on the range of problems the code base spans.
Similarly, there are reasons why you don't want to do task breakdowns for everything in the bug tracker. Global refactorings are a good candidate to skip that, because you will do that across teams, piece by piece, and tracking them in a bug tracker is not necessary. We got spreadsheets for that ;)
Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug. And really, the "flow" is just nine different priorities. (God, let me never work on something that has nine different priorities ;)
So, "season to taste". But there are definitely lots of good ideas in there. If there was just ONE I could enforce across all projects I ever work on, it'd be "Close the damn bugs if you're not going to work on it" - issue hygiene is incredibly important.