How should a bug tracker be managed?
Posted: Thu Oct 25, 2018 6:32 pm
After much emotional discussion about a particular project, this thread is started to try to discuss pros and cons of particular bug-tracking strategies.
Listed criticisms of some projects trackers mostly centered around not closing old bugs (10+ years old), common explanation being the devs aren't taking the time to maintain their trackers. Reasoning for the criticism is that it makes the project look like it is not supporting users properly (particular to the project was that they use a paid support model, note that the GPL explicitly states that programs don't come with support, yet many developers have a desire to offer it).
So lets have some discussion (without attacking developers) that might actually help devs improve their project management. Feel free to use specific examples, discuss other bug-tracking practices or strategies you like or dislike, the reasoning, and/or explanations for status quo. How to encourage more and better bug reports and patch contributions is of course within scope of the topic.
Listed criticisms of some projects trackers mostly centered around not closing old bugs (10+ years old), common explanation being the devs aren't taking the time to maintain their trackers. Reasoning for the criticism is that it makes the project look like it is not supporting users properly (particular to the project was that they use a paid support model, note that the GPL explicitly states that programs don't come with support, yet many developers have a desire to offer it).
So lets have some discussion (without attacking developers) that might actually help devs improve their project management. Feel free to use specific examples, discuss other bug-tracking practices or strategies you like or dislike, the reasoning, and/or explanations for status quo. How to encourage more and better bug reports and patch contributions is of course within scope of the topic.