Close irrelevant issues

[woojiq]

So I read 8 pages of Issues and I can say that 20% of them are dead or fixed or have no information etc.

I think the maintainers should set a little stricter rules for issue management. If this does not happen, the number of Issue will soon exceed 1 thousand (which is a distraction from the real problems).

Here is some issue I recorded that IMHO should be closed (there are more of them, but I chose the most understandable ones). Someone take a quick look at them and tell me if I'm right about their invalidity:

• The creator didn't close issue himself (very common practice): new theme inherits directive does not allow for *unsetting* previously-defined options #5053
• The dead issue with a clear explanation of why this is not a bug: Numeric file suffix not visible #4975
• A possible solution was given + ignore: fails to build for powerpc-unknown-linux-gnu #4880
• The pr with this feature was declined: Write without formatting #4853
• The pr was merged but the issue didn't closed: ayu-Themes cursor has the same color as selection #4754
• Possibly solved by Pr + ignore: Helix editor ignores standard Linux mouse click paste of text #4511
• Intended behavior: Helix cannot delete the last blank line(s) of the buffer when the cursor is at the very last line #4433

Btw, this is very hard task to follow all issue, but ...

How to be an open source gardener:

This is one of the other things I had to kind of let go of when working on a real project: closing an issue isn’t forever. You can always re-open the issue later if it turns out you were wrong. So when trying to get a handle on 800 open issues, I defaulted to ‘guilty until proven innocent.’ Terminate issues with extreme prejudice. Leaving old, inconclusive issues doesn’t help anyone. If it’s a real bug that matters to someone, they’ll come along and help reproduce it. If not, maybe someone else will later.

[pascalkuthe]

Thank you for pointing out these issues. I agree with your reasoning and closed them.
I was planning to go trough issue and find which can be closed but it's a lot of work. If you run across an issue that can be closed, just leave a comment like "I think this issue can be closed, because XYZ". I receive notifications for every comment on the repo so I will know to close the issue if I agree.

However a majority a issues are feature requests/discussion that are not outright rejected but are also not concrete enough to be actionable (or nobody has the time to work on them). Oftentimes there are even multiple similar feature requests that are just different enough where I will leave them both open. So there is only so much you can do about th number of open issues.

@archseer mentinoed on matrix that it might be an option to remove most feature requests from the issue tracker and delegate design discussion to github discussion. Issues would only be actionable bug reports and tracking issues for "accepted" feature requests (which could run trough an RFC like process so we end up with high-quality actionable feature request issue).

I think that would be a nice improvement but such a policy can only be put in place by @archseer.

[woojiq]

just leave a comment like "I think this issue can be closed, because XYZ". I receive notifications for every comment on the repo so I will know to close the issue if I agree

Ok, Ill continue to look at old issue time to time. I could mention someone earlier (under the issue), but I didn't want to be super annoying. Since you give me the "rights" to do it now, I will :)

@archseer mentinoed on matrix that it might be an option to remove most feature requests from the issue tracker and delegate design discussion to github discussion.

This wasn't necessarily when the project was small, but now it has a large fan base and many issues are related to key bindings or new features. And so that there are not 100+ such questions, it would be good to have a discussion sector for this. I like the idea of voting, where there is a collection of all possible innovations, everyone can vote. If x votes are received, it moves to the release sector. Small patches will come out less often, but through years helix will not be a repository of features for one or two people. Afaik, you can't do more than one poll in one discussion.

[pascalkuthe]

I like the idea of voting, where there is a collection of all possible innovations, everyone can vote. If x votes are received, it moves to the release sector. Small patches will come out less often, but through years helix will not be a repository of features for one or two people. Afaik, you can't do more than one poll in one discussion.

Helix explicitly lists popularity as a non-goal what gets accepted is decided by the maintainers and not by popularity. I think RFCs can be drafted up in the discussions section and once the author is happy the maintainers could accept the RFC as a tracking issue

[exastone]

My two cents; Your opinion is valid as I also find it difficult to filter through; however, if you look at number of issue by label compared to the total open issue (722 currently) you'll see the top 5 labels contributing to issues are:

1. A-helix-term (532)
2. C-enhancement (484)
3. C-bug (232)
4. S-waiting-on-review (170)
5. A-language-server (61)

keeping in-mind that many issue are multi-labeled so these numbers are a bit misleading.

Let's be pessimistic for a moment and say that "most" of the open issue are "distracting from the real problems" (lets say 80%, so ~580)

In my opinion, 170 issues labeled as S-waiting-on-review is a good indication there is a health amount of contribution and reduce that 580 by 170, so that leaves us with 410 distracting issue.

Not all C-bug labels are going to be critical but as a relatively new project that has gained a significant amount of popularity very quickly, it makes sense that bug issue are going to take a big spike with the significant popularity the project has gained while being a relatively immature project. lets say half of these C-bug issues are dead, been fixed elsewhere without closure, etc. that would leave us at 292 "distracting from real problems" issues.

Now lets get to where the suspected culprit of poor quality issues come from, C-enhancement.

Theres bit of a semantics issue going on here related to the word enhancement.
Enhancement (arguable) is meant to describe adding functionality via extension of an existing feature that is present, meaning it should require less time to implement than something such as a feature request. A feature request is (arguably) meant to describe adding functionality via the introduction of new high-level components that enable functionality to be derived from them.

The reason for (attempting) to distinguish the two from each other is that feature requests are suppose to first be opened as an idea discussion thread to get rough judgement of community interest, which from my experience viewing issues and the discussion threads, is not happening.

As you mentioned maybe stricter issue management could help with this, requiring linking a C-enhancement issue that is actually a feature request to a related Idea Discussion thread would help cut down on the number of feature request issues being opened; however, determining whether something is (semantically) an enhancement or a feature request isn't always clear without further investigation by maintainers/contributes.

Lastly, there are (currently) 46 issues labeled as A-keymap. In the docs it's known that keymaps and keybindings are currently limited and being worked on. Until helix completes implementation of in these area, people are going to complain, that's one of the trade offs of using an immature project that we have to deal with and personally i think most of these issue will be resolved when work on key mapping are completed in (hopefully) soon coming releases.

Overall we're looking at ~250 open issue (on the high-side) that are "distracting from real problems". Given that contributing/maintainer team is also growing relatively quickly and fantastic at addressing issues as they come in, I don't see ~250 (possibly) poor quality issues as all that bad considering the rapid traction the project has gained.