Hey all! So I'm trying to understand some things about GitHub. I've gotten good at using terminal to commit and push / pull to my own repositories and whatnot.
What I'm not grasping is how people contribute to other people's repositories. If you can only see the code, how can you make sense of exactly what to contribute? I understand how to fork and make a pull request and everything, I just don't know what to contribute or how people know what to contribute. Help? :)
Top comments (13)
There's several ways that you could try.
1) ask. Try contacting the owner and ask where/if you could help
2) find things that you miss in a project and implement that
3) there's issues. If you find a project with open issues, comment on an interesting issue and let them know you're interested in fixing that.
this suggestion actually inspires me out of massive repositories on that regarding volunteering for projects out of interests.Thanks.
Thanks for the suggestions :)
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!
Don't worry, you're not missing anything obvious. It is sometimes a matter of guessing and asking the right questions. It's never totally clear.
People are usually okay with receiving speculative PRs that may fix something, as long as you're humble about it.
Ultimately it can take a while to get right. You can start with lower barrier things like documentation issues, just to get a feel for the flow.
You're always welcome to find projects to make PRs such as this one on behalf of DEV 😄
oh cool! I'll check that out too.
Did my first pull request :) It was a comma that didn't need to be there.... but still lol.
What you can do is check the repo issues and see if there is something you can do :D
Thanks! From there how do I find the file that the issue is in?
That part's on you. Unit tests will help you sometimes, other times you'll have to trace the flow of execution yourself (or write tests), still other times grep is your best friend. But every situation is different and the only way to learn is by doing.
More on tests as documentation:
Avoid the Code Crawl by Reading Tests
Brandon Martinez
Without docs or good tests, it's going to be a matter of search, trial, and error, as Dian is saying.