We should focus on a smaller number of issues

[jmfayard]

This is my current understanding of the problem. Please provide feedback whether I'm missing something.

We currently have 78 open issues, and I love that the project is popular. But also I know that restically we will never be able to implement all of them. Or even most of them. Nor we should. Focused software beats kitchen sink software. Brute force only leads to burn out. And burn out is really bad, believe me.

[jmfayard]

Possible solutions:

• Let lots of issues opened but focus on a project with a sub-selection of issues
• Identify what are core features that define the essence of refreshVersions and focus on that at the expanse of nice-to-have or add-a-configuration thing
• Invest time in making our workflow simpler so that maintenance is less overwhelming
• Being realistic about our time and energy, and honest in telling people more often that we don't have the bandwith to implement this, so unless someone takes it up or sponsor us, it probably won't happen.
• Add the stale bot https://github.com/apps/stale

[jmfayard]

@LouisCAD what's your opinion about GitHub stale bot? https://github.com/apps/stale

[LouisCAD]

I'm not sure about the stale bot.

I'm generally skeptical of bots that lack the smarts of humans being that have more context. Also, we have much fewer issues per maintainer than Gradle.

I personally think having relevant but non prioritized issues is fine, we can keep them open, I don't see it burning me out personally.

People can vote, and if we have no priorities (which hasn't really been a thing so far), we sort the issues by 👍 count and take on what we want from here.