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