Bug Finding Considered Harmful?
7 points by eatonphil
7 points by eatonphil
From the linked Z3 thread:
You only want these issues fixed so you can find your "next batch", not because you've building something awesome that needs this "broken" functionality.
Is an unfortunate dynamic that plays out in open source. Also:
Localize and even submit fixes for simple bugs that can be addressed (some of these bugs are pretty basic and require no deep understanding of internals).
Many times I keep my PRs small so they'll be reviewed, but after reviewing them the maintainer is rewarded with another PR of mine that had to wait until the previous PRs were done. So really it starts to function as a single-queue network with a feedback loop where servicing a task results in another task immediately being put at the back of the queue. Since work is endless, the incentive to actually review a PR drops to zero because the reward for reviewing the PR is another PR to review. Hopefully at least the underlying project quality improves as a side-effect of this system. In dysfunctional projects, maintainers might realize this pattern and eventually stop responding to your PRs so your option at that point is to either graduate to maintainer status yourself & start approving your own PRs, or just stop contributing to the project.
For finding bugs, I have done a lot of that and well... bugs are cheap and have recently become astronomically cheaper. At least filing a non-security-critical bug is more like tossing a TODO on the pile instead of generating a work obligation. Of course, there are bugs and bugs, the critical soundness kind that only manifest once in a pathological scheduling of system events. But those are very difficult to find.
For the bugs that are “simple to fix”, I have this hope that maybe we can actually enumerate all the cases that changed as the result of this change in a provable way, which might lead to breaking the asymmetry I mention in the post. Maybe this way we can even out the leverages.