Hacker News Reader

Comment by cthulhuology | Hacker News Reader

For many projects, Github is just a place to publish yet another public repo. Using github issues and pull requests is a sure fire way to feel ignored. If you want to contribute, e-mail the lead maintainer. Do not submit patches to the ether. Do not think anyone will look at your patches. Having started several large open source projects, and started / worked for a number of open source companies, I can tell you the best way to get involved is to work on your personal relationship with the other developers. If that means hanging out in IRC or Slack, that's what it takes. Github is a terrible form of communication, especially when your org / developers have 100+ repos.

View on HN

That doesn't sound like a sound advice.

If the author of the repo can't be bothered to look at the issue or a PR then I don't see how they'll be receptive to emails.

Most projects don't have other ways of contacting the people involved (very few list their e-mail addresses and even less have dedicated irc or slack channels).

Yes, it happens way too often that issues and PRs are ignored but realistically it's a strong signal to stop investing more time into such projects because it's unlikely things will improve.

> If the author of the repo can't be bothered to look at the issue or a PR then I don't see how they'll be receptive to emails.

There's an assumption here that GitHub is automatically more convenient and desirable than an email or other project management tools. That's not a universal sentiment; not everyone wants to participate in the GitHub social network, and even tools themselves that GitHub offers are a step down depending on who you ask (like the pull request mechanism and issues and what they try to pass off as a "wiki" and...)

So just because a project and its maintainers don't have a big showing on GitHub, don't assume that means anything about the health of the project. It may just mean they have better places and ways to spend their time and get things done.

> Most projects don't have other ways of contacting the people involved

Why do you think the email field that shows up in git's log was put in place? Honest question.

Why do you assume everyone fills it up ? Honest question.

While it's true github isn't the "best tool" for everything in the world (what is?), I find it mostly serves as a discovery tool. If I have a bug in a project, I'll first look at the issues/PRs for other people who might have fixed the damned thing. And it often turns out there are. The original author might have abandonned the project, or he might have a different way to handle contributions, but that doesn't matter to ME. I care about having my fix, upstreamed or not.

> Why do you think the email field that shows up in git's log was put in place? Honest question.

to provide a unique identifier for the author of the commit, and a means for finding the public key you should use to check the signature.

> e-mail the lead maintainer.

Check that there is not a mailing list first. This is where the "read the contributing guide" kicks in.

I for example have quite a lot of filters, that make sure I reply to mailing lists, but if you email me directly, you may end up lumped in with all the commercial "include my $thing in your project please" emails (purely by accident)

While it's true you might want to email the author and all, having a PR is great for one thing: letting other people looking for the bug/feature find the fix before it's upstreamed.

This is what I usually do with my PRs. I first submit the PR so it's there for other people to grab if they need it, and then I'll look into the "proper" way of upstreaming the fix.

This avoids duplication of work and enhances discoverability.

Reply on news.ycombinator.com