The noise would come from the PRs not associated with a trac ticket, I don’t have a good feeling for how frequent those would be
This is my only doubt – there are some contributors who open PRs to make things friendlier for for reusable apps or to relax unnecessary assertions in unit tests, often without a ticket, because it’s not a behavior change.
We’ve documented the simpler rule that anything but a typo needs a ticket. So, we can “get tough” and start doing tickets for every PR to remove a hardcoded PK in a unit test. My question is whether we should really “get tough” from day one, or should we “soft launch”.
Yeah I was looking through the last few months of merged PR’s there and yeah there are a few noteworthy contributors who don’t really use the checklist, (but are obviously doing the things in it) I can see why you wouldn’t want to make their path harder.
Thanks @blighj, I share your view but the reality these days is that the egalitarian principle/culture was designed for humans, and it’s being stress-tested by something it wasn’t built for: the flood of AI-generated and low-effort PRs. This is a qualitatively different problem (to which I have no clue how to address yet).
The “established contributor” exemption would not be about creating an upper class, but instead about avoiding doing bot-filtering to the people it was never meant to filter.
This looks like a very well-thought out implementation and an excellent way to combat the issues that have arisen lately. Definitely a great starting point, at the very least.
. Let me know if you find/see any issues! 