By aggressive, I'm referring to the fact that you're explicitly calling out someone in a very public manner, for something that isn't going to imminently break functionality. I have no comment on whether this is a real concern as I lack context and have not read the linked post, but from your description, I wouldn't expect this to break things before the next path (which is three months out).
I can't speak for gausie, but if you had instead called me out in this way for a change I committed, I would have found that rather offputting, and I'd be less inclined to work with you in the future.
A more constructive approach (in addition to what I assume is the fix you've provided in this patch) might be to add a test that enforces this requirement of "three unknown paths" in the enum. Some day, we aspire to add hooks to block commits if tests fail. We're not there yet, and we don't have good enough test coverage yet for this to be adequate. There are large swaths of the codebase that are quite frankly difficult to test without invasive refactors (anything in request/, for one).
...
If it were up to me, everyone would be held to the same standard for nontrivial non-urgent patches. While something like code review may seem to reduce velocity in the short-term, it improves the quality / readability of code, stops errors from reaching production, reduces the amount of time that we need to spend fixing bugs afterwards, and reduces the frequency of bad revisions. All of these things together more than counterbalance the immediately visible reduction of velocity, in the long run.
(That said, this is not my decision to make unilaterally. I also would not institute mandatory code reviews unless we adopted some tooling that better supported doing so.)
