But what about designers?
Debian needs some help from artists:
How to contribute to an open source project on GitHub
71–80 of 98 posts
Re: How to contribute to an open source project on GitHub
#72For 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…
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.
Re: How to contribute to an open source project on GitHub
#73Earlier quoted context omitted.
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…
> 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 dow…
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.
Re: How to contribute to an open source project on GitHub
#74This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project. Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason…
To sum all that in a nutshell: Collaborate.
Re: How to contribute to an open source project on GitHub
#75Step 1: stumble upon a terrible bug (or that really obvious missing feature that _should_ be there) in your favorite library / framework / app. Step 2: rant about it on HN / Github issues / whatever. Step 3 (optional): try to reach developers on GitHub and get the obligatory "pull requests are welcome" response. Step 4: In frustration, clone the repository, fix the damn bug and submit your pull request. Steps 5..41:…
> Steps 5..41: have an angry and emotional discussion with the devs who refuse to accept your PR because broken binary compatibility / regression tests / coding style / your choice of variable names etc. Fix all these issues and resubmit the PR until it's accepted.
As a maintainer, I can completely see where you're coming from here and some of nits that I have against PRs probably seem quite trivial. However, if you have a fairly large project then as a maintainer the onus is on us to make sure that things don't break (and that the project remains manageable). Not to mention that the argument people use (that we should just make a follow-up commit that fixes the PR so it's actually acceptable) doesn't _really_ work if you're someone who has to do bisects often -- I'm not going to merge code that is clearly wrong in several places (unless the code is returning a "not implemented" error).
It's not a pride thing, as maintainers we have much less time than the contributors (there are fewer of us than there are of you) so we can't carry every PR that someone drops on our issue tracker.
Of course, for runC we have automated testing that verifies that things like golint and gofmt succeed (so we don't have to waste time going back-and-forth with contributors about it). Lots of smaller projects don't do this, which leads to nothing but annoyances for contributors.
Also, in general when reviewing a change I try to state whether or not the idea is sound. If I am commenting on your choice of variables or how you've structured your algorithm, that means that I like the idea (and is an implicit "I will merge this once you fix "). Not all maintainers do this, but most learn to do this quite quickly.
Re: How to contribute to an open source project on GitHub
#76Wow! When you want to fix a typo, it can be as little as two hours!
To be honest, typo fixes are fairly draining as a maintainer in large projects. Especially if it's a small (one-line) fix.
Yeah, I get that you want to contribute and that's awesome (one of the best things about free software is that everyone can contribute). But the relative benefit of the actual change versus the time-to-check-the-PR and time-to-reach-consensus-with-another-maintainer is quite low in most "typo fix" PRs.
If you're going to make a typo fix PR, please at least run a spell checker on the file that you're doing the typo fix on (and even better run it on the whole repo). Because at least then, your PR has a higher benefit ratio.
That being said, if you still make a typo fix PR I will merge it eventually. Just be aware that I sigh out loud each time I get a notification for typo fix PR, and I will almost certainly put other things higher on my priority list.
Re: How to contribute to an open source project on GitHub
#77Earlier quoted context omitted.
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…
> 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 dow…
> 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.
Re: How to contribute to an open source project on GitHub
#78This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project. Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason…
To sum all that in a nutshell: Collaborate.
I'm curious to see what others think about your comment, notyourwork. To me (maybe only me!) it looks like you're putting a pithy stamp on what the GP said. Going a little farther, it looks to me like you're taking credit for what the GP said. I do not see the value of saying, "To sum all that in a nutshell: Collaborate." I see a value in what the GP said.
That said, this is the first time I've criticized this kind of comment. I've seen people pithily-sum-up others a lot. If others disagree with me, I'll take that into account.
Re: How to contribute to an open source project on GitHub
#79This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project. Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason…
> Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired.
I think all that matters is that the change is something you want. If no one else has any need for it, you can continue using it as long as you wish to maintain your fork.
It's great to collaborate and share ideas before you start working, but if it's something you need, you'll do it even if everyone else says it's pointless.
Re: How to contribute to an open source project on GitHub
#80This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project. Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason…
There is, however, value in submitting a PR without diving into the often stalemating "discussion" happening in a lot of projects. As much as I wish it weren't the case, I have found over the years that if your code follows conventions, works, and is useful, asking for forgiveness is much, much easier than asking for permission.