7 ms·

It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature reques

It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"

zozbot234 4y ago
GitHub's issue tracking has tags, which can be used for this.
- mort96 4y ago
  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.
  - zozbot234 4y ago
    > until you manually go and filter them out. Filtering by tag only takes a single click. It's not hard.
    - mort96 4y ago
      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.
      - vladvasiliu 4y ago
        > 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"?
        mort96 4y ago
        Here's a couple possible solutions: * 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".
        shkkmo 4y ago
        > 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.
  - vladvasiliu 4y ago
    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.
  - willnonya 4y ago
    "until you manually go and filter them out" 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.
    - mort96 4y ago
      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?
      - shkkmo 4y ago
        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.
  - jasonlotito 4y ago
    > 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.
  - rad_gruchalski 4y ago
    > people assume There you go. That’s the problem.
  - remram 4y ago
    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).

It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"

zozbot234 4y ago

GitHub's issue tracking has tags, which can be used for this.

mort96 4y ago
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.
- zozbot234 4y ago
  > until you manually go and filter them out. Filtering by tag only takes a single click. It's not hard.
  - mort96 4y ago
    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.
    - vladvasiliu 4y ago
      > 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"?
      - mort96 4y ago
        Here's a couple possible solutions: * 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".
        shkkmo 4y ago
        > 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.
- vladvasiliu 4y ago
  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.
- willnonya 4y ago
  "until you manually go and filter them out" 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.
  - mort96 4y ago
    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?
    - shkkmo 4y ago
      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.
- jasonlotito 4y ago
  > 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.
- rad_gruchalski 4y ago
  > people assume There you go. That’s the problem.
- remram 4y ago
  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).