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.

I too have had idle thoughts about what lessons to pass on and what was lacking in my own formal education.

My elevator pitch is to have a semester long project broken down by feature. You get a couple weeks to develop, but after each one is complete you have to trade code bases with someone else in the class. It’d teach both how to work in an established code base, and how to be kind to some future maintainer (who might be yourself).

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.