Then you're not going to the good people. Stop going through intermediaries, go straight for the source (package specific issues on Ubuntu must be reported to Ubuntu -like python not recognizing a new module-, but bad code inside the package must be dealt with with upstream).
> Half the time the developers are extremely resistant to changes and believe the change is wrong/unnecessary, or the current state is already correct, or that the changes are too big and/or not worth it, [...]
That's why I take the habit of jumping on IRC first, talking with devs a bit and trying to understand why I find a specific piece of code problematic.
I was trying to add support for i686 on an AUR package I maintain; quickly dismissed "we don't support i686 anymore anyway, just slap comments in your PKGBUILD and ship it".
I was working with the btrfs(8) util, which has the most horrific interface ever designed; "OK, we're not hostile to a new interface design, but you'll have to provide a comprehensive explanation of what you want and how it should behave".
And finally, documentation usually gets merged real fast (recently on cbsd(8) and nextcloud).[0][1]
