4 ms·

I wish GitHub made it easier for the community to continue working on abandoned projects. All too often, a project's owner goes MIA (without adding more members

I wish GitHub made it easier for the community to continue working on abandoned projects. All too often, a project's owner goes MIA (without adding more members), and the pull requests just keep piling up and are never acted upon. The only way to discover if a project has a more active fork elsewhere is to go to the network tab and scroll around in the graph... Ideally there would be a way to add a banner at the top of dead repositories with a text like "This project is inactive, but there is a more active fork <here>", as otherwise most people visiting the project's page would have no idea such a fork exists. I've successfully revived an abandoned project (with an owner who ignored all my attempts to contact them), but only because the primary resource for the project was a wiki on another website, so it involved changing the links there - but this isn't the case for projects whose GitHub page is their main website.

raziel2p 9y ago
How do you propose this to be done? I've been able to track down active forks by looking at the network graph before, but it's a bit hidden. The problem is, if there are any forks, it's difficult (or impossible) to objectively determine which fork is the "official" one.
- deleted 9y ago
  [deleted]
- CyberShadow 9y ago
  One simple way to do this would be: if a repository has had no activity (commits or comments) from owners/members, show a banner linking to the fork with the most stars.
jszymborski 9y ago
It'd be difficult to engineer that feature in a reasonable way, I think. Potential for abuse by hostile forks and ill-wishers would be a big problem and I can't think of any real mitigations. As is often hotly debated in HN comments, measures of repo inactivity/health are not universally accepted. I can see thresholds in any of these metrics potentially problematic if applied universally. I do sympathise with the pain-point you're outlining, however!
- rcthompson 9y ago
  I don't think such a feature is quite as difficult as one might think. The use case is for repos that are completely abandoned with an actively maintained fork, so you can be super conservative with the time frame in order to limit the possibility of abuse. Don't allow it for any repository with any activity from its owner in the past year, and give the owner something like 3 months from the time the request is initiated to refuse. If they don't respond, then the repo has been untouched for a minimum of 15 months. At that point, the requester gets their fork marked as the "canonical" repo, with a banner on the original repo informing people that it is unmaintained for X months and directing them to the maintained fork. Thereafter, if the the original repo's owner ever logs in, they could have a button on their repo to remove the banner, or alternatively confirm the transfer of maintainership (after which they can no longer take it back). In any case, the frequency of this kind of thing should be rare enough that it also would be reasonable to require approval by a human at Github for each one. Anyway, the above is one possible concept for such a feature that I think would be pretty resistant to any kind of abuse. But I'm not necessarily arguing in favor to this specific concept. In fact, given how rare such events would be, the most expedient "implementation" of this feature might simply be a dedicated email address and instructions on how to write up such a request for manual review, along with a stated policy of the minimum period of inactivity before a repo is eligible for such treatment. But my overall point is that with abandoned projects, I think you can slow down the timeline for transfer of maintainership to the point that abuse of the feature becomes essentially impossible.
  - jakub_g 9y ago
    BTW, GH already has a feature that if a repo gets deleted, and it had forks, then the most starred (AFAIR) fork becomes the "master fork" and other forks have their link "forked from..." updated. It would be a good idea to do as you propose: if the maintainer doesn't click a button for X months (and the button is prominent when you're logged in, impossible to overlook), make another fork a primary fork.
- TAForObvReasons 9y ago
  To first order, the network should show up for large projects that have many forks (Sometimes it says "Too many forks to display."). And it should be straightforward to distinguish forks with no updates from forks that have diverged from the main repo. Just being able to see forks with changes would be enough in many cases to at least open a conversation with the community.
deckar01 9y ago
I forked one of GitHub's own abandoned projects and noticed that it was archived when I received a flurry of notifications as all of it's issues were being closed automatically. It is actually a little harder to find the links to my fork now, because they were comments on the unresolved issues that were created when I migrated them to my fork. It might be useful to promote the "Network" graph a little more prominently once a project is archived.
- nerdponx 9y ago
  It seems like the network actually got harder to access in recent UI updates. It's a really useful feature when looking at repos of projects that haven't been updated in a few years.
  - jakub_g 9y ago
    FYI you can use http://forked.yannick.io http://forked.yannick.io to find the most starred / most forked fork. It would be really great if GitHub made something like that a built-in. On my side, I've been a Cordova developer for a while and I experienced many dead repos (I think most Cordova devs go native at one point). Fork reconciliation is an interesting issue but not sure how to implement it to prevent abuse. I once got an email from a guy who created a fork, sent an email to all the owners of the other forks who were ahead, to come up with a community fork, I think that's the best we can have for now. The main problem is how to signalize to other devs that you're interested in maintaining the fork and accepting PRs. One way could be to just comment on open issues/PRs on the dead repo to say "come to my fork", but when the repo is archived, seems it won't be possible anymore. So it would be actually harder now to create a community fork.
- mikemcquaid 9y ago
  Note that archived repository issues aren’t closed automatically. I did so manually but en masse before archiving some of GitHub’s deprecated projects this week so this may have been what you saw.
