4 ms·

The idea is great but... I checked out about 15+ smaller repositories with the "help wanted" labels and only one had active development. Most projects had sev

The idea is great but... 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.

Cthulhu_ 5y ago
Github (I presume it's all GH projects) should come up with a system that makes it easier to either take over stewardship of a codebase, or make active forks much more visible - I mean in theory if the steward of one project has effectively abandoned it, someone else can fork it and go from there. But in practice, that fork fixes one issue and gets abandoned as well, and nobody can find it (or nobody actively looks for it). 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.
- tn1 5y ago
  In the Perl world (and possibly others), the CPAN maintainers will transfer ownership/maintainership privileges to you if you can prove you haven't been able to contact the original author (typically by sending an email and CC'ing the perl5-modules mailing list). This works well when there is one or two distributions that are the canonical way to solve a task. Obviously not possible for GitHub as a whole, but perhaps we could reimagine how GitHub interacts with specific language/tool/whatever communities.
  - franciscop 5y ago
    This is very similar to how npm works! I got some simple name packages after the original authors didn't answer like `server` and `files`.
    - Jenk 5y ago
      and is also the double edged-sword that permits bad actors to take over popular packages and inject malware and other nasties :(
- codetrotter 5y ago
  > 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 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.
  - jerf 5y ago
    I think there's a balance between what they show now and what I'd like them to show, for sure. I certainly do not want GitHub to try to declare what an "official" repository is, in any form whatsoever. GitHub simply is not in a position to make that declaration, philosophically, practically, or any other way. 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".
- akent 5y ago
  Check out https://useful-forks.github.io/ https://useful-forks.github.io/ if you haven't seen it, agree it'd be great to have this kind of thing a lot more visible particularly on repos with no commits for like 6+ months or something.
- withinboredom 5y ago
  Just because a project doesn't have any recent commits, doesn't mean it doesn't work. Often you can look up it's forks and find a more active fork.
- leifg 5y ago
  I like that! 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.
- toast0 5y ago
  > Github (I presume it's all GH projects) should come up with a system that makes it easier to either take over stewardship of a codebase, or make active forks much more visible 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.
fundamental 5y ago
I'd support purging inactive projects in order to make the process easier for prospective contributors. Ideally there should be some specific rules that projects can use to see that they'd be filtered. It doesn't look like up-for-grabs upstream agrees though https://github.com/up-for-grabs/up-for-grabs.net/issues/2536 https://github.com/up-for-grabs/up-for-grabs.net/issues/2536
- matkoniecz 5y ago
  Do you remember how you looked for projects or even specific ones? I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781 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#issuecomment-869090795 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.
  - fundamental 5y ago
    I just clicked around for a while seeing mostly dead repos IIRC. If you want assistance for reviewing the age of a load of repositories I was looking into a commit metric similar to what's mentioned in the github thread. Example output of my script (fetches repos, gets stats, dumps output): https://fundamental-code.com/mruby-timeline/ 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.
singhrac 5y ago
Yeah, this should sort by most active contributions. Fwiw there are many open source codebases with lots of activity and are very friendly to newcomers.
matkoniecz 5y ago
Do you remember how you looked for projects or even specific ones? I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781 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#issuecomment-869090795 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.

Cthulhu_ 5y ago

Github (I presume it's all GH projects) should come up with a system that makes it easier to either take over stewardship of a codebase, or make active forks much more visible - I mean in theory if the steward of one project has effectively abandoned it, someone else can fork it and go from there. But in practice, that fork fixes one issue and gets abandoned as well, and nobody can find it (or nobody actively looks for it). 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.

tn1 5y ago
In the Perl world (and possibly others), the CPAN maintainers will transfer ownership/maintainership privileges to you if you can prove you haven't been able to contact the original author (typically by sending an email and CC'ing the perl5-modules mailing list). This works well when there is one or two distributions that are the canonical way to solve a task. Obviously not possible for GitHub as a whole, but perhaps we could reimagine how GitHub interacts with specific language/tool/whatever communities.
- franciscop 5y ago
  This is very similar to how npm works! I got some simple name packages after the original authors didn't answer like `server` and `files`.
  - Jenk 5y ago
    and is also the double edged-sword that permits bad actors to take over popular packages and inject malware and other nasties :(
codetrotter 5y ago
> 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 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.
- jerf 5y ago
  I think there's a balance between what they show now and what I'd like them to show, for sure. I certainly do not want GitHub to try to declare what an "official" repository is, in any form whatsoever. GitHub simply is not in a position to make that declaration, philosophically, practically, or any other way. 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".
akent 5y ago
Check out https://useful-forks.github.io/ https://useful-forks.github.io/ if you haven't seen it, agree it'd be great to have this kind of thing a lot more visible particularly on repos with no commits for like 6+ months or something.
withinboredom 5y ago
Just because a project doesn't have any recent commits, doesn't mean it doesn't work. Often you can look up it's forks and find a more active fork.
leifg 5y ago
I like that! 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.
toast0 5y ago
> Github (I presume it's all GH projects) should come up with a system that makes it easier to either take over stewardship of a codebase, or make active forks much more visible 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.

fundamental 5y ago

I'd support purging inactive projects in order to make the process easier for prospective contributors. Ideally there should be some specific rules that projects can use to see that they'd be filtered. It doesn't look like up-for-grabs upstream agrees though https://github.com/up-for-grabs/up-for-grabs.net/issues/2536 https://github.com/up-for-grabs/up-for-grabs.net/issues/2536

matkoniecz 5y ago
Do you remember how you looked for projects or even specific ones? I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781 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#issuecomment-869090795 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.
- fundamental 5y ago
  I just clicked around for a while seeing mostly dead repos IIRC. If you want assistance for reviewing the age of a load of repositories I was looking into a commit metric similar to what's mentioned in the github thread. Example output of my script (fetches repos, gets stats, dumps output): https://fundamental-code.com/mruby-timeline/ 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.

singhrac 5y ago

Yeah, this should sort by most active contributions. Fwiw there are many open source codebases with lots of activity and are very friendly to newcomers.

matkoniecz 5y ago

Do you remember how you looked for projects or even specific ones? I submitted pull request removing dead project and it was soon merged: https://github.com/up-for-grabs/up-for-grabs.net/pull/2781 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#issuecomment-869090795 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.