How do you start contributing to open source in GitHub as a beginner?
Posted by Actual_Help_8657@reddit | learnprogramming | View on Reddit | 17 comments
How do you guys actually contribute to open source on GitHub?
I’ve got basic experience with Git and coding, but I’m a bit stuck on how to go from “I can code” to actually contributing to real projects.
Do you just pick an issue and start working on it? Or is there a proper process I should follow (like contacting maintainers first, etc.)?
Also, how did you find your first project to contribute to?
Would appreciate any advice or personal experiences.
HybridM@reddit
Biggest tip: pick something you actually use, way easier to stay motivated.
The137@reddit
Probably a lot of other great info in this thread, I can only offer my limited perspective. I contributed to a project while I was still in boot camp. I stumbled across a project that didn't have a feature I needed, I thought I could get away with coding it, and I reached out to the maintainer. Figured he would give enough of a spot check to whatever I submitted, then I struggled thru writing something over my current level, but it all worked out. I say go for it, you're not going to break anything
White_C4@reddit
Read both README.md and CONTRIBUTING.md (if they provide them) which will help you figure out how the project works and how to participate in it.
Yeah, just pick and go with it. Most open-source projects are not strict on contributions. But make sure to read the comments first in the issue ticket to make sure the issue is still ongoing. Try to avoid issues that are new because they're likely already being worked on by the maintainer or someone else. In that case, check out pull requests to make sure none of them are linked to the issue.
Kitty_Sparkles@reddit
Hello! 👋 Open-source maintainer (and occasional contributor) here. I don’t know that there is a universally approved etiquette, but here are some pointers from my perspective:
- Pick a software you use and appreciate! It can be a library, a tool or whatever. Ideally the more niche the better, because helping a solo maintainer with their software is probably more meaningful than wanting to contribute to React or Next.js who has dozens of official maintainers.
- I would recommend supporting with open issues rather than adding unprompted features. If you would like to fix something for which there is no open issue, open one first! Explain your problem, and how you suggest fixing it. Once you and the maintainers are on the same page, roll with it.
- Keep in mind a lot of maintainers are actually quite burnt by people recklessly throwing AI at problems. As I shared in another post, your ability to use AI as a random contributor is definitely worse than the maintainers’ ability to use AI in their project that they know intimately. That doesn’t mean you can’t use AI, but it should be a tool for you to contribute, not the whole solution.
- Be sure to read through the repository for guidelines and rules (README.md, CONTRIBUTING.md, documentation, wiki, etc.). If there are tests in place, make sure they pass, and add some to cover whatever you are working on! If your work impacts the documentation, update it as well. In other words, don’t stop once the main lines of code were written: do the whole feature well.
I hope this helps a bit. :)
Made-In-Slovakia@reddit
Nice comment. Only thing I can add is: if you pick open-source project you like and use daily, try connect with community of developers around it, maybe they have Discord server where you can chat together and get even more than from discussion under GitHub issues.
_SeeDLinG_32@reddit
Well said, thanks!
EyesOfTheConcord@reddit
Find any repo written in JavaScript, fork it, make a new branch locally, convert it all to typescript in a single commit then open a pull request titled “enhancement”
/s
Kitty_Sparkles@reddit
Don’t forget to call the current implementation “legacy code.”
crawlpatterns@reddit
honestly i overthought this a ton at first, it’s way simpler once you just try. most people start by picking small issues labeled like “good first issue” and just giving it a shot, worst case you learn something and it doesnt get merged. reading the repo docs and maybe leaving a quick comment like “hey can i take this” is usually enough, maintainers dont expect perfection. also fixing tiny stuff like typos or docs helped me get comfortable before touching actual code, kinda builds confidence slowly
IAmANobodyAMA@reddit
Not like this 🤣
https://medium.com/@asarav/verify-the-pull-request-and-merge-asap-an-autopsy-of-how-not-to-make-a-pull-request-and-how-to-not-1a389d28baff
Conscious-Pace7669@reddit
April1987@reddit
Make your own. Seriously. Start your own repos. Wok on this code from multiple machines. Don't hesitate to clone other people's repo and push them to yours. There is no need to push the fork button.
Keep doing your own thing.
TechBriefbyBMe@reddit
Yeah just pick an issue and start. The "proper process" is just reading the contributing.md file, which everyone skips anyway and then gets told to read it in the first comment.
IshYume@reddit
I fix stuff that annoys me or a feature I WANT
dkopgerpgdolfg@reddit
This is very much project-specific.
As a general statement, aside from technical topics and project policies, have a look at the licensing conditions first before you contribute (including contributors agreements if there are any).
Born-Election8498@reddit
start with good first issue labels
PoePlayerbf@reddit
There’s no good first issues labels anymore lmao, all of them are immediately taken and done by AI.
It’s been like this for like the last 2-3 years.
When I first contributed back in 2018 it wasn’t like that. A lot of open source projects needed people to do small changes.