4 ms·

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

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.

mort96 4y ago
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
- vladvasiliu 4y ago
  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.
  - mort96 4y ago
    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.
    - vladvasiliu 4y ago
      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.
      - mort96 4y ago
        "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.
        shkkmo 4y ago
        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.
        4y ago
sodality2 4y ago
> 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".
- willnonya 4y ago
  So, it's a marketing problem with the default being issues rather than request?
  - mort96 4y ago
    It's not a marketing problem, it's a semantic problem. Issues are not requests and requests should not be called issues.
    - shkkmo 4y ago
      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.
      - mort96 4y ago
        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.
        shkkmo 4y ago
        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.

mort96 4y ago

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

vladvasiliu 4y ago
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.
- mort96 4y ago
  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.
  - vladvasiliu 4y ago
    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.
    - mort96 4y ago
      "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.
      - shkkmo 4y ago
        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.
        4y ago

sodality2 4y ago

> 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".

willnonya 4y ago
So, it's a marketing problem with the default being issues rather than request?
- mort96 4y ago
  It's not a marketing problem, it's a semantic problem. Issues are not requests and requests should not be called issues.
  - shkkmo 4y ago
    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.
    - mort96 4y ago
      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.
      - shkkmo 4y ago
        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.