Issue tracker cleanup

[msfjarvis]

Our issue tracker has hovered around 30 open issues for nearly 3 years now. Most of these are very old issues for features that were proposed 2 to 5 years ago and have not been implemented yet.

As basically the lone developer on the project, I find little to no value in keeping issues around that I have no intention of fixing. I simply cannot work on big features that I personally have no motivation to add to the app, so I'm closing all the issues that fall into the category.

If your issue was closed with a link to this page, it simply means I have no reason to implement it myself. It does leave the door open for external contributions, which I will dutifully try to review as long as I'm working on this app. If you want to see any of these features in the app, you'll need to write the code yourself, and I can only offer my abilities as a reviewer.

[Lord-Valen]

I think a better approach to these issues would be a wontfix or prwanted label to signal that you won't be working on these features but are open to others implementing them.

[msfjarvis]

I reserve the wontfix label for issues that will actually never be fixed because the proposal does not add value or does not align with the project's direction. Closing issues with a link to this discussion IMO best communicates the reasoning and intent behind the decision and better explains the status quo than a single label.

[pataquets]

Although the reasoning behind closing issues it's 100% understandable, I agree with @Lord-Valen , specially bc closing loses track of the feature/idea/suggestion. If wontfix is not an acceptable label, so be it. Just using another label (prwanted or help wanted) would do for the purpose of avoid "losing" issues.
The idea to link here for issues labeled as such is a very good one, thou. Thanks for sharing this software!

[msfjarvis]

The issue tracker primarily serves me, and secondly the community. If the signal to noise ratio of the issue tracker (i.e. things I want to do versus things I will likely never look at) is poor then it impacts my ability to properly use my time on the project. Closing an issue moves it out of my primary to-do list where it does not belong and keeps it around for others to search and look at. Putting a 'help wanted' label indicates that an issue is something I want resolved but can't do myself, which is not the case for the issues I've closed as part of the cleanup.

[pataquets]

Sure. Fair enough. Also, I didn't thought on the implications of a help wanted label, good call.
I understand your desire of moving the issues out of sight for tidiness, and I guess that this also takes labels out of the equation.
In that case, the only thing I see to avoid losing the issues is converting them into discussions and state clearly (in the issue template?) that they're not binding for the maintainer, so ppl should be ready to code themselves. That would also avoid ppl wasting their time or, worse yet, yours. This way, both separation is kept and it also conveys the intent of issues=tasks/support and discussions=ideas/proposals.

[pataquets]

For your convenience, I would suggest thinking about using Github's issue templates to clearly stating upfront your policy, maybe linking here, too. HTH.

[msfjarvis]

That is a good idea, I'll look into it.

[pataquets]

I'd like also to suggest using #numbered links when referencing this issue links to keep track of closed/declined issues with the automatically added crosslinks.

[msfjarvis]

This is a discussion not an issue and thus does not generate crosslinks.