Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
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.
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.