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.

My experience, ymmv, the most work went into configuring everything you need or want the first time. The right drivers for your graphics card, for your webcam, wifi, acpi multimedia keys, etc. Though I don’t use a gnome/kde/DE, so some of that may automagically work for you. After that though, updates don’t tend to break the things you’ve already fixed.

One time in 5 years the names of some acpi keys changed, and I had to update the script, and that wasn’t really arch’s fault. Also Google did a funny thing with their monospaced font that xft couldn’t handle, again not an arch specific thing.

And here’s a hot take for you, I only update about every 18 months. That’s usually how long it takes Discord to become binarily incompatible with installed libraries. Update the keyring first and never a problem.