How should a contributor gauge whether to make big changes to “do it right” or to do it a little hacky just to get the job done?

When you work in enough diverse codebases, with enough diverse contributors, you begin to understand there isn’t one objectively right way. There are many objectively wrong ways to do something. Picking a way to do a certain task is about picking from tradeoffs. A disturbingly common tradeoff is picking rapid development over long term maintainability, but that isn’t not the right way to do it in a competitive space.

Needs change over time and certain tradoffs may no longer apply. You’re likely to see better success making lots of little hacky fixes until it’s not a hack anymore because you’ve morphed it slowly over time.

Version control, git et al, allows you to make multiple commits in a single PR, so you could break the changes up to be more reviewable.

Hear, hear! I would add that it multiplies again, again when other people are actually using the product. Engineers famously build tools for engineers which can leave something to be desired for the layman.

Maybe this goes a bit deeper than the question intended, but I’ve made and shared two patches that I had to apply locally for years before they were merged into the base packages.

The first was a patch in 2015 for SDL2 to prevent the Sixaxis and other misbehaving controllers to not use uninitialized axes and overwrite initialized ones. Merged in 2018.

The second was a patch in the spring of 2021 for Xft to not assume all the glyphs in a monospaced font to be the same size. Some fonts have ligatures which are glyphs that represent multiple characters together, so they’re actually some multiple of the base glyph size. Merged in the fall of 2022.