4 ms·

Step 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 ab

Step 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: 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. Step 42: And this is how you become a contributor to high-profile projects like Docker, Akka, Spark etc, and now free to boast about it in your CV!

gosubpl 10y ago
https://xkcd.com/386/ https://xkcd.com/386/ Disclaimer: I am an akka and akka-http community contributor. I don't know how this works for other projects. But I don't think the process is as painful as you describe in the akka world. My experiences are quite to the contrary. The community here is warm and welcoming. But, please look at this from the other side. Would you use the software in your mission critical application if the project was accepting quickly contributions from random strangers on the internets? Please, find an issue marked as community in https://github.com/akka/akka/issues https://github.com/akka/akka/issues or https://github.com/akka/akka-http/issues https://github.com/akka/akka-http/issues and give it a go. How to solve the "credentialize yourself" problem? Be known to the commiters by first working on a docs issue.
- atemerev 10y ago
  I am half-joking, of course; when I have submitted my first (minor) PR to Akka, I thought "wow, that is probably the most complicated code I ever had to follow through!" So I expected that I could get many things wrong, and will have to correct them first. So I did. Akka community is excellent.
deleted 10y ago
[deleted]
logn 10y ago
> Step 4: In frustration... Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package. > Steps 5..41: ... I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and sincere thanks. There's no reason to treat contributors like junior devs you're trying to teach and guide. Sometimes that requires swallowing some pride in having the code be just right or means you may want to fix up a few things after the merge.
- tananaev 10y ago
  As a maintainer of small project I would say that it depends. If the code is really useful and contributor is not willing to fix any of my comments, I would merge it anyway and fix it myself. If the code is so bad that it would be easier for me to completely re-write it myself, I would reject it. I'd like to think that my code review comments are reasonable most of the time, so it doesn't usually take more than 2 or 3 iterations to complete a pull request.
- angry-hacker 10y ago
  Yes. I remember when my first ever request was accepted. The fev thanked and with next release I saw he changed few things in my code, small things. Nevertheless it made me more comfortable submitting pull requests and really happy at the time.
cloudjacker 10y ago
> And this is how you become a contributor to high-profile projects like Docker, Akka, Spark etc, and now free to boast about it in your CV! And get the same pay as everyone else that doesn't play any of these reindeer games, because recruiters already know how to find us and setup the interviews!
agibsonccc 10y ago
To be fair here: It's on both parties to be mature about this interaction. It is the responsibility of the developers of the project to be responsive though. I would just like to add that many open source projects you are looking at are funded by companies with salaried developers (all of the ones you listed are). These companies have customers that come first. Their has to be due diligence on what goes in to the code base. If you are ready to submit a pull request to a project and the developers are receptive to teaching then view it as a learning experience. Try to understand both sides though.
cyphar 10y ago
> 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 <these set of nits>"). Not all maintainers do this, but most learn to do this quite quickly.

gosubpl 10y ago

https://xkcd.com/386/ https://xkcd.com/386/ Disclaimer: I am an akka and akka-http community contributor. I don't know how this works for other projects. But I don't think the process is as painful as you describe in the akka world. My experiences are quite to the contrary. The community here is warm and welcoming. But, please look at this from the other side. Would you use the software in your mission critical application if the project was accepting quickly contributions from random strangers on the internets? Please, find an issue marked as community in https://github.com/akka/akka/issues https://github.com/akka/akka/issues or https://github.com/akka/akka-http/issues https://github.com/akka/akka-http/issues and give it a go. How to solve the "credentialize yourself" problem? Be known to the commiters by first working on a docs issue.

atemerev 10y ago
I am half-joking, of course; when I have submitted my first (minor) PR to Akka, I thought "wow, that is probably the most complicated code I ever had to follow through!" So I expected that I could get many things wrong, and will have to correct them first. So I did. Akka community is excellent.

deleted 10y ago

[deleted]

logn 10y ago

> Step 4: In frustration... Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package. > Steps 5..41: ... I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and sincere thanks. There's no reason to treat contributors like junior devs you're trying to teach and guide. Sometimes that requires swallowing some pride in having the code be just right or means you may want to fix up a few things after the merge.

tananaev 10y ago
As a maintainer of small project I would say that it depends. If the code is really useful and contributor is not willing to fix any of my comments, I would merge it anyway and fix it myself. If the code is so bad that it would be easier for me to completely re-write it myself, I would reject it. I'd like to think that my code review comments are reasonable most of the time, so it doesn't usually take more than 2 or 3 iterations to complete a pull request.
angry-hacker 10y ago
Yes. I remember when my first ever request was accepted. The fev thanked and with next release I saw he changed few things in my code, small things. Nevertheless it made me more comfortable submitting pull requests and really happy at the time.

cloudjacker 10y ago

> And this is how you become a contributor to high-profile projects like Docker, Akka, Spark etc, and now free to boast about it in your CV! And get the same pay as everyone else that doesn't play any of these reindeer games, because recruiters already know how to find us and setup the interviews!

agibsonccc 10y ago

To be fair here: It's on both parties to be mature about this interaction. It is the responsibility of the developers of the project to be responsive though. I would just like to add that many open source projects you are looking at are funded by companies with salaried developers (all of the ones you listed are). These companies have customers that come first. Their has to be due diligence on what goes in to the code base. If you are ready to submit a pull request to a project and the developers are receptive to teaching then view it as a learning experience. Try to understand both sides though.

cyphar 10y ago

> 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 <these set of nits>"). Not all maintainers do this, but most learn to do this quite quickly.