[normie3000]

> I'm hesitant to even open a PR, because...

For me the answer to this is to let go of all expectations. Fix things for your own purpose, and then open PRs to give the maintainers the option to engage or ignore.

Obviously from my post above, with my maintainer hat on I often fail to let go of the emotions. But it's a goal.

The lowest-stress PRs to handle are the ones with clearest test cases, and minimal incidental changes. Don't refactor, reformat or rename things to your own preferences and then expect a maintainer to engage.

Reducing changes to the meaningful minimum will also make your fork easier to maintain if the PR is refused, or ignored for months+ as the upstream project continues to evolve.

Ultimately, opening a PR is in part self-serving - best case is my change is upstreamed, worst case is I have taken time to streamline it, and simplify integration of future upstream changes into my fork.