Being a Linux distribution maintainer, there is a specific kind of work which is so crucial for maintaining a good distribution – It is to apply small tweaks to an otherwise upstream package which makes it work in the distribution, over time, these tweaks grow due to expanding use cases e.g. new processor architectures, compiler versions getting added to name a few reasons. This can result in a significant amount of technical debt on distribution maintenance. Linux Distributions package 1000’s of packages and maintainers are not subject matter experts in all of them, therefore lot of these tweaks will be one-off contributions.
As packaging and version upgrade work is happening, the packages get exposed to new environments, e.g. a new version of compiler, or an alternative compiler, a different system runtime or architecture which might cause package to not build, usually fixes for such changes are small tweaks and they may be deemed insignificant and hence ignored, but it’s prudent to open a link with upstream community of the respective package and bring it to their notice. It could be as simple as opening a ticket in issue tracker and describing the problem and a possible workaround. Even better, would be to open a pull request to get the patch merged upstream. Every package maintainer has limited resources to perform Continuous Integration and testing, therefore, it’s possible that the package is not regularly tested on all the distribution policy combinations, therefore, such patches help in code cleanup and keep it readily portable for newer compilers or other environments.
I classify this as code cleanup, so it is not as cool as developing a new feature or rewriting the whole package from scratch ( why not ), however, it helps the distribution to stay nimble and portable. There will be resistance at times to these cleanups, but this is no different than rejecting a feature request, with valid reasons, I consider that normal.
Sometimes, this also expands into fixing issues one finds while fixing completely different thing e.g. typo in a comment. I encourage you to fix these adjacent problems while you are here, and propose them as possible fixes via a set of patches in a pull request or a separate change set.
This can be a possible path for new developers to navigate packages that match their interests and contribute well tested patches using the distribution framework and perhaps become a significant contributor to a package overtime.