4 ms·

There's (at least) four Fs, and the first in the list should be "File it". Not every open source user is a developer who can Fix it or Fork it, but a well-writ

by pdpi 4y ago

There's (at least) four Fs, and the first in the list should be "File it". Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.

obert 4y ago
Add “Find it”, eg try debugging and provide some starting points about where/what the root cause might be
sixhobbits 4y ago
That's literally the first sentence of TFA > your first option is to make a request to fix it. Raise the issue in the bug/request tracker of choice.
- pindab0ter 4y ago
  I'm sorry, what's "TFA"?
  - Doctor_Fegg 4y ago
    The Fabulous Article
  - tdrgabi 4y ago
    The fine article
  - dmolony 4y ago
    Presumably 'The Fucking Article'
  - tpoacher 4y ago
    The Fantastic Article
ZeroGravitas 4y ago
I find that I do this less than I would otherwise, because I'm not sure if it will be interpreted as a demand that they fix it immediately, either by the developer who may already be dealing with entitled users or just feel compelled to help users of their software, or by random passer bys who use open 'bugs' as a metric to attack people with. It would be neat if you could contribute information on issues, suggested fixes, workarounds with some guarantee that it was in a format that would actually help the maintainer, rather than stress them out. Usually I just end up spending a reasonable amount of time thanking them, explaining that what I've noticed isn't a big deal for me, just something I think they might want to be aware of etc. But some systems should be put in place for this, like being able to tag issues as "I see this bug too" but also seperately "this is important to me" so widespread, but low priority issues can be prioritised and information gathered.
raro11 4y ago
And then you see it get marked as stale and closed after a month of inactivity. I hate that practice with a passion. I don't care there are 1000 issues open. I do care there are 1000 unresolved issues closed by a bot. I should create a bot that auto-replies "I believe this is still unresolved" for issues I have under the "File it" category!
- sph 4y ago
  "Beep boop! This issue hasn't had activity in 7 days. It will automatically close in 24 hours." I wish this bot had a physical manifestation so I could hit it with a wrench. "Issue closed as resolved by stupid-bot." And another +1 to the end-of-year KPI slides.
- mariusor 4y ago
  I think that's because maintainers consider tickets as action items for them personally instead of treating them as feedback documenting known issues(sometimes with workarounds) for their users. I think DeVault put it very well a while back: a ticket is the place where the community can gather and exchange feedback on a perceived issue with a project (I'm paraphrasing).
NohatCoder 4y ago
I really don't understand OSS maintainers that encourage or require people to fix or change things themselves. For a small patch the work of ensuring that the work of a new contributor is good enough is easily greater than just writing the patch yourself. And the time the contributor spent is likely much more. Give me someone who does enough work that they get well acquainted with the code, or none at all.
- devjam 4y ago
  Unless it's time-sensitive/critical, from the point of view of an OSS maintainer why should it matter whether a patch took 3 days to develop, or 3 minutes? As long as the quality and correctness is consistent across those patches, as a maintainer I'd encourage a wider base of developers who are fluent in my codebase, even if their initial PRs took slightly longer.
- veltas 4y ago
  On most larger projects the 3 minute fix is more like 10-20 minutes depending on workflow, and they have many such issues in the backlog already. And most of the people who know your issue well enough to fix it that quickly are unpaid volunteers using their limited free time. If you can ever actually encourage someone to fix something themselves, they just became a developer. They now have a non-zero chance of fixing other issues, or otherwise contributing. So it makes perfect sense to try and encourage people to contribute themselves, whenever possible. What doesn't make sense is insisting when you could actually fix it yourself, you have time, motivation, etc, you just feel they don't deserve the fix.
- samsquire 4y ago
  The maintainer can implement your features faster than you can, but does that mean they should, or that it is fine for you to expect them to? Nope, it isn't right. They are separate people from you and they decide what they work on, not you.
