When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.
GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.
I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.
The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening them are disciplined (and pay attention) enough to file them in the right category. Just because there's a separate "feature request" top-level tab doesn't mean that nobody will ever open a "bug" asking for a "feature". Especially if not everybody is allowed to ask for new features.
And I'm not even going into the difference between "improvement" and "feature" requests.
> To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.
The difference is that they're all under the label "issues" implying it's something that needs to be fixed. Sure, you could label it, but that's a workaround and it's still in a category called "issues".
A feature request should have a different life cycle. In that regard it should be more like a PR, where you submit a request, it gets feedback and is resubmitted etc. All with a history that's clearly visualized, so it's easy to compare the different revisions.
I find it quite difficult to follow the discussion around a non-trivial feature request when it's just a regular issue.
It is not a semantic problem. "Issue" was an very broad term far before it was used in software development / project management. It's meaning easily encompasses far more than just bug reports. This is why we have labels to break issues down into other categories. Some issues are purely discussion topics, some are change requests, some are bug reports. You seem to be trying to restrict the meaning of 'issue' in a way that matches neither current usage, nor historical usage.
You may disagree that it's a problem, but what I'm referring to has nothing to do with marketing and everything to do with the semantic meaning of the word.
The actual semantic meaning of the word "issue" is broad and doesn't support any of your arguments. You seem to think "issue" means something different from how the rest of the world uses it or has used it.
Ok, so? That means you disagree about me on whether it's a problem, which is fine.
When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.
Concern about the negative emotional connotation of a word instead of that word's semantic meaning is a classic "marketing" concern, but whether or not we call your concern one about "marketing" (which is itself a very broad term) seem irrelevant to that actual substance of your concern.
Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means.
> Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
> Holy shit. You are disagreeing with me about the meaning of a term.
I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in.
If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue.
> Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
We currently have a broad category of things, these things need to have a name. You seem to think that "issue" is a bad name for this category of things, so I am asking: what you think is a better term for this category?
We can further break down that category into "bug reports", "feature requests", "change requests", "discussions" and add better UI elements to surface those groups but the overall system that manages these all these items still needs a general name for what it is managing.
Listen, I'm done with this discussion. For the second part of your comment I already linked you to this comment: https://news.ycombinator.com/item?id=33774066. For the first part, everything I can find on the topic indicates that connotations are part of semantics; it's a part of the word's meaning, after all. If you disagree with that, fine, I don't care, I have made it as clear as I can possibly be that nothing I've said has anything to do with marketing.
"meaning" itself is a broad term, but the "literal meaning" AKA the "denotation" is distinct from the "connotation" of a term. Semantics is a broad term that means different things in different disciplines, but generally concerns itself with the denotation more than the connotation. I suppose you could make an argument that the denotation of "semantics" could technically include connotation but that the connotation of "semantics" usually implies that it is denotation that is being discussed.
Instead of arguing the different definitions of the word "semantic" with me, why not just listen when I say that I'm not talking about marketing. Please.
I've mentioned "marketing" exactly once, and only to dismiss the debate about what is and isn't marketing as irrelevant. I've tried to constructively drive the conversation forward repeatedly, if I've been drawn into side discussions, it is only by you bringing up those topics.
I also disagree with you about how you're treating the term. "Issue" is used more broadly from a user perspective.
As a user it legitimately is an issue, in the commonly used sense, if you cannot do what you need to do with software, even if that software is working exactly as designed and no one has yet flagged some alternate functionality to add with an enhancement.
> When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation.
That's a you problem.
Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.
A feature request is very much something that should be discussed.
> Maybe I'm just wrong,
Yes, you are. Rather than push back, accept it and move on.
> GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.
Except that GitHub Issues originally only encompassed bugs. Labels weren't added until later that allowed you to filter by "type". Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system", so I wouldn't say that it's so "clearly defined".
> Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system"
That quote is directly below a quite clear explanation of what issues are for: "are useful for discussing specific details of a project such as bug reports, planned improvements and feedback."
Each project can decide for themselves at where they draw the line in terms of what they want where. That is a good thing, it makes github issues flexible for a wide range of projects that are organized in a wide variety of manners. It seems like a shame to lose that flexibility to make it easier for people who are too lazy to do more than look at the count of open issues when evaluating the health of a project.
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"...
> When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs.
That's just changing how GitHub presents the "issues." They could just as easily remove the global number display and simply display the count of each type of issue on the issues page.
> When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.
That's just a UX/UI concern. You can easily link to feature requests only.
None of these are "issues" related, but rather, just how it's displayed. Your concern is with the visuals.
Do you have any evidence that people assume that? Most popular projects have many issues, which don't seem to drive people away (e.g. React 900 issues, scikit-learn 1.5k).
You mean, until you manage your project...gasp. How horrible!
Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.
I don't understand what you are trying to say. Why is a build-up of feature requests a sign of neglect, if bugs are regularly fixed? Do you consider a build-up of unimplemented feature requests to reflect as poorly on a project as a build-up of unfixed bugs?
A build up of un-triage feature requests can be a sign of neglect or of maintainer overload (the later will probably lead to the former eventually), but you can't tell if that is the case just by looking at an issue count.
Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues are bunched together by default -- that filtering out the issues you don't care about takes any clicks at all -- contributes to that.
> the issue is with the lack of a clear separation
But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine.
I think it's a fine trade-off to have something generic, and let each project add whatever tags work for it.
I wouldn't be against renaming "issues" to something more "generic". Maybe "change requests"?
* Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.
* Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
Maybe both of those solutions are bad and a good UX designer (not a random commenter on HN who has thought about this for 2 minutes) can think of something better. Maybe both of those solutions are bad and there is no good solution and the current approach is the best possible. I don't know. Notably though, "there is no solution to the problem that's not worse than the problem itself" does not mean the same as "there is no problem".
> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.
And then we also need to separate tab for discussions and questions since those are also very common use cases for issues.
> Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
The only part of this that doesn't exist is a tab that links directly to the labels page, which does show the number open/closed issues per label
It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. I would agree that looking just at an open issue count is not the best way to assess the health of a project. I think you are better looking at open issues will un-merged pull requests and why they aren't merged. You can also look at a sample of open issues to see how organized and responsive the developers are and what types of bugs tend to be present. All of these require far more effort than just clicking over to the issues tab and then clicking into the labels page to see a breakdown of open issues by label. I would say that users that don't take the effort to do this basic research of before pulling in a dependency aren't the high value users that will help contribute to the value of the project.
> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues.
No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be intentionally misunderstanding me at this point.
Owners of a project have the ability to create clear separations between categories if they want. The 'issues with labels' structure allows each project to setup the categories and level of separation that matches their need. This is important because of the following:
The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "feature request" and there are also issues that don't fall cleanly into either category.
Examples:
1) A user opens an issues because a library doesn't work properly on platform X and fails with an error message. The developer of that library closes that issue with a "won't fix" because they don't support the platform. Is this a bug report or a feature request?
2) A user opens an issues because one of the dependencies of a library is no longer being developed so won't support moving to the new version of the language the library is written in. Is this a bug report or a feature request?
3) A project owner opens an issue because a new standard has been released that the library has to support because it is critical to it's ability to interoperate with other parts of the software ecosystem. This could well be much higher priority than many minor edge-case bugs, but is still new functionality.
The answers to these questions can, and should, vary from project to project and issue to issue depending on the larger context. An issue tracking system should be flexible enough to encompass these different needs.
I charitably assumed you were focused on "potential users quickly dismissing projects with too many open issues" since that at least provides a clear reason for why the current methods of categorizing issues isn't good. Since that assumption was incorrect, I still don't understand exactly what exactly your issue is with github issues.
I'm bringing up issues that have to be considered when creating an issue tracking system that serves the needs of a wide range of projects. You can choose to ignore those issues, but that doesn't mean they don't matter.
You've repeatedly conflated categorization of issues based on priority and categorization of issues based on relation to the spec. Just because something is a bug report doesn't mean it needs to be fixed and just because something is a new feature doesn't mean that it shouldn't prioritized over bugs. Ignoring this simply serves to keep the conversation running in circles.
GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.