Evan ProdromouProgrammers only: if you find a bug in someone else's software that affects your project, which of these things do you do? Select all that apply.
Workaround
Issue/bug report
Pull request
Other (please specify)
Poll ended at .
Thanks, all. I always do a workaround. I try to report it first, so it doesn't get forgotten, because once I have a workaround my incentive for doing the report goes way down. I'll occasionally do a PR, especially if there are unit tests or I can test manually pretty easily.
Chris Cantrellonce you have the workaround it stops being a bug and becomes ambient furniture. report-first is the only system that survives contact with the solution.
Usually fix it myself and feel briefly superior before remembering I have three bugs of my own I haven't filed tickets for.
Nicolas Constant@evan it's all the cases for me: I will do a workaround or chose an alternative in the first time.
Then it depends on the project, often I'll check if the issue is known (and it's the case 99% of the time), if not maybe I'll open one, and more rarely even I'll do the fix myself with a PR.
Then it depends on the project, often I'll check if the issue is known (and it's the case 99% of the time), if not maybe I'll open one, and more rarely even I'll do the fix myself with a PR.
James 🦉 #FBPE 🇪🇺@evan There's what I should do, and then there's what I do do
@freequaybuoy Scathing Mastodon post?
Ygor@evan It depends on the project and my mood, really. I'll open an issue if there isn't already one and if I feel like someone will actually care, and I'll try to fix it myself if I feel like I might be able to, within the time I have, and that it will actually be reviewed and merged. Otherwise I'll just try to work around it. Often there's already an issue that has been open for 5+ years, so there isn't much else to be done.
Jyrki 
penryu
jasonkarns@evan “patching” could be considered a workaround, but I think they’re different. A workaround deals with the buggy behavior or output within your own application’s boundary.
A patch jams the fix into the library so your own application can cleanly observe “bug free” behavior.
(Not always possible or viable)
@jasonkarns what about software not under your control? For example, a network service or API that you use, or a reader for a file your software creates?
@evan I meant the patching for stuff not under my control (libraries, primarily). in dynamic langs that allow post-facto modification, that is.
For a network service, one might consider an MITM “proxy” or adapter to be a form of patch, though that’s almost indistinguishable from a workaround. (Just a matter of degree, I suppose).
@evan Keeping the workaround isolated so that MY app is as ignorant of the patch as possible, is the key factor. It allows trivial removal of the patch/workaround once the behavior is fixed upstream.
manchicken@evan I have a conversation with them like a grownup and try to see how they would like me to handle it. I’m no fan of duplicated effort, and I don’t want someone to think I’m being pushy. It might also not be a bug, and I might be misunderstanding something important.
I love PRs, but sometimes just talking to someone is the best first step.
Caden@evan sometimes if it requires structural changes to the codebase or if my quick fix has a performance hit that I'm ok with I'll just fork it and use my version. Usually I just want to get a workaround as fast as possible so I'm not in the right headspace to write a good issue/bug report. That comes later (sometimes I forget though)
halcy​ 
@evan bug report if I'm sure it's a bug, workaround if I'm not or it is the "Feature Gap" type of bug rather than the "obvious defect" type of bug, pull request if I have the time to do it
Xavier@pekan How is that "other"?
@pekan Oh, and also: after you do the workaround, what is your motivation to make the bug report and PR?
@evan I’ve had a few instances recently where the workaround involves more work (but still doable) that could be easily solved in the dependency. If it’s possible to do a bug report it is done, and then maybe after depending on the findings it can also be fixed via a pull request.
@pekan I find myself often building a workaround and then not bothering with the bug report. And sometimes, when I'm researching the bug, I'll find workarounds in other projects for the same problem. We all work around it, instead of getting the bug fixed.
@evan I literally try to do all of them, not just one … but maybe that’s not what you were looking for as “other”
Brooke Vibber 
@evan workaround first. if i think the project might be responsive, file a bug report. if i think they'd take the patch and i know how to git 'er done, i might do a pull request.
however the patch review/release cycle on dependencies is often very slow, which is why i can't rely on a patch making it in and being usable in time to use it _now_ without a forked/patch dependency
which is why the workaround is generally mandatory, not an optional step :D
Abraham Williams@evan I've done all of them. Others is usually complaining on social media.
rj
babble encatFor a small project with short code I've sometimes just submitted a PR. If the PR is long then a bug report would be appropriate too
If the project is big with lots of developers and i don't know them, I'm hesitant to even report bugs. I saw a bug in #CoMaps yesterday but i haven't figured out how to report it and i could use a hand walking through that.
If I'm paid then I'll reach out to big projects though. But for personal stuff i get a little social anxiety
az
kepstin@evan one annoying case when you're dealing with long term support Linux distros is that you might have an old version of software with a bug that has long since been fixed, but it's not a "security" issue, so the only thing you can really do is work around it.
I do generally try to report issues if I'm working with newer software, tho I might still need a short term workaround too. PRs are less common but I've done a few.