- NohatCoder 4y ago
  For anyone in doubt, I'm saying this as a maintainer, random people's patches on average suck. Taking those patches is likely to cost me more time than they save. So why would I be adamant about encouraging strangers to write patches?

by pdpi 4y ago

obert 4y ago

Add “Find it”, eg try debugging and provide some starting points about where/what the root cause might be

sixhobbits 4y ago

That's literally the first sentence of TFA > your first option is to make a request to fix it. Raise the issue in the bug/request tracker of choice.

pindab0ter 4y ago
I'm sorry, what's "TFA"?
- Doctor_Fegg 4y ago
  The Fabulous Article
- tdrgabi 4y ago
  The fine article
- dmolony 4y ago
  Presumably 'The Fucking Article'
- tpoacher 4y ago
  The Fantastic Article

ZeroGravitas 4y ago

I find that I do this less than I would otherwise, because I'm not sure if it will be interpreted as a demand that they fix it immediately, either by the developer who may already be dealing with entitled users or just feel compelled to help users of their software, or by random passer bys who use open 'bugs' as a metric to attack people with. It would be neat if you could contribute information on issues, suggested fixes, workarounds with some guarantee that it was in a format that would actually help the maintainer, rather than stress them out. Usually I just end up spending a reasonable amount of time thanking them, explaining that what I've noticed isn't a big deal for me, just something I think they might want to be aware of etc. But some systems should be put in place for this, like being able to tag issues as "I see this bug too" but also seperately "this is important to me" so widespread, but low priority issues can be prioritised and information gathered.

raro11 4y ago

And then you see it get marked as stale and closed after a month of inactivity. I hate that practice with a passion. I don't care there are 1000 issues open. I do care there are 1000 unresolved issues closed by a bot. I should create a bot that auto-replies "I believe this is still unresolved" for issues I have under the "File it" category!

sph 4y ago
"Beep boop! This issue hasn't had activity in 7 days. It will automatically close in 24 hours." I wish this bot had a physical manifestation so I could hit it with a wrench. "Issue closed as resolved by stupid-bot." And another +1 to the end-of-year KPI slides.
mariusor 4y ago
I think that's because maintainers consider tickets as action items for them personally instead of treating them as feedback documenting known issues(sometimes with workarounds) for their users. I think DeVault put it very well a while back: a ticket is the place where the community can gather and exchange feedback on a perceived issue with a project (I'm paraphrasing).

NohatCoder 4y ago

I really don't understand OSS maintainers that encourage or require people to fix or change things themselves. For a small patch the work of ensuring that the work of a new contributor is good enough is easily greater than just writing the patch yourself. And the time the contributor spent is likely much more. Give me someone who does enough work that they get well acquainted with the code, or none at all.

devjam 4y ago
Unless it's time-sensitive/critical, from the point of view of an OSS maintainer why should it matter whether a patch took 3 days to develop, or 3 minutes? As long as the quality and correctness is consistent across those patches, as a maintainer I'd encourage a wider base of developers who are fluent in my codebase, even if their initial PRs took slightly longer.
veltas 4y ago
On most larger projects the 3 minute fix is more like 10-20 minutes depending on workflow, and they have many such issues in the backlog already. And most of the people who know your issue well enough to fix it that quickly are unpaid volunteers using their limited free time. If you can ever actually encourage someone to fix something themselves, they just became a developer. They now have a non-zero chance of fixing other issues, or otherwise contributing. So it makes perfect sense to try and encourage people to contribute themselves, whenever possible. What doesn't make sense is insisting when you could actually fix it yourself, you have time, motivation, etc, you just feel they don't deserve the fix.
samsquire 4y ago
The maintainer can implement your features faster than you can, but does that mean they should, or that it is fine for you to expect them to? Nope, it isn't right. They are separate people from you and they decide what they work on, not you.
NohatCoder 4y ago
For anyone in doubt, I'm saying this as a maintainer, random people's patches on average suck. Taking those patches is likely to cost me more time than they save. So why would I be adamant about encouraging strangers to write patches?