Up for Grabs | Hacker News Reader

Up for Grabs

up-for-grabs.net

170 pointsfybs28 comments

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.

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.

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.

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`.

and is also the double edged-sword that permits bad actors to take over popular packages and inject malware and other nasties :(

> 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.

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".

Check out 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.

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.

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.

> 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.

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

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

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 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/ . 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.

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.

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

Also, they replied in https://github.com/up-for-grabs/up-for-grabs.net/issues/2536...

> Do you have a solution or suggestion for this? How should we tackle this.

How practically beneficial are around the edge/minor issue contributors to projects? Between coding standards, formatting, and how long it takes for people to learn a codebase, are a bunch of new minor contributors actually all that helpful?

Asking as someone not meaningfully in the FOSS world, so I do not know either way.

My perspective as a maintainer is _surprisingly beneficial_ in aggregate.

The changes aren't necessarily going to be the most impactful, or most visible, but I'm sure you've seen after N years on a project all the small "I'd love to fix this but can't reasonably prioritize it" items that accumulate, and someone with less expertise may often be the perfect candidate to help burn that down (it also helps build that expertise in doing so.)

I can see situations in which there might be more difficult tradeoffs of "time spent vetting contributions/ramping up new people" vs. "utility per capita" but at least for the projects I've had touch on, there are always a healthy slice of up-for-grabs issues that I was/am more than happy to see get knocked off and were often reasonably self-contained, but would still contribute incrementally to the polish+overall-goodness of the project.

A minor, fringe contribution is, ideally, a stepping stone to larger, more substantial contributions.

> How practically beneficial are around the edge/minor issue contributors to projects?

I have received a few such "minor" PR and they are really welcome. Even re-wordings or clarifications of the project README file. Sometimes just adding a single sentence at the beginning of the README, by a random stranger, is helpful and makes it much more clear.

You can try that. If you find in the wild a project description that is a bit confusing, send a PR with a better choice of words. The developers will likely be thankful to you and accept your pull request.

I second this.

I’ve had a few PRs in the past which have just been tweeting grammatical errors or minor reworking to make sentences flow better and they’ve been fabulous.

Proof readers are a real, paid, profession. And if someone is spending their time enhancing my project by correcting any faults with the documentation then I welcome that just as much as source code submissions (and the README is often the most important document in all of your documentation).

Small PRs are great, IME. They're much easier to handle than bigger ones, so there are rarely downsides for maintainers.

Coding standards and formatting are rarely an issue in small PRs. Even if I don't have a CI, I can just run the linter/formatter on my side, or even fix by hand if it's small enough. Worst case? You get a code review.

Bug fixes are certainly always welcome, even if you just paste the fix in a Github Issue. Even just a reproduction is good enough and very welcome. Non-code contributions are also contributions.

Typos and change of phrasing? Adding examples to the documentation? Quick to check and quick to merge, awesome.

I'd say the only "small" contributions I ever denied were things that didn't add at all to the project: someone who tried to add hand-drawn logos to several of my repositories, trying to change the license, code that caused bugs or security issues and we couldn't really fix it, one-line PRs to the readme join the contributor's list, etc.

In terms of getting a lot of work done, not all that helpful. They are more useful for recruiting possible repeat contributors as well as generally helping maintainer morale (fast to review, though good first-timers-only style issues do take a lot of time to initially setup).

For tiny projects it is quite cool that someone contributed anything at all.

Even for larger projects for example fixing typos can be very useful - there are some projects where among main author none is a native speaker. So someone "only" contributing fixes to grammar mistakes can be very helpful!

See for example https://github.com/streetcomplete/StreetComplete/pulls?q=is%... (searching by "spelling" "wording" would also find some similar PRs)

This has been posted 6 times before, see this HN thread below if you want to read their discussion about it:

https://news.ycombinator.com/item?id=10830618

some of these appear to not actually have curated tasks. it lists exiv2 for example which links to an issues tag on github, but it's empty https://github.com/Exiv2/exiv2/issues?q=label%3A%22good+firs...

That is a lot of effort to go through to get your project listed.

Is it? The documentation ( https://github.com/up-for-grabs/up-for-grabs.net/blob/gh-pag... ) is verbose, but that appears to be an attempt to lower the barrier of entry. Each PR to add a new project seems to be just the addition of a single .yml file describing the project and associated tags.

Reply on news.ycombinator.com