I started by reporting issues. My first reports were general descriptions of behavior. Gradually I learned enough about the project to identify which parts of the code had the issue and point to those in my issues. Eventually I managed to start actually fixing things.
I also support adding documentation. Often there are undocumented options in the code, or simple typos that are easy to fix.
Sometimes a library doesn't work correctly for my uses, either because of a bug or because our use case is slightly outside the norm for the library. In that case I'll fork it and see if I can get it to behave how I want. In these cases I generally submit a pull request, which sometimes gets merged and sometimes doesn't.
Oh, and sometimes when I update my framework a library will no longer install because the maintainer used pessimistic versioning. In that case I'll fork it, update the library's requirements, and see if it works in the new version, run tests, etc. Often times you can verify that it works and simply update the requirements without changing the code. This is an easy way to contribute that saves the maintainer's time.
In my experience, documentation is always welcome, and a great place to start, because you have to learn about the app to contribute to the documentation, which helps when/if you want to make a change to the code.
Also be sure to read the contribution guidelines. Good projects will make them very accessible.
Top comments (7)
I recommend, github.com/tldr-pages/tldr
There are a lot of open issues with
new command
that you can add,make sure to run the linter before PR.
thanks for your simple informative answer
Thanks for the resource
I started by reporting issues. My first reports were general descriptions of behavior. Gradually I learned enough about the project to identify which parts of the code had the issue and point to those in my issues. Eventually I managed to start actually fixing things.
I also support adding documentation. Often there are undocumented options in the code, or simple typos that are easy to fix.
Sometimes a library doesn't work correctly for my uses, either because of a bug or because our use case is slightly outside the norm for the library. In that case I'll fork it and see if I can get it to behave how I want. In these cases I generally submit a pull request, which sometimes gets merged and sometimes doesn't.
Oh, and sometimes when I update my framework a library will no longer install because the maintainer used pessimistic versioning. In that case I'll fork it, update the library's requirements, and see if it works in the new version, run tests, etc. Often times you can verify that it works and simply update the requirements without changing the code. This is an easy way to contribute that saves the maintainer's time.
Great Advice Thanks
In my experience, documentation is always welcome, and a great place to start, because you have to learn about the app to contribute to the documentation, which helps when/if you want to make a change to the code.
Also be sure to read the contribution guidelines. Good projects will make them very accessible.
Sure thanks for the advice