You want more bugs fixed, it would seem a better way would be to build a better sense of community (Have bugfix-only days, etc) and encourage it through good behavior, not through negative reinforcement.
I do agree with that in a general way, but I think there should also be a real effort done by the various maintainers to make sure people indeed fix the few PRs they created. Maintainers should be able to say, "please think of fixing this PR before submitting a patch for that feature". That doesn't introduce administrative overhead, because maintainers should keep track of the various PRs and patches of their area. I think it works already for some areas of the compiler, but doesn't work fine for the "most common" areas. A few examples of that (maybe I'm always quoting the same examples, but those are the ones I know that impact my own work on GCC): -- how can bootstrap stay broken (with default configure options) on i386-linux for 3 weeks? -- how could i386-netbsd bootstrap be broken for months (PR30058), and i386-mingw still be broken after 6 months (PR30589), when the cause of failure is well known? These are not rethorical "How", or finger-pointing. I think these are cases of failure we should analyze to understand what in our development model allows them to happen. FX
