5 ms·

As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "healt

As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "health" of a repository, things like the number or lifetime of issues play an important role. Even npm shows publicly (open) "Issues" and "Pull Requests". Well, if my project is working as intended, I like that people look at it and see the "Issues" count to be as close to 0 as possible. That's why I'm so excited/hopeful about Github Discussions, that seems like it was a huge hole in the whole Github and finally being addressed. A place to ask questions, meta questions, show YOUR issues using the library, etc. just a place to have conversations around the library. So you can leave the Issues for bug reports/potential issues. I closed the Issues tab in two of my most popular libraries because they just got low quality questions where devs were expecting me/others to basically fix their code/do their homework.

onei 5y ago
Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.
- humanistbot 5y ago
  A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
- FooBarWidget 5y ago
  An another OSS author, I am glad that you think that way (and I agree with you) but unfortunately not all users think that way. I have literally heard stories from users who think that my project is unstable because it had a sizable open issues count (~200). They didn't even look at the fact that 1/3rd are feature requests.
marcosdumay 5y ago
That's why there shouldn't be any "open" or "closed" state. And yeah, the GP is calling for a forum. Bug reports, feature requests, and interface issues are a topic of discussion first, and a work item as a distant second. There is some value in once you identify something as a bug to be fixed or an impromevent to be made, to tag the discussion saying if the work is in progress or done, and what release has it complete. None of those tags invalidate the discussion, and it's not realistic to expect all items to have a tag like this.

onei 5y ago

Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.

humanistbot 5y ago
A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
FooBarWidget 5y ago
An another OSS author, I am glad that you think that way (and I agree with you) but unfortunately not all users think that way. I have literally heard stories from users who think that my project is unstable because it had a sizable open issues count (~200). They didn't even look at the fact that 1/3rd are feature requests.

marcosdumay 5y ago

That's why there shouldn't be any "open" or "closed" state. And yeah, the GP is calling for a forum. Bug reports, feature requests, and interface issues are a topic of discussion first, and a work item as a distant second. There is some value in once you identify something as a bug to be fixed or an impromevent to be made, to tag the discussion saying if the work is in progress or done, and what release has it complete. None of those tags invalidate the discussion, and it's not realistic to expect all items to have a tag like this.