7 ms·

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue temp

• RobotToaster 4y ago
  >Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?
  • nightpool 4y ago
    The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/codespaces https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything
    • shkkmo 4y ago
      > The forum was built to be a feature request tracker. It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues." Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.) > It's used extensively for that purpose at Github Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.
• sodality2 4y ago
  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.
          • 4y ago
• ilyt 4y ago
  It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"
  • remram 4y ago
    Do you have any evidence that passerbys think this way? Scikit-learn has 1.5k issues, react has 900, I don't think it is driving them away?
    • iudqnolq 4y ago
      Personally I skim a sample of issues before adding a dependency. The main thing I look at is what happens after high quality bug reports are filed. The top line number doesn't bother me much.
  • madeofpalk 4y ago
    I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.
    • xur17 4y ago
      This seems like a great way to handle it.
  • lcnPylGDnU4H9OF 4y ago
    It could still be worth saying "no", per the article, to the 295 open feature requests. The fact that the maintainers have not (yet) declined these requests, resulting in this seemingly inflated total of 300 "Issues", is not necessarily a problem with github.
• qikInNdOutReply 4y ago
  There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.
  • eropple 4y ago
    That would be a nice add-on, but IME, most people just click straight through it.
    • qikInNdOutReply 4y ago
      Then allow them to auto-cluster by similarity for those who have to read the mess, also sort by quality.
      • eropple 4y ago
        Now that's an idea. I like that.
• croes 4y ago
  Your project has 65 issues. Without looking into the details I could assume these are 65 bugs.
  • shkkmo 4y ago
    That seems like a bad assumption. Even if there are 65 bugs, without taking a look at a sample of them you have no idea of the severity or relevance of those bugs. Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.
• xphos 4y ago
  I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.
  • Kovah 4y ago
    That's absolutely a valid point. However, if Github would have set something like this as a default, there would be a lot of people who would complain about it being too opinionated. Being open first with many options to customize and "lock down" is probably a good compromise.
• lifeisstillgood 4y ago
  That's a fantastic way to setup your github - I shall steal it asap :-)