| > their upstream code is responsible 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] [0] https://github.com/nextcloud/documentation/pull/826 [1] https://github.com/cbsd/cbsd-wwwdoc/pull/12 |