#FOSS etiquette question
I run into this situation pretty often: I encounter a bug in a FOSS project that has a codebase I don't know well, but I find a workaround that solves my particular use case. I'd like to be helpful and report the bug, but getting it fixed won't really benefit me and I'm not willing to submit a PR.
So here's the question: is there a concise way to report the bug as a FYI for the maintainer, while making it clear that I'm not asking them to do anything for my benefit?
@codesections just leave a matter-of-fact bug report concicely explaining the problem and reproduction steps without necessarily addressing anyone (e.g. the maintainers). Keep it professional and sterile and it won't imply any expectations.
Subject: frobnicator terminates early if the input does not end with a newline
printf 'input' | frobnicate # note lack of \n
> Keep it professional and sterile and it won't imply any expectations.
I'm not 100% sure I agree.
Maybe I'm projecting, but when I get a bug report, there's a part of me that thinks "oh no, a user of software I wrote has run into a problem because of a mistake *I* made. I'd be doing them a favor if I fix it!"
And if the maintainer thinks they're doing the user a favor *and* the user thinks they're doing the maintainer a favor… well, that seems to be the path to miscommunication
@codesections no one's doing anyone a favor. Recording bugs is just a part of the process of software development.
@sir @codesections I for one *appreciate* a good bug report; it's much better than someone just bitching that my code doesn't work, and with a hard-to-reproduce bug a good bug report can give me that clue as to how to get a reproduction; also if you have people who pay for support, it's really nice when someone gives you a bug report before a paying customer hits it and shouts at you!
> no one's doing anyone a favor. Recording bugs is just a part of the process of software development.
That's probably a good attitude to have (and is probably healthy/helps prevent burnout).
I've never quite managed that detachment; when someone fixes a bug that was causing me a lot of trouble, I feel personally grateful; when someone runs into a bug with my software, I feel like I'm letting them down.
(I'm not endorsing those feelings; just reporting them)
@codesections "Hi, thank you for $X, it's mighty useful! I ran into the bug below, which I managed to find a workaround for, so I do not have a problem anymore. Nevertheless, I figured I'll let you know what I ran into, and how to work it around, in case anyone else ends up in a similar situation.
<description of bug & workaround>"
I've received similar reports, they're very valuable. I can see it's not a prio, but it allows others to chime in later, if the workaround isn't ok for them.
> "Hi, thank you for $X, it's mighty useful! I ran into the bug below, which I managed to find a workaround for, so I do not have a problem anymore. Nevertheless, I figured I'll let you know what I ran into, and how to work it around, in case anyone else ends up in a similar situation. <description of bug & workaround>"
Thanks, that's a helpful template. I've used a similar approach, but not managed to be quite that concise, so that's helpful :)
@codesections Just report the bug! Add a note about the workaround; that workaround might help others as well.
@codesections just submit an issue/bug with your reproduction steps and how you worked around it. If the maintainers think it needs priority and a fix they’ll fix it or ask you if you can. If they don’t at least there’s a crumb for other users to follow when they run into the same problem.
@codesections recording your workaround along with the bug could be helpful for other people running into the same thing while at the same time signalling to the maintainers that this is not an urgent problem for you anymore?
@codesections If you document a bug along with the workaround this is very helpful for those users which do not directly find the workaround (me, typically), as searching for the bug might point them to your solution. Unless the software has a clearly associated user forum, the code issue tracker should be the best place to ease use for others... unless the software has a manual, then mention the issue + workaround there and possibly create a PR for the document only?
@codesections as others have said, make it a good bug report including how it happened. If you can narrow things down all the better.
The latest WordPress one I mentioned today was a good example.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.