> Isn't that a bit too high to be manageable?

Yes. See many past conversations on why Github Issues become unmanageable.

Labels help to segment, but aren't enough.

I find the number of 'open' issues a demotivator (bordering on depressing) for my projects, or when I look to work on others; even if most aren't issues but support questions/feature requests/on hold. If not triaged well, digging through to find the real bugs takes effort.

Github tried with 'Projects' but I haven't seen many (any?) projects using them successfully. For individual workflows they seem to work well. Big projects have fallen back on milestones.

Julia has 2400 open issues and 660 open PRs (http://kristofferc.github.io/post/julia_issue/ 2017)

Rust has 4,500 dotnet core libs 2,600 donet coreclr has 2,000 Golang has 4000

Actually plenty of issues are RFCs and feature requests.

We have a new RFC repos to brings a bit more sanity to the bug tracker: https://github.com/nim-lang/RFCs/issues

Ansible has 3900+ issues and 1700+ open pull requests on Github...

Was looking at Flutter recently and it has over 4000 issues.

I think that's understandable, in spite of being a young niche/language the community oversells it continuously on larger communities (like HN) but it is that much polished. The promise: pythonic, cross compilable, fast solution for everything with readable macros.

And in my opinion it is not like that, see my comment on the top level.

Issues have a status one presumes -- 1000 "requests for new features" or minor BS complains don't matter as critical issues.