A demotivating pattern in quite some open source projects: New user notices a bug, opens issue with detailed description, a few minutes later someone from the project comes and declares "Ah, yes a duplicate of #6754" and closes the issue.
-
A demotivating pattern in quite some open source projects: New user notices a bug, opens issue with detailed description, a few minutes later someone from the project comes and declares "Ah, yes a duplicate of #6754" and closes the issue. Meanwhile #6754 is open since 2 years and still not any closer to being fixed.
I'd say that if a certain threshold of # of issues combined with "staleness" is reached, the project should announce a bug fix festival week to bring down open issues. 1/3
-
A demotivating pattern in quite some open source projects: New user notices a bug, opens issue with detailed description, a few minutes later someone from the project comes and declares "Ah, yes a duplicate of #6754" and closes the issue. Meanwhile #6754 is open since 2 years and still not any closer to being fixed.
I'd say that if a certain threshold of # of issues combined with "staleness" is reached, the project should announce a bug fix festival week to bring down open issues. 1/3
Bug triage should NOT mean to try to find duplicates, IMHO. The total number of open issues should NOT be growing beyond the projects capacity to get them fixed. Every issue should be clearly defined and not become a collection of related things, because that makes a fix less probable. The average age of open issues should typically be less than 7-10 days. 2/3
-
Bug triage should NOT mean to try to find duplicates, IMHO. The total number of open issues should NOT be growing beyond the projects capacity to get them fixed. Every issue should be clearly defined and not become a collection of related things, because that makes a fix less probable. The average age of open issues should typically be less than 7-10 days. 2/3
When issues stay open for too long, the code may have already developed too far away from a fix. So older issues typically need a complete re-evaluation to see if the problem still exists and the proposed solutions are even possible now. This causes exponential waste of time and resources, in my experience, leading to issues that stay open or unsolved for years. 3/3
-
A demotivating pattern in quite some open source projects: New user notices a bug, opens issue with detailed description, a few minutes later someone from the project comes and declares "Ah, yes a duplicate of #6754" and closes the issue. Meanwhile #6754 is open since 2 years and still not any closer to being fixed.
I'd say that if a certain threshold of # of issues combined with "staleness" is reached, the project should announce a bug fix festival week to bring down open issues. 1/3
@jwildeboer a bugfix festival sounds fun but realisticly does not change a lot. The old issues are often old because they are complicated or otherwise challenging. All projects suffer from such issues with no easy remedy. We just have to accept that every once in a while a dupe issue is reported. That's life.
-
@jwildeboer a bugfix festival sounds fun but realisticly does not change a lot. The old issues are often old because they are complicated or otherwise challenging. All projects suffer from such issues with no easy remedy. We just have to accept that every once in a while a dupe issue is reported. That's life.
@bagder Sure. And quite a lot of issues are in reality feature requests that should be handled in a different way, I know that all too well. But looking at a project with 800+ open issues and an open issue growth rate of around 25 per week combined with a closure rate of less than 10 per week tells me a story of growing frustration and loss of control that never leads to a good outcome
The bugfix festival idea might help in creating awareness, at least. -
Bug triage should NOT mean to try to find duplicates, IMHO. The total number of open issues should NOT be growing beyond the projects capacity to get them fixed. Every issue should be clearly defined and not become a collection of related things, because that makes a fix less probable. The average age of open issues should typically be less than 7-10 days. 2/3
@jwildeboer For a big project you often have issues open for a long time because they have to be fixed as part of a bigger set of work. If you have a well written piece of software you should have few short duratiojn issues because the bugs like that shouldn't exist in the first place but plenty of long duration issues because they will be around functionality and integrated in a proper planned and tested manner.
-
@jwildeboer For a big project you often have issues open for a long time because they have to be fixed as part of a bigger set of work. If you have a well written piece of software you should have few short duratiojn issues because the bugs like that shouldn't exist in the first place but plenty of long duration issues because they will be around functionality and integrated in a proper planned and tested manner.
@etchedpixels Absolutely. But the issue trackers in Github/Gitlab/Forgejo don't have a good way of separating those long-term issues from short-lived ones. Heck, typically feature requests and bug reports are in the same issue tracker, recognisable only by arbitrary subject line keywords. Good issue management is an art form of its own, IMHO, that is often not handled with the love and care it deserves (and needs)
-
When issues stay open for too long, the code may have already developed too far away from a fix. So older issues typically need a complete re-evaluation to see if the problem still exists and the proposed solutions are even possible now. This causes exponential waste of time and resources, in my experience, leading to issues that stay open or unsolved for years. 3/3
@jwildeboer@social.wildeboer.net I disagree, the solution to an issue list growing faster than the project's capability to handle them, is not "the devs should work harder".
In the OSS world, the devs need to be paid more, the project needs more funding, or perhaps the project might need help organizationally.
Almost always our stale issues require refactors that change the calculus of work vs reward. We will not refactor entire systems to fix small UI workflow bugs, for example.
Also, PRs welcome 🥲
