I tend to check the age difference between the earliest and latest commits because that lets me be sure it's not a project that someone spent a couple weeks coding up, dropped on github, and then forgot about. I'll also check the issues on there. I'm looking for more closed issues than open ones, but I'll also quickly scan over them to get a rough idea of how many are truly meaningful issues. I also get signals from the readme and docs. It's not a hard pass if there's issues with those, but it's certainly helpful to my opinion if they exist and are both clear and detailed.
If one of the repos has many more stars, I weigh that strongly when choosing. Freshness of commits is definitely important, but for me the fact that many other people starred the repo shows that there are eyeballs and activity.
You're the kind that checks everything. Even if you had something valuable, a scammer wouldn't waste their time with you then there are easier fish to bait.
I really wish GitHub would have some sort of flag for "stale" projects. I use your methods too (issues, dates, etc.), and I'm usually disappointed when search results bring up ghost projects. However, in a few instances, I found a project that was similar to an issue I was working on that went one step beyond where I was, and even though it was a ghost project, it helped. But in general, these projects don't help. I'm also disappointed that I'm thinking, "Hmmm, maybe LLMs can help..."
It's almost like you are thinking of it as an expiration date and the software has spoiled.
Now that I think about it — it is a python wrapper around a boost library and neither of those have made backwards incompatible changes in a long time which is quite suspicious.
As you indicate though, they require more effort to adjudicate. Are issues from core team members? Are commits meaningful? Is community activity meaningful? I wish GitHub would give allow us to parse things like this more easily.
My use of star count is generally a binary indicator. 1k+ is probably a legit project and below is probably still early. Beyond that, it's probably too noisy.
So unless you are really well versed in the project and spent some time following it, stars actually might be a better indicator of the project quality and reputation.
God, I hate this. Every time I have an issue with something, look it up on the issue tracker and find the exact issue I'm having autoclosed as "stale" by a fucking bot because the author didn't reply "this is still an issue" once every 24 hours, it instantly makes my blood boil and I avoid using the software in question as much as possible in the future. Nothing screams "I care more about github numbers than my users or the quality of my software" more than this.
Rust and other compiled languages that have backward and forward compatibility in mind do much better.
Just a small anecdote of Boost changing behavior that broke some of my stuff.
Else, ask for a new maintainer. While code can be considered done (especially if no new features are added), it should never go unmaintained. If it's actually used a lot of course.
There might be a maintained fork/separate project that does what I want that I would like to find instead. Or maybe I was just searching to save myself 30 minutes on a one time task and I'm not up for adopting an abandoned project.
The problem here is simply closing issues that are not fixed because they're "stale", no reason to do this unless you're obsessed with keeping the number of open issues low to deceive people into believing no issues exist. Keeping issues open does not take any effort.
I doubt anyone would do this, but commit date can be arbitrarily changed.