How do you know they obviously need the change by making a decision away from the project management discussions?
Perhaps a solution has been discussed and is incoming from a regular developer?
They could deprecate the module where the change is "obviously" needed in a larger fix.
Frame it a different way: You're basing the needs of a project on your view of it, which, minus discussing things with project mgmt beforehand, may be incomplete.
You completely misunderstood who was needing the fix. In this case, it was the person who spent time fixing it. They likely fixed it because they need the fix.
Doesn't matter if the entire module becomes deprecated. They'll stay back with their fix (likely). Doesn't matter if another solution is inbound, they needed the fix now and not when a patch lands.
And since they already took the time to fix it - little time is lost sending a PR, regardless if it gets merged or not. If it is merged? Sweet you helped the project out (most likely). If not? Well a small bummer that you'll need to maintain your own patch(es).
This is an odd way of thinking about it. As a user of software, I like fixing it for my needs but I'd rather make the change in a way that the maintainer will accept, so that I don't have to maintain my patch. That means I'll tend to open an issue first, explain that I'm willing to submit a PR, and see if the maintainer wants to give me guidance.
I think it depends a lot on context. If I am looking to contribute for the sole purpose of improving the OSS project, then I follow your method. If I am using an OSS project in a larger commercial project and I need a bugfix or feature now, I just build it. If I think it may be useful to the OSS project, then I will contribute back with the understanding that it may not be merged.
Perhaps a solution has been discussed and is incoming from a regular developer?
They could deprecate the module where the change is "obviously" needed in a larger fix.
Frame it a different way: You're basing the needs of a project on your view of it, which, minus discussing things with project mgmt beforehand, may be incomplete.