That's pretty much what I ended up doing. Install Gnu Make 4.4 as part of the pipeline. I then added a check to warn the user if the Make version they use is not supported.
Nowhere as convenient as using psql but you could try using Python or Perl to have a more civilised interaction w/ SQLite. For Python the module sqlite3 is already in the stdlib and for Perl just install perl-DBD-sqlite using your package manager.
I'm a software engineer by profession and passion and have been writing programs for well over 20 years now. I believe your experience is totally natural - at least I share the same feelings:
Large code bases take time getting to know and understand: most definitely true. It takes time and effort and is an investment you need to make before being able to feel confident. You don't need to fully comprehend every aspect of the project before you can contribute but you sure need to have a decent enough idea of how to build, test, run and deploy a particular feature. See point (2).
Don't let the size of the project intimidate you. Start small and expand your knowledge base as you go. Usually one good starting point is simply building the project, running tests and deploying it (if applicable.) Then try to take on simple tasks (eg from the project's issue tracker) and deliver on those (even things like fixing the installation docs, typos, ...) That'll have the additional impact of making you feel good about the work that you're doing and what you're learning. I'm sure at this stage you will "know" when you're confident enough to work on tasks which are a bit bigger.
During (1) and (2), please please do NOT be tempted to just blindly copy-paste stuff at the first sign of trouble. Instead invest some time and try to understand things, what is failing and why it is so. Once you do, it's totally fine to copy-paste.
After all, there's no clear cut formula. Each project is a living and breathing creature and "not one of them is like another." The only general guideline is patience, curiosity and incremental work.
That's usually true except that this project is about the Makefile itself 😁 I'm working on a set of useful recipes, targets and variables which I've always missed from Make's out-of-the-box offering - something like a stdlib/utils for Make.
And yes, as you may have already guessed, I've had to deal w/ Makefiles relatively frequently 😀
RE Travis: I feel quite comfortable and happy w/ Travis already. Additionally, I want to keep my reliance on github minimal. The only reason I'm using it is that it is where things are searched for and found by fellow programmers :-)
RE Container: My home machine is running Tumbleweed which's had Gnu Make 4.4 for a few months now already. I was trying to make the pipeline behave as closely as possible to the user's machine who may not have that version installed. Otherwise as you and @sugar_in_your_tea@sh.itjust.works mentioned, I could pack everything I'd need in a container.
Throughout the years, I always stuck with my own method of organising my config files with my own style which is all based on eval-after-load. Never felt any motivation to move my things to use-package as I am quite happy with what I have. Well, I feel like I should give it a fair shot now that it comes out of the box.
Not a direct answer I'm afraid but I use Tree Style Tabs. You can group tabs (in a subtree), move them to other windows (drag and drop), close them together, ...
It's helped me a lot keep my browser tabs tidy and grouped up by relevance.
I don't think you'll be able to achieve that with systemd paths, I'm afraid. It's not a use-case it is designed for.
It's hard to come up with a suggestion without knowing more about the depth of the directory and the number of nodes in each level. But you could try updating a dummy file such as latest_timestamp in the top-level directory (which a systemd path can monitor BTW) and let the service unit be triggered by that.
Did anyone actually take action?
I'm not sure how to, or if I'm supposed to, since I'm based in Canada.