if someone comes to you with a bazillion issues that you cannot possibly fix in the X hours you have during the day what are you going to do? you're going to prioritize and you're going to fix the most important bugs, right?
if you're developing a new feature and things are pointed out during the code review (bots or no bots) what are you going to do? fix it, right? you want to ship whatever you're doing with high quality.
so the problem outlined below is a false one. you can never fix all the possible bugs if the codebase if nothing but trivial.
> you're going to prioritize and you're going to fix the most important bugs, right?
That doesn't make sense. Presented one way, the bugs were fixed to a 70% rate. Presented another way, 0%.
Presumably the bugs in each case were about equivalent in their severity (else the conclusion is meaningless) so severity was not the driving factor in what got fixed.
> you can never fix all the possible bugs if the codebase if nothing but trivial.
That's a non-sequitur. No-one suggested they could fix all, or should try. It was about known bugs presented to them.
It makes perfect sense. If you file a bug assigned to me that doesn't seem to actually affect users or isn't aligned with the work I am already committed too, it goes in the backlog and I may or may not ever get to it. If it's a bot that generated the bug, it comes after user reports, and I may never get to all of those.
If it's a comment on a code review for code I am already working on, then of course I want my new or changed code to be up to date with standards and avoid error prone patterns, etc.
@mirceal, @wffurr, I see what you're saying and you're both right.
However that does leave a major question for me; if devs are triaging their own bugs to this extent (70% vs 0% fix), is this safe, because those bugs will relate ultimately to business requirements related to uptime and correctness.
For the most part at Facebook, ongoing maintenance and business outcomes are the responsibility of the team that originally wrote and deployed the feature. The idea is to give the team (and ideally the individual developer) as much agency as possible as they are the closest to the actual problems.
developers don’t triage their own bugs (mostly) but the difference is that one issue is implicit at PR time while the other is explicit (actual
bugs filing - this means that apart from fixing they occur the overhead of actually having Jira/whatever items attached to them, being discussed and prioritized in backlog grooming, being preempted by higer priority feature work or bugs, you name it. what was a 5 minutes fix now eats hours. with 0 recognition and perceived as cleanup that might not be needed at all)
if someone comes to you with a bazillion issues that you cannot possibly fix in the X hours you have during the day what are you going to do? you're going to prioritize and you're going to fix the most important bugs, right?
if you're developing a new feature and things are pointed out during the code review (bots or no bots) what are you going to do? fix it, right? you want to ship whatever you're doing with high quality.
so the problem outlined below is a false one. you can never fix all the possible bugs if the codebase if nothing but trivial.