3 ms·

> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention beca

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

mort96 4y ago
> 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.
- shkkmo 4y ago
  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.
  - mort96 4y ago
    You're displaying that you haven't read this discussion and are bringing up things which don't matter. Stop.
    - shkkmo 4y ago
      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.

by shkkmo 4y ago

mort96 4y ago

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

shkkmo 4y ago
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.
- mort96 4y ago
  You're displaying that you haven't read this discussion and are bringing up things which don't matter. Stop.
  - shkkmo 4y ago
    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.