6 ms·

the systemd stars-to-issues ratio is worrying to say the least

Iolaum 5y ago
lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)
TheDong 5y ago
What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... And I've also noticed that low-level systems projects generally attract relatively few stars (i.e. a javascript library or go library will have more stars than a well used c library or systemd). My theory on that is that the people involved in projects like systemd, gnu, etc, see github as mostly just a git repository host, and don't bother with stars etc. I guess from my perspective, I put zero weight into the stars on a project, and issue count only matters in the context of how the project deals with issues. What do you see as "worrying" in there? Do you see more value in those numbers than me?
- 867-5309 5y ago
  I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd
  - pseudalopex 5y ago
    More stars wouldn't decrease the number of issues though.
    - 867-5309 5y ago
      it would decrease the ratio
      - pseudalopex 5y ago
        The number of issues has some relevance. The number of stars doesn't.
        867-5309 5y ago
        not following
        pseudalopex 5y ago
        You can't compare the number of stars for different kinds of software. A large number of open issues means the maintainers can't keep up. 10x more issues mean the problem is worse even if the project has 20x more stars.
        TheDong 5y ago
        For what it's worth, I also don't think comparing issues between different projects works. If you have project A, run by a company, which uses an internal Jira instance to track backlogs and developer's selected tasks, but uses github issues to track all user's reported bugs, well, that will have fewer issues than project B, which uses github issues to track backlogs and sprints in addition to bugs. There's a lot of variability in this. The kubernetes project (~2k issues) has a bot that closes issues after 90 days by default (~9k closed by the bot so far), and without that bot, they'd have way more. > A large number of open issues means the maintainers can't keep up. That's not necessarily true. Github doesn't prescribe that every issue is immediately actionable. Perhaps the issue was tagged as "feature-request / help-wanted". Perhaps it is marked as "awaiting additional reporter info" (like logs, or OS), and there's nothing the maintainers can do until the reporter gets them more info. Whether every issue gets triaged tells you something about whether maintainers are keeping up, but issues that are triaged aren't then always closed, so the number of open issues doesn't tell you much about how many issues are triaged and how quickly.
    - beermonster 5y ago
      The criteria for a person to star a repo likely varies person to person. Therefore I’m not sure it’s a useful metric of anything in particular? Some crude popularity metric maybe? I don’t star repos myself. Feels more like a social networking feature.
  - TheDong 5y ago
    > should projects be on github if the issues aren't used as intended? What do you mean by "not used as intended"? systemd has a mailing list too, but they also respond to github issues. Does having multiple different forms of interaction with your community mean you're not using issues as intended? Some projects use github issues as a sorta backlog, or in conjunction with milestones and github projects to track future work. Some don't. Are projects that don't do that not using issues as intended? As far as I know, github gives no general guidance on how to use github issues, and it's up to each project to setup issue templates and/or contributing.md files to explain that project's expectations. > generally shows how active, responsive and sufficiently staffed the maintainers are Okay, so if a project has a bunch of maintainers and is so well staffed they close all issues immediately, that means they have 0 issues, so that's good, right? Except many well-maintained projects on github have hundreds to thousands of open issues, like nodejs with >1k, rust-lang with 7k, etc. From where I sit, how well-maintained a project is has almost nothing to do with how many issues it has. Issues are a function of number of users (which is much different from level of maintenance), and maintainer policy on whether they close issues without enough information, close stale issues automatically, use issues to track backlog work, etc.
  - detaro 5y ago
    So in your metric, all those projects that use a bot to close issues after 30 days as "stale" are using Github better?
    - 867-5309 5y ago
      it's not a metric, just an indicator
  - kaba0 5y ago
    There is for example nixpkgs, which uses issues very differently to a conventional repo, and you can’t really argue whether the project is over/under stuffed based on that, since it packages almost everything. Some of the issues may be upstream bugs, etc.
- TeMPOraL 5y ago
  Github stars are just bookmarks. They're not an expression that someone loves the project, or are using it, or even very interested in it - they're just a way to bookmark something that piqued your interest, so that you can find it later. This tells you why "low-level systems projects" attract less stars. It's because well-known, long-lasting projects attract less stars. There's a little point of starring a repo of a project that you recognize and use. You remember its name already. Meanwhile, a random JS library that looks like it could come in handy in the future? These things come and go, and you'll forget its name 5 minutes from now anyway, so you star it.
  - saagarjha 5y ago
    Well, to you. I use GitHub stars as a way to mark projects that I use or particularly appreciate.

lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)

What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... And I've also noticed that low-level systems projects generally attract relatively few stars (i.e. a javascript library or go library will have more stars than a well used c library or systemd). My theory on that is that the people involved in projects like systemd, gnu, etc, see github as mostly just a git repository host, and don't bother with stars etc. I guess from my perspective, I put zero weight into the stars on a project, and issue count only matters in the context of how the project deals with issues. What do you see as "worrying" in there? Do you see more value in those numbers than me?

867-5309 5y ago
I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd
- pseudalopex 5y ago
  More stars wouldn't decrease the number of issues though.
  - 867-5309 5y ago
    it would decrease the ratio
    - pseudalopex 5y ago
      The number of issues has some relevance. The number of stars doesn't.
      - 867-5309 5y ago
        not following
        pseudalopex 5y ago
        You can't compare the number of stars for different kinds of software. A large number of open issues means the maintainers can't keep up. 10x more issues mean the problem is worse even if the project has 20x more stars.
        TheDong 5y ago
        For what it's worth, I also don't think comparing issues between different projects works. If you have project A, run by a company, which uses an internal Jira instance to track backlogs and developer's selected tasks, but uses github issues to track all user's reported bugs, well, that will have fewer issues than project B, which uses github issues to track backlogs and sprints in addition to bugs. There's a lot of variability in this. The kubernetes project (~2k issues) has a bot that closes issues after 90 days by default (~9k closed by the bot so far), and without that bot, they'd have way more. > A large number of open issues means the maintainers can't keep up. That's not necessarily true. Github doesn't prescribe that every issue is immediately actionable. Perhaps the issue was tagged as "feature-request / help-wanted". Perhaps it is marked as "awaiting additional reporter info" (like logs, or OS), and there's nothing the maintainers can do until the reporter gets them more info. Whether every issue gets triaged tells you something about whether maintainers are keeping up, but issues that are triaged aren't then always closed, so the number of open issues doesn't tell you much about how many issues are triaged and how quickly.
  - beermonster 5y ago
    The criteria for a person to star a repo likely varies person to person. Therefore I’m not sure it’s a useful metric of anything in particular? Some crude popularity metric maybe? I don’t star repos myself. Feels more like a social networking feature.
- TheDong 5y ago
  > should projects be on github if the issues aren't used as intended? What do you mean by "not used as intended"? systemd has a mailing list too, but they also respond to github issues. Does having multiple different forms of interaction with your community mean you're not using issues as intended? Some projects use github issues as a sorta backlog, or in conjunction with milestones and github projects to track future work. Some don't. Are projects that don't do that not using issues as intended? As far as I know, github gives no general guidance on how to use github issues, and it's up to each project to setup issue templates and/or contributing.md files to explain that project's expectations. > generally shows how active, responsive and sufficiently staffed the maintainers are Okay, so if a project has a bunch of maintainers and is so well staffed they close all issues immediately, that means they have 0 issues, so that's good, right? Except many well-maintained projects on github have hundreds to thousands of open issues, like nodejs with >1k, rust-lang with 7k, etc. From where I sit, how well-maintained a project is has almost nothing to do with how many issues it has. Issues are a function of number of users (which is much different from level of maintenance), and maintainer policy on whether they close issues without enough information, close stale issues automatically, use issues to track backlog work, etc.
- detaro 5y ago
  So in your metric, all those projects that use a bot to close issues after 30 days as "stale" are using Github better?
  - 867-5309 5y ago
    it's not a metric, just an indicator
- kaba0 5y ago
  There is for example nixpkgs, which uses issues very differently to a conventional repo, and you can’t really argue whether the project is over/under stuffed based on that, since it packages almost everything. Some of the issues may be upstream bugs, etc.
TeMPOraL 5y ago
Github stars are just bookmarks. They're not an expression that someone loves the project, or are using it, or even very interested in it - they're just a way to bookmark something that piqued your interest, so that you can find it later. This tells you why "low-level systems projects" attract less stars. It's because well-known, long-lasting projects attract less stars. There's a little point of starring a repo of a project that you recognize and use. You remember its name already. Meanwhile, a random JS library that looks like it could come in handy in the future? These things come and go, and you'll forget its name 5 minutes from now anyway, so you star it.
- saagarjha 5y ago
  Well, to you. I use GitHub stars as a way to mark projects that I use or particularly appreciate.