There are about 2k issues. Should we consider prioritizing these issues?
Today, I encounter an issue. After searching, it is an issue reported 9 years ago.
Issues 11493
Closed 9536
Open 1957
and still that does not add much meaning to the 2K open issues.
I won't speak for anyone but I should probably comment on this. The latter half of last year for me has been going through the issue list one by one starting from random pages.
First, about your specific issue: Recursive/forward types are not really implemented properly and may need a redesign. If you'll notice I added a label for that issue and other similar issues just a couple months ago. It's just that recursive types do not really come up often and issues usually have simple workarounds including that issue compared to the effort it would take to deal with them, but anyone is welcome to try.
Secondly, obviously fixing issues is a priority, including old issues, many were closed recently. There is not really a way of knowing which issues are more important without people bringing them up, commenting on old issues or creating new ones. There are indeed 2000 issues.
I think anyone who had/has/is used/using Nim, or is just involved in this community can say "we".
Focusing on the use of "we" or "you", but not issues, scares me.
To be clear up front, I am totally fine with the compiler team dealing with issues in whatever order fits their priorities. But dealing with a backlog of 2K issues seems to me a bit overwhelming.
One way to reduce the backlog would be for members of the community to pick a minor issue that annoys them and submit a PR that fixes it. Indeed, a common response to complaints in the forum has been "PRs are welcome".
Unfortunately, my experience indicates that generating a PR has little bearing on whether the fix actually finds its way into the code.
A couple years ago, while learning how to use VSCode with Nim, I found a problem that I found quite annoying. Types, fields, procs, etc. appear in the outline pane, but templates do not. (BTW, neither do methods.) By any measure this is a minor problem, but it does bug me.
Being new to working in the open source world, I figured this would be a good way to get my feet wet. So I created an issue (#21923) and went about tracking down the cause. TLDR, I found the problem to be in a part of the compiler that helps nimsuggest. I coded a fix, and submitted a PR. @Araq reviewed the code, and I updated the PR with his recommended changes.
And there it sat. It was resynced once by a member of the compiler team, but was never merged. Eventually Github expired the PR due to lack of activity.
My interpretation is that, with everything else that was (and still is) going on in the compiler, the PR simply fell though the cracks.
I totally get that the compiler team is small, with limited time to deal with minor issues. What seems to be missing is a way to ensure that minor fixes such as the above, when they are accepted, don't get lost but instead are put into a queue to be automatically merged.
For myself, while I have tons of programming experience, I do not have much compiler knowledge, so it takes considerable time and effort for me to track down and fix even minor compiler-related issues such as above. For me to undertake that again, I need to know that my efforts are not wasted - either my fix will be rejected because there is a better fix from elsewhere, or it will be revised as required, accepted and merged. Not lost and forgotten.
For now I will raise issues as I encounter them. But I will leave it to the compiler team to deal with them according to their own priorities.
I was certainly not trying to scare you.
I have simply observed that "we" is used by a lot of people trying to tell other people what to do.