I've been doing this a very very long time and I must admit, submitting patches to other people's projects is still very much intimidating. Sure, I can go through the mechanics of forking a repository, pulling down the code locally, making a change, pushing it up, and opening a pull request; but how do I know what change to make? and further, how do I know that the people I'm sending the change to will like it?
In my experience, there's a few things that have been most helpful:
Start with the stuff you're using/learning/interested in. It's far easier for me to understand the context of a project and how I can help if it's a thing I've been using or learning. In fact, 99% of my OSS contributions are to projects that I use in client projects or that I am trying to learn on my own.
Apply sand-paper, not a sledgehammer. OSS maintainers are often unpaid volunteers holding out hope that maybe, just maybe, someone will also like the thing they built. This is less true in commercial open source, but in either case a small change is going to be easier to understand, test, and integrate than a larger change.
Improve the stuff that calls to you. Most of my initial contributions to a project are small bug fixes that I stumbled upon or documentation changes that confused the crap out of me. Most OSS maintainers love documentation improvements, and they provide a way to start building rapport with the project maintainers.
Ditch the projects that don't want you. Investing your time and attention into a project where the maintainer doesn't (really) want your help is a frustrating experience for everyone. If you start getting whiffs of frustration or entitlement, there are greener pastures. And who wants to use software that is maintained by someone who treats volunteers poorly?
Thanks so much! That makes a lot of sense. I actually did a PR for a documentation issue. It was just a comma in the wrong place but made me trip over the sentence when I was trying to read it. They actually told me they weren’t going to merge it because it’s trivial and will probably end up getting changed again. I’m assuming that’s the type of people to stay away from.
Hey Nicole,
I've been doing this a very very long time and I must admit, submitting patches to other people's projects is still very much intimidating. Sure, I can go through the mechanics of forking a repository, pulling down the code locally, making a change, pushing it up, and opening a pull request; but how do I know what change to make? and further, how do I know that the people I'm sending the change to will like it?
In my experience, there's a few things that have been most helpful:
Start with the stuff you're using/learning/interested in. It's far easier for me to understand the context of a project and how I can help if it's a thing I've been using or learning. In fact, 99% of my OSS contributions are to projects that I use in client projects or that I am trying to learn on my own.
Apply sand-paper, not a sledgehammer. OSS maintainers are often unpaid volunteers holding out hope that maybe, just maybe, someone will also like the thing they built. This is less true in commercial open source, but in either case a small change is going to be easier to understand, test, and integrate than a larger change.
Improve the stuff that calls to you. Most of my initial contributions to a project are small bug fixes that I stumbled upon or documentation changes that confused the crap out of me. Most OSS maintainers love documentation improvements, and they provide a way to start building rapport with the project maintainers.
Ditch the projects that don't want you. Investing your time and attention into a project where the maintainer doesn't (really) want your help is a frustrating experience for everyone. If you start getting whiffs of frustration or entitlement, there are greener pastures. And who wants to use software that is maintained by someone who treats volunteers poorly?
Good luck out there!
Thanks so much! That makes a lot of sense. I actually did a PR for a documentation issue. It was just a comma in the wrong place but made me trip over the sentence when I was trying to read it. They actually told me they weren’t going to merge it because it’s trivial and will probably end up getting changed again. I’m assuming that’s the type of people to stay away from.
Yea, I would consider that a yellow flag; as there is a mismatch between what the maintainer views as meaningful and what you do.
Good luck!