3 ms·
Ignoring is one tool. Another one I have to (sometimes/more often than I'd like) resort to (especially at work) is a simple "No". The "No" is especially fun to
by White_Wolf 6y ago
Ignoring is one tool. Another one I have to (sometimes/more often than I'd like) resort to (especially at work) is a simple "No".
The "No" is especially fun to use with people have the wrong impression that if you know how/can to do something you actually have to do it for them whenever they request it.
That being said:
For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it.
- MaxBarraclough 6y ago> For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it. Also, your project is better off for having the bug reported, even if it's never fixed. Known bugs are less of a problem than unknown bugs, especially if clearly documented. With legacy systems, it might even be impractical to fix the bug, as other code may rely on the original buggy behaviour.
- pessimizer 6y agoYeah, if you know the bug is there, it's often easy to write around it. Even completely ignored issue queues are useful.
- phkahler 6y agoBugs can also be categorized over time. Sometimes the solution becomes clearer over time with multiple related examples. In other words, it's easier to fix by accumulating issues instead of digging around with a debugger. This is facilitated by having no obligation to fix it now.