Fork Freshness is poking at an important problem. If the author of an open source project stops responding, then there is usually no obvious way for the project's community to reorganize or recognize a new leader or a replacement for the project. I agree with other commenters; I really don't want to talk about my dependencies on twitter to this bot.
Fork Freshness: Project lifespans in the Ruby ecosystem
21–30 of 38 posts
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#22Earlier quoted context omitted.
More active repos don't necessarily have more stars, maybe a better way to sort would be to have main repo followed by number of commits ahead, then number of commits behind. Most often what I find is a repo will have 3-5 dozen forks and the vast majority will either be far behind or have one or two localizations. It is very rare that I find something that someone has really forked and started doing active developmen…
I think sorting forks by most recent commit would good enough. Not sure why GitHub doesn't do more to help with discoverability
btw, iirc GitLab does give you the option of sorting by most recent commit.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#23Fork Freshness is poking at an important problem. If the author of an open source project stops responding, then there is usually no obvious way for the project's community to reorganize or recognize a new leader or a replacement for the project. I agree with other commenters; I really don't want to talk about my dependencies on twitter to this bot.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#24I usually just use https://techgaun.github.io/active-forks/index.html Any chance this could be made not to rely on Twitter?
hi! I made Fork Freshness. that alternative is much faster, but it relies on the `pushed_at` attribute from the GitHub REST API. I was unable to find documentation for that attribute, but I rejected the GraphQL equivalent, `pushedAt`, because if Dependabot pushes to an otherwise dead repo with a PR to auto-update some dependency, `pushedAt` treats that as recent work. I didn't want to write a robot which chased anoth…
That blog post is the same link for this thread.
> without creating a User model
A User model isn't necessary if you don't require login to use your tool.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#25Earlier quoted context omitted.
Nice. I wonder whether the posted tool offers any more data since this tool is instantaneous and the posted one is slow. It would be great to know, for example, "commits ahead of". EDIT: found a few! [1] is easiest to use. For [2] you need to give it a github access token. [1] https://stackoverflow.com/questions/54868988/how-to-determin... [2] https://github.com/dragongling/Better-Github-Forks
it does! although the reason I use a different strategy is not for more data, but for better data. see this comment: https://news.ycombinator.com/item?id=28984305
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#26I have noticed this issue that Fork Freshness tries to solve. My example is Twitter's project murder https://github.com/lg/murder When a project becomes unmaintained whether officially or unofficially, the future home is often lost unless the original points to the new home at the top of the README file. You can dig within GitHub in the Insights > Network section to get a visual glimpse of what has changed since. https://github.com/lg/murder/network The original repository put up a notice that the project is unmaintained and archived the project which effectively ends the project in practice. In this case, ervinb's fork seems to be the most active commits before being abandoned. https://github.com/ervinb/murder Other forks also had independent commits that never were pulled into other projects. Looking at the network method fails to differentiate 30 grammar fixes from 30 new features without digging into each promising looking fork. Even then, you may miss a single commit that included more work then the entirety of the other commits. Disclosure: I have not worked on murder.
This is a serious problem and I hope we solve it.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#27Earlier quoted context omitted.
hi! I made Fork Freshness. that alternative is much faster, but it relies on the `pushed_at` attribute from the GitHub REST API. I was unable to find documentation for that attribute, but I rejected the GraphQL equivalent, `pushedAt`, because if Dependabot pushes to an otherwise dead repo with a PR to auto-update some dependency, `pushedAt` treats that as recent work. I didn't want to write a robot which chased anoth…
> I wrote that up here, in a fairly gigantic blog post: That blog post is the same link for this thread. > without creating a User model A User model isn't necessary if you don't require login to use your tool.
User preferences, settings, interaction history, whatever can be stored in different models. The User model can be slim.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#28Is there a reason this requires a Twitter account? Seems like something I'd like to use but I don't have Twitter.
The article mentions it in the section "How It Works: UI"
I don't see why I should let Twitter know that I'm using this service. Furthermore I should log into Twitter in a browser tab and go there to check if the result arrived. On the other side I understand that it's hard to find a convenient asynchronous delivery mechanism. Email is what everybody has but it's hard to send thousands of emails for free and not to get into a spam list.
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#29I usually just use https://techgaun.github.io/active-forks/index.html Any chance this could be made not to rely on Twitter?
hi! I made Fork Freshness. that alternative is much faster, but it relies on the `pushed_at` attribute from the GitHub REST API. I was unable to find documentation for that attribute, but I rejected the GraphQL equivalent, `pushedAt`, because if Dependabot pushes to an otherwise dead repo with a PR to auto-update some dependency, `pushedAt` treats that as recent work. I didn't want to write a robot which chased anoth…
Same problem as stated here, repo owner moved on. Thankfully a few people have contributor access on the main repo so it hasn’t died yet. But I’m likely to go awol on it in the next few months and there’s no clear second in command to hand it to.
I’ve also been working with the GitHub api this weekend and I was wondering how pushed_at and updated_at were differentiated. Good to know re: dependabot
Re: Fork Freshness: Project lifespans in the Ruby ecosystem
#30This problem could be solved if Github simply sorted the list of forks by stars instead of alphabetically.
- hide any repo that hasn't seen any commits
- show commits ahead and behind as well as number of tags
- include issue tracker activity
- highlight those forks that were renamed which is often an indicator of a new package/gem being released from this fork
- Show a link from the main page of a repository to the most active fork to make it clear that there is an active fork at all.