I checked out about 15+ smaller repositories with the "help wanted" labels and only one had active development.
Most projects had several unanswered pull-requests since 2018/2019 contributed by strangers wanting to help or issues with comments from people asking to help with no response.
I actually looked for one project that i could potentially help out a tiny bit, but the experience so far has been discouraging.
But if you can make a fork and petition for it to be seen as the "active, maintained" version, it would work a lot better I think.
In theory, open source is all about forking and the like. In practice, it's a lot of islands with single people or organizations at the "top" dominating the project, with any forks having no chance at survival unless they get merged in again.
Obviously not possible for GitHub as a whole, but perhaps we could reimagine how GitHub interacts with specific language/tool/whatever communities.
In practice I fear that this would lead to abuse where scammers (or what you want to call them) fork dead projects but then add crypto miners, adware and ransomware to the code and then they create a bunch of dummy commits to make it seem active to automated systems and to people only taking a glance at the project. And all of that can happen already of course, but if you then allow these people to automatically be assigned status of the canonical active maintained version then much more people will end up installing these malware-infested versions of the software.
On the other hand, the network view, which is the closest thing we have right now, is pretty hard to read for the question of "where are active forks right now"? I just sampled them now to make sure I'm not shooting my mouth off, and I think a major problem is that the graph doesn't have a strong visual difference between an active fork with many commits and contributors and someone who happened to commit something yesterday against an old (perhaps "official" fork), and there doesn't seem to be any sensible sorting that I can make out, either. Plus the UI on that thing is just funky in general; I think I see lines going off the right of some of these networks entirely but I can't seem to scroll right or left.
Upshot is, I'd rather they just figured out how to improve that graph, or generally build a "more active forks available here" that can be obtained through a clickthrough, but not have GitHub try to guess at who's "official".
Unfortunately for libraries you will also have to have a system in place for all the library hosting providers (npm, rubygems …) to transfer ownership as well.
They've got that weird graph thing of fork activity, assuming people forked on Github, that has worked well enough for me to find a less recently abandoned fork on the things I've run into.
I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781
Also, they replied in https://github.com/up-for-grabs/up-for-grabs.net/issues/2536...
> We don't want to direct new contributors to the projects where they would feel lost or ignored. That gives a bad user experience due to which people tend to stop contributing to Open Source. I had same experiences so many times.
> Do you have a solution or suggestion for this? How should we tackle this.
> One way we can do this is to track the latest commit on the repo, but there could be a reason like the Repo is hard to work with and the Maintainers are reviewing PRs and Issues but there is nothing useful to be committed for a long time. This happens.
I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781
Also, they replied in https://github.com/up-for-grabs/up-for-grabs.net/issues/2536...
> We don't want to direct new contributors to the projects where they would feel lost or ignored. That gives a bad user experience due to which people tend to stop contributing to Open Source. I had same experiences so many times.
> Do you have a solution or suggestion for this? How should we tackle this.
> One way we can do this is to track the latest commit on the repo, but there could be a reason like the Repo is hard to work with and the Maintainers are reviewing PRs and Issues but there is nothing useful to be committed for a long time. This happens.
Example output of my script (fetches repos, gets stats, dumps output): https://fundamental-code.com/mruby-timeline/ . From there it should be easy to prune short lived/old repos and then the rest of the process becomes somewhat more manual from there.
EDIT: actually forget that, it looks like there's already a last-updated stat which seems to be in place, up-for-grabs seems to be fine with projects which don't have any activity for a few years based on their existing metric.