One problem with forks (for the case where it can be assessed that the author has indeed abandoned the project) is that existing issues, pull requests, stars and watchers aren't transferred to the new repo; in fact, a new repo is not even what's needed at all in this situation: new maintainers is what's needed.
I wonder if the Julia community should decide on some sort of guidelines for handling these cases. For example, we could require any package registered to METADATA.jl to provide administrative access to at least one person from the core maintainer team (I mention admin access rather than just commit rights, because then that person would be stuck as the maintainer if the original author goes MIA, since they wouldn't be able to give others --i.e. prospective new maintainers-- commit access). Of course, the guidelines should also specify that this admin access should not be used unless the author indeed goes MIA (say, for a set period of time without warning). One nice side-effect of such a procedure would be that if a serious bug or security issue is discovered in a dormant package, it can be addressed without disabling the package altogether from METADATA.jl. On Friday, September 2, 2016 at 11:48:13 PM UTC+1, Chris Rackauckas wrote: > > You can fork, update it, and then put a PR in to METADATA which changes > the url for the package. Someone like @tkelman will probably try to contact > the author to make sure he/she's really disappeared. Open an issue on > METADATA and see if the author shows up. > > On Friday, September 2, 2016 at 3:34:42 PM UTC-7, Evan Fields wrote: >> >> I use the package GreatCircle <https://github.com/acrosby/GreatCircle.jl> >> for >> great circle distance calculations. On 0.4.x it generates depwarns, and >> it's incompatible with 0.5. I've opened a pull request with the tiny >> changes needed to use the package on 0.5, but there's been no response and >> from the author's Github profile it looks like he/she is no longer >> generally active. Is there a way to rescue the package in this situation? >> (Besides perhaps forking and renaming, which leads to cluttered package >> names...) >> >
