I’ve noticed that I’ve kind of unintentionally enacted a new policy: I won’t open issues for bugs that are likely very rare issues for the microbe stage.
Like a year ago or so I used to basically always open a new issue whenever someone reported a bug or a weird thing, but every now and then looking at our issue backlog I’ve noticed that we’ve had some issues open for 3-4 years without anyone trying to solve them or anyone at all noticing the bug at all. So I’ve started to wonder what is the point of opening an issue for a bug that nobody will see again within 4 years? Is there any point to such issues being in our backlog?
So I kind of wanted to talk about this and hear opinions from other people. Should I switch back to just always opening an issue whenever there’s a bug report, even if I think it will be one of those issues that will ever be reported just once and never actively worked on and fixed? With such issues only really getting closed years and years later when they are either randomly fixed or I think there’s likely a chance it might have been fixed and we can wait until it is reported again.
It’s kind of weird how a big fraction of bug reports are bugs that only a single person notices in a feature that has been basically unchanged for 1-2 years, and then if opened as an issue nobody seems to find the same bug for years. Of course “popular” bugs or bugs in new features are different and I’ve been keeping up with either fixing those immediately or opening an issue.
I’ve also now thought that it might be reasonable to have either of these policies:
Any bug report for a feature that hasn’t been changed in a year (so the bug was likely present but unnoticed for this long) requires a second bug report about the same issue from a different person / a team member creating a bug reproduction case before an issue is allowed to be opened.
Issues are opened for any bug but any bug that is for code older than a year will be marked specially and if there is no second report within 1-2 years the issue is just silently closed and again ignored as an insignificant problem.
These would give some balance between our backlog expanding with issues that affect very insignificant number of people, and mostly ignoring older bugs.
I agree. I also noticed some old issues turned out to be Godot-related and have been solved with the newer versions of the engine, so having a time threshold to close the issues as “stale” (or something like that) would be beneficial to clean up the todo list from issues that don’t actually exist anymore.
It would also help new contributors that may end up tackling older issues that are no longer reproducible, avoiding wasting their time.
I basically agree with that.
And I was thinking about adding a bot to automatically find related issues, so that if there’s a second report and the first report is stale or closed, we can still connect them.
Note on the issues though is that before an issue is opened the opener has to look for duplicates. So duplicates should be prevented by searching. I don’t see another way to prevent them.
Actually, being a bit lazy I realized that I can just make this as a github automatic action, so it’ll be very easy to do, and so I have created the tag and this PR will add the workflow to run it:
Also I created a “triage” tag for user-created reports so that a team member can then remember to add the “more-reports-wanted” tag which marks these issues that have only been seen once and not confirmed by a programmer.