Maintainers obviously have to go through and re-label or move issues as appropriate. The situation is the same now; if someone creates an issue labelled "bug" where they ask for a new feature, you have to go in there and change the label to "feature request". I'm not sure I understand why you think that matters in this discussion
That matters because it shows that there still is a need for the maintainer to go and make sure the labeling is correct. So having multiple top-level categories doesn't help with the maintenance burden.
I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.
> A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.
A healthy project can also close feature requests they don't want to implement. They can also choose to close every issue that isn't a bug report because they use different tools for feature planning and discussion. They can also choose to just automatically close every issue because they don't use github issues at all, but prefer other tools.
So, your issue with the current implementation is purely cosmetic / "semantic"? As in seeing there are 1000 "issues", when 999 of these are actually "improvement / feature requests"?
Because when you go in the issues tab, you then choose to only see "bugs", which will show you the one that needs handling, and you can ignore the 999 others.
"Cosmetic" and "semantic" aren't synonyms, saying "this project has 100 issues" has a different meaning from "there are 100 features which users want to see implemented".
But no, the wording isn't the only/main issue IMO, it's the lack of a clean separation between problems which should be fixed and non-problems which don't need to ever be resolved. It's a cognitive thing for maintainers, I believe mixing up those things contribute to burn-out through the purely psychological effects of being told by the UI that there are 100 things which need to be solved when there may in fact only be 5, it's a public perception thing when the stat that's prominently placed on the repo page is the number of open issues.
And yes, it's vague. It's not the technical lack of a good enough labelling and search system. And maybe different people react differently to this stuff, maybe some people have no trouble dealing with the lack of a clean separation. But given the fact that burn-out in open source is such a huge issue, maybe conflating the stuff which must be fixed and the stuff which doesn't have to be fixed isn't such a great idea.
I don't see how moving the categorization of "feature request" vs "bug" outside of labels helps anything. That must makes it harder to do the inevitable re-categorization that will always be required since the line between "feature request" and "bug" can get subjective and fuzzy depending on how one views the purpose / spec / scope of a project.
If all you are saying is that it is a UI issue to mix those two categories when you open the issues page for the first time, it is pretty easy to bookmark or link to a list of issues filtered by label.
I don't know what more I can say to make it clear that "there are workarounds or workflows which make it possible to separate bugs and feature requests" doesn't respond in any way to what I'm saying, so I'll just step out of the conversation now.
The question I was trying to ask you is: What do you see as a better way to separate bugs from feature requests and what makes that way better than the existing system?
If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say
Perhaps other people may have another opinion but I'm afraid that most people seeing 200 issues think that the product is in the phase of intensive development so is not mature (what can be true) or that its development is stale (what also can be true). Their first thought isn't "it's a mature but still well-maintained product"...
