# Thoughts on opening issues (bugs)
**URL:** https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257
**Category:** Meta
**Created:** [May 21, 2026, 9:02am UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257 "2026-05-21T09:02:06Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@hhyyrylainen](https://forum.revolutionarygamesstudio.com/u/hhyyrylainen)
#### Post date: [May 21, 2026, 9:02am UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257/1 "2026-05-21T09:02:07Z")
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.
So anyone have any thoughts on this dilemma?
---
### Author:  [@xfractalino](https://forum.revolutionarygamesstudio.com/u/xfractalino)
#### Post date: [May 21, 2026, 9:10am UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257/2 "2026-05-21T09:10:39Z")
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.
---
### Author:  [@CheviLevi](https://forum.revolutionarygamesstudio.com/u/CheviLevi)
#### Post date: [May 21, 2026, 9:30am UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257/3 "2026-05-21T09:30:32Z")
> [@hhyyrylainen](#):
>
> 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.
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.
---
### Author:  [@hhyyrylainen](https://forum.revolutionarygamesstudio.com/u/hhyyrylainen)
#### Post date: [May 21, 2026, 9:55am UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257/4 "2026-05-21T09:55:45Z")
I think a bot to manage this would be quite a good idea. We can run such a bot as part of the [GitHub - Revolutionary-Games/RevolutionaryWebApp: Web apps with features for Thrive development · GitHub](https://github.com/Revolutionary-Games/RevolutionaryWebApp)
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.
---
### Author:  [@hhyyrylainen](https://forum.revolutionarygamesstudio.com/u/hhyyrylainen)
#### Post date: [May 21, 2026, 12:41pm UTC](https://forum.revolutionarygamesstudio.com/t/thoughts-on-opening-issues-bugs/1257/5 "2026-05-21T12:41:40Z")
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:
>
>
> \*\*Brief Description of What This PR Does\*\*
>
> https://forum.revolutionarygamesst…udio.com/t/thoughts-on-opening-issues-bugs/1257
>
> \*\*Related Issues\*\*
>
>
>
> \*\*Progress Checklist\*\*
>
> Note: before starting this checklist the PR should be marked as non-draft.
>
> \- \[x\] PR author has checked that this PR works as intended and doesn't
> break existing features:
> https://wiki.revolutionarygamesstudio.com/wiki/Testing\_Checklist
> (this is important as to not waste the time of Thrive team
> members reviewing this PR). This includes \*\*gameplay\*\* testing by the PR author.
> \- \[\] Initial code review passed (this and further items should not be checked by the PR author)
> \- \[\] Functionality is confirmed working by another person (see above checklist link)
> \- \[\] Final code review is passed and code conforms to the
> \[styleguide\](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style\_guide.md).
>
> Before merging all CI jobs should finish on this PR without errors, if
> there are automatically detected style issues they should be fixed by
> the PR author. Merging must follow our
> \[styleguide\](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style\_guide.md#git).
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.