Timeline for Responsibility to reproduce bugs
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2013 at 6:06 | comment | added | jmoreno | @user626528: It's not about ego, it's about priorities -- inability to reproduce a bug lower's it's priority. Given two EOI (Execute Operator Immediately) bugs, one reproducible and one not, I would work on the one that can be reproduced first, and I would tell any other developer to do the same. And if the library isn't used that much, I might work on another project entirely -- even if the bugs in it are not as significant. If he is /solely/ being paid to work on this library AND there are no outstanding feature request or bugs other than this one, then yeah he should just do it. | |
| Jun 12, 2013 at 2:37 | comment | added | user626528 | too much ego. He is paid to work on that freaking library. | |
| Jun 11, 2013 at 19:10 | comment | added | jmoreno | Since YOU are the one that wants it fixed now, it's your responsibility to convince him that it is worth HIS time fixing it now, instead of in 10 or 12 years when he doesn't have anything else more important to fix. theregister.co.uk/2013/01/21/kde_bug_quashed. Given an unreproducible bug, of significance X, and a reproducible bug of the same significance, I will work on the reproducible bug every time. | |
| Jun 11, 2013 at 2:45 | comment | added | user626528 | You answer looks very strange for me. I'm fixing my bugs on my own, and don't wait for someone to do dirty work instead of me. I'd say it's primary responsibility of code author to do his best to fix his code. | |
| Jun 10, 2013 at 19:33 | history | answered | jmoreno | CC BY-SA 3.0 |