Changing our stale issue policy 🙋

Hey everyone 👋

Some time ago, I introduced an automated stale workflow to help keep the issue tracker manageable and to encourage activity on older issues.

The intention was good: surface issues that were still relevant, get feedback from people experiencing the same problems, and hopefully encourage contributions.

However, after using it for a while, I don't think automatically closing issues simply because they haven't received recent activity is the right approach for Gogh.

An issue can still be valid even if nobody has commented on it for months — or even years. Closing it automatically can also make useful reports harder to discover and may discourage future contributors from picking them up.

What is changing

Going forward, issues will no longer be automatically closed solely because of inactivity.

Older issues may occasionally receive a comment asking whether they are still relevant. If you encounter the same problem or would like to see a feature implemented, a 👍 reaction, comment, additional context, or — even better — a pull request is always welcome.

Issues that are waiting for information from the original reporter may still be closed after a reasonable period if the requested information isn't provided.

Pull requests may continue to use a stale policy, since long-lived PRs are more likely to become outdated as the codebase changes.

About issues previously closed as stale

If you find an issue that was automatically closed but is still relevant, feel free to comment on it or open a new issue referencing the original one. We can reopen useful issues when appropriate.

Thanks to everyone who has reported bugs, suggested improvements, submitted themes, and contributed code to Gogh over the years. ❤️

The goal is to make the issue tracker useful not only for maintainers, but also as a place where future contributors can discover things worth working on.

No file, test, or entry point is named. The issue explains the desired stale-policy outcome and exceptions, but does not identify where the workflow or related documentation lives; completion criteria would need to be established before implementation.