[mehrdadn]

This. And the benefit is it's easy to add your own fixes to your local version too. Stuff like removing the PerformSelfTest() call, adding items to the ListView in batch, item bounds checking when refreshing the ListView, etc. can quite noticeably speed up the UI, and random window focusing/sizing issues aren't too hard to fix either.

[sebazzz]

You might also consider submitting such changes as a patch to Dominic, the developer.

[mehrdadn]

In a perfect world I would love to, but every time I've tried to submit improvements to open-source software I've come out extremely frustrated with how many hoops I have to jump through just to get my code properly considered, let alone merged. 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, or that their upstream code is responsible, etc., and the other half the time they're admittedly quite welcoming but present hoops that on my end I simply don't feel like jumping through (like putting more personal info on the internet than I care to), especially when I'm already going out of my way to help people. Maybe you'd think the problem is with me, or maybe Dominic would be an exception in all regards, but wherever the problem is, I've grown very reluctant about the idea in general, so I just fix bugs on my own computer and let someone else who cares & has the time/energy to put up a real fight fix the issues for everyone else.

[moviuro]

> 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

[mehrdadn]

I assure you I'm not naively just dumping code on random developers and telling them to merge it. I do talk to them first, that's exactly how I figure out they think their code is fine and my changes are unwelcome whenever that's the case. (Edit: Well, mostly. It's also happened that my changes were rejected after I made the patch, but that was nevertheless after discussions had already taken place. Like when I said they later decide the patch is too big.) And regarding the upstream project issue: in the case I had in mind, the upstream project had its own reasons for not doing things the way I mentioned. The changes really did belong in the downstream project, but the downstream guy just didn't care to have to maintain the changes. Although, I also have to point out that upstream projects tend to present even more obstacles for merging code -- not only when the entire reason there's a downstream fork is that upstream is not going to support the entire platform/architecture/whatever, but also when they're big projects with their own hoops I don't care to jump through on my end as I explained earlier.