6 ms·

Up for Grabs

170 points by fybs 5y ago

upforgrabs 5y ago
Why is this in the #1 spot from a relatively new account, few upvotes, and no comments? dang?
MattGaiser 5y ago
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.
- existencebox 5y ago
  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.
- moonchild 5y ago
  A minor, fringe contribution is, ideally, a stepping stone to larger, more substantial contributions.
- enriquto 5y ago
  > 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.
  - laumars 5y ago
    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).
- ratww 5y ago
  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.
- fundamental 5y ago
  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).
- matkoniecz 5y ago
  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%3Apr+typo https://github.com/streetcomplete/StreetComplete/pulls?q=is%... (searching by "spelling" "wording" would also find some similar PRs)
deviation 5y ago
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 https://news.ycombinator.com/item?id=10830618
ruined 5y ago
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+first+issue%22+ https://github.com/Exiv2/exiv2/issues?q=label%3A%22good+firs...
Liquidor 5y ago
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`.
Aeolun 5y ago
That is a lot of effort to go through to get your project listed.
- fundamental 5y ago
  Is it? The documentation ( https://github.com/up-for-grabs/up-for-grabs.net/blob/gh-pages/docs/list-a-project.md 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.
deleted 5y ago
[deleted]

170 points by fybs 5y ago

Why is this in the #1 spot from a relatively new account, few upvotes, and no comments? dang?

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.

existencebox 5y ago
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.
moonchild 5y ago
A minor, fringe contribution is, ideally, a stepping stone to larger, more substantial contributions.
enriquto 5y ago
> 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.
- laumars 5y ago
  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).
ratww 5y ago
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.
fundamental 5y ago
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).
matkoniecz 5y ago
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%3Apr+typo https://github.com/streetcomplete/StreetComplete/pulls?q=is%... (searching by "spelling" "wording" would also find some similar PRs)

deviation 5y ago

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 https://news.ycombinator.com/item?id=10830618

ruined 5y ago

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+first+issue%22+ https://github.com/Exiv2/exiv2/issues?q=label%3A%22good+firs...

Liquidor 5y ago

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

Aeolun 5y ago

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

fundamental 5y ago
Is it? The documentation ( https://github.com/up-for-grabs/up-for-grabs.net/blob/gh-pages/docs/list-a-project.md 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.

deleted 5y ago

[deleted]