Hey everyone!
This is actually my first post on here despite having lurked for some time without an account and then for a while even after creating one.
Anyways, I am currently a student studying computer science and over this summer I became much more aware of the concept of open source as well as the giant community that surrounds it and advocates for its practice. (I went to OSCON in Portland on a whim and learned a lot there).
However, I still find myself to be lost in where to start in terms of contributing to a project. I find myself getting in my own head about not knowing what or how I can contribute as well as if what I would contribute would make a difference at all.
I would appreciate any and all suggestions on things that I should keep in mind / resources that would help me get started! (and let me know if you guys have any questions about me that might help!)
Top comments (1)
The best way to learn is by doing.
Writing code is the easy part. The hard part is getting used to using git, github, and collaborating with other devs.
1. Learn how to adapt to the existing project workflow that a project uses
Always start by reading CONTRIBUTING.md
Some projects you just submit a PR and the maintainer merges it.
Some you have to claim an existing issue to implement a planned feature or your PR will be ignored.
Some you have to submit a CLA, write a RFC, wait a predefined period for cruticism/critiques from the community, then spec out the feature and start writing actual code.
Some projects are mature and don't require regular maintenance. Keep in mind, maintaining OSS projects takes a lot of time/effort. Most maintainers don't get paid for their work. Unless you have a lot (ie months) of patience, you'll probably be better off seeking out greener pastures.
2. Knowing how to work with the existing code instead of unnecessarily rewriting.
There is no better way to get a PR reject than to include a ton of unrelated stylistic changes.
Nobody cares how 'clean' you think the code you write is. Instead, aim to contribute with as little impact on the existing code as possible.
Treat it like you're a guest in their home. If you want to have more say in the direction a project takes, you have to earn it.
3. Start small. Like a feature that looks so easy you question, "why is this even a feature request to begin with."
The answer to that question is, good maintainers put a lot of thought into creating an environment where contributors can get a start.
Sure, it probably requires more work to create issue and outline a spec than it would take to implement. That's because those issues were created for your benefit.
Here's a good place to start:
github.com/TroyTae/game-of-life/is...
Claim the issue. Implementation requires defining a 2D array to match the spec'd life form.
The maintainer is also very active, shouldn't take long to get your PR reviewed and merged.