5 ms·
This 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
by jhchen 10y ago
This 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. Instead engage and discuss the Issue first and make sure it's actually something the project wants.
Don't just start writing code. Familiarize yourself with the codebase. This comes naturally if you are a user of the project, as you will naturally run into bugs or learn the software's behaviors and as you discuss the Issue or features with maintainers. There are far fewer right ways to build a feature than possible ways.
Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.
- notyourwork 10y agoTo sum all that in a nutshell: Collaborate.
- delish 10y agoI'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.
- kahrkunne 10y agoYour 2 paragraph criticism of one a one sentence comment is way more obnoxious and contributes less. What he was trying to do is summarize and give a one word interpretation/other way of looking at it, not trying to do something insidious and inane as trying to steal credit for an HN comment. Sometimes it helps to have a point summed up in the briefest possible way. What never helps, though, is posting inane accusations of ulterior motives to HN comments.
- pitay 10y agoI have to agree with delish on this matter. Notyourwork's comment actually took away from the conversation. jhchen's assertions of, "be familiar with the project", "don't just start writingcode", and "your contribution is not free for the project" is not summed up nicely with the word "collaborate". To some people, collaborate might mean to put in a pull request without caring whether it is wanted or not, the exact opposite of what the OP said. "Collaborate" can be taken in so many ways that it is useless, and in this instance actually takes away from the message. A closer summary of what the OP said is "Don't waste the project maintainers time" which, while much better than "collaborate", is still a waste of time and misses the specific advice the OP gives. Delish is justified in calling out notyourwork's comment for providing nothing useful. If I wrote a comment like the one notyourwork wrote I would be feeling guilty for writing a comment just for points. Also the size of a comment is not a good basis for criticism.
- nicky0 10y agoJust stop.
- notyourwork 10y ago> 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. The response was a long winded way of saying collaborate with people and don't work in a closed box. I was merely trying to summarize that open source can be a simple and beautiful thing. It's not complicated to get involved but tossing pull requests over the wall isn't the way to do it which brings us back to precisely what I said. Sorry you didn't find value in it.
- no_protocol 10y ago> 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.
- fapjacks 10y agoThere 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.
- sdrinf 10y ago| Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is. Understand code interactions: they scale N^2 with each new feature added. Specifically, each interaction your feature has with all the other features has to be coded, and then each new feature might interact with yours. This is the curse of scope freak. It is the sole responsibility of the PM/owner of the project to select which features worth this.