styfle 9y ago
This would be great! I’m actually dealing with this right now with a project[0] that was forked from an unmaintained repo that wouldn’t accept any pull requests. [0]: https://github.com/styfle/geoslack https://github.com/styfle/geoslack
Ajedi32 9y ago
I've been using this Chrome extension for that: https://chrome.google.com/webstore/detail/lovely-forks/ialbpcipalajnakfondkflpkagbkdoib https://chrome.google.com/webstore/detail/lovely-forks/ialbp... Really simple, and it actually works surprisingly well.

raziel2p 9y ago

How do you propose this to be done? I've been able to track down active forks by looking at the network graph before, but it's a bit hidden. The problem is, if there are any forks, it's difficult (or impossible) to objectively determine which fork is the "official" one.

deleted 9y ago
[deleted]
CyberShadow 9y ago
One simple way to do this would be: if a repository has had no activity (commits or comments) from owners/members, show a banner linking to the fork with the most stars.

jszymborski 9y ago

It'd be difficult to engineer that feature in a reasonable way, I think. Potential for abuse by hostile forks and ill-wishers would be a big problem and I can't think of any real mitigations. As is often hotly debated in HN comments, measures of repo inactivity/health are not universally accepted. I can see thresholds in any of these metrics potentially problematic if applied universally. I do sympathise with the pain-point you're outlining, however!

rcthompson 9y ago
I don't think such a feature is quite as difficult as one might think. The use case is for repos that are completely abandoned with an actively maintained fork, so you can be super conservative with the time frame in order to limit the possibility of abuse. Don't allow it for any repository with any activity from its owner in the past year, and give the owner something like 3 months from the time the request is initiated to refuse. If they don't respond, then the repo has been untouched for a minimum of 15 months. At that point, the requester gets their fork marked as the "canonical" repo, with a banner on the original repo informing people that it is unmaintained for X months and directing them to the maintained fork. Thereafter, if the the original repo's owner ever logs in, they could have a button on their repo to remove the banner, or alternatively confirm the transfer of maintainership (after which they can no longer take it back). In any case, the frequency of this kind of thing should be rare enough that it also would be reasonable to require approval by a human at Github for each one. Anyway, the above is one possible concept for such a feature that I think would be pretty resistant to any kind of abuse. But I'm not necessarily arguing in favor to this specific concept. In fact, given how rare such events would be, the most expedient "implementation" of this feature might simply be a dedicated email address and instructions on how to write up such a request for manual review, along with a stated policy of the minimum period of inactivity before a repo is eligible for such treatment. But my overall point is that with abandoned projects, I think you can slow down the timeline for transfer of maintainership to the point that abuse of the feature becomes essentially impossible.
- jakub_g 9y ago
  BTW, GH already has a feature that if a repo gets deleted, and it had forks, then the most starred (AFAIR) fork becomes the "master fork" and other forks have their link "forked from..." updated. It would be a good idea to do as you propose: if the maintainer doesn't click a button for X months (and the button is prominent when you're logged in, impossible to overlook), make another fork a primary fork.
TAForObvReasons 9y ago
To first order, the network should show up for large projects that have many forks (Sometimes it says "Too many forks to display."). And it should be straightforward to distinguish forks with no updates from forks that have diverged from the main repo. Just being able to see forks with changes would be enough in many cases to at least open a conversation with the community.

deckar01 9y ago

I forked one of GitHub's own abandoned projects and noticed that it was archived when I received a flurry of notifications as all of it's issues were being closed automatically. It is actually a little harder to find the links to my fork now, because they were comments on the unresolved issues that were created when I migrated them to my fork. It might be useful to promote the "Network" graph a little more prominently once a project is archived.

nerdponx 9y ago
It seems like the network actually got harder to access in recent UI updates. It's a really useful feature when looking at repos of projects that haven't been updated in a few years.
- jakub_g 9y ago
  FYI you can use http://forked.yannick.io http://forked.yannick.io to find the most starred / most forked fork. It would be really great if GitHub made something like that a built-in. On my side, I've been a Cordova developer for a while and I experienced many dead repos (I think most Cordova devs go native at one point). Fork reconciliation is an interesting issue but not sure how to implement it to prevent abuse. I once got an email from a guy who created a fork, sent an email to all the owners of the other forks who were ahead, to come up with a community fork, I think that's the best we can have for now. The main problem is how to signalize to other devs that you're interested in maintaining the fork and accepting PRs. One way could be to just comment on open issues/PRs on the dead repo to say "come to my fork", but when the repo is archived, seems it won't be possible anymore. So it would be actually harder now to create a community fork.
mikemcquaid 9y ago
Note that archived repository issues aren’t closed automatically. I did so manually but en masse before archiving some of GitHub’s deprecated projects this week so this may have been what you saw.

styfle 9y ago

This would be great! I’m actually dealing with this right now with a project[0] that was forked from an unmaintained repo that wouldn’t accept any pull requests. [0]: https://github.com/styfle/geoslack https://github.com/styfle/geoslack

Ajedi32 9y ago

I've been using this Chrome extension for that: https://chrome.google.com/webstore/detail/lovely-forks/ialbpcipalajnakfondkflpkagbkdoib https://chrome.google.com/webstore/detail/lovely-forks/ialbp... Really simple, and it actually works surprisingly well.