[HN Gopher] Up for Grabs
___________________________________________________________________
Up for Grabs
Author : fybs
Score : 167 points
Date : 2021-06-14 02:17 UTC (20 hours ago)
(HTM) web link (up-for-grabs.net)
(TXT) w3m dump (up-for-grabs.net)
| deviation wrote:
| 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
| ruined wrote:
| 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...
| [deleted]
| upforgrabs wrote:
| Why is this in the #1 spot from a relatively new account, few
| upvotes, and no comments?
|
| dang?
| Liquidor wrote:
| 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.
| fundamental wrote:
| 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
| singhrac wrote:
| 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.
| Cthulhu_ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| and is also the double edged-sword that permits bad
| actors to take over popular packages and inject malware
| and other nasties :(
| codetrotter wrote:
| > 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 wrote:
| 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".
| toast0 wrote:
| > 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.
| withinboredom wrote:
| 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.
| akent wrote:
| 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.
| leifg wrote:
| 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.
| MattGaiser wrote:
| 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.
| moonchild wrote:
| A minor, fringe contribution is, ideally, a stepping stone to
| larger, more substantial contributions.
| existencebox wrote:
| 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.
| enriquto wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| Aeolun wrote:
| That is a _lot_ of effort to go through to get your project
| listed.
| fundamental wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-14 23:02 UTC)