markdown guide

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.


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.

Classic DEV Post from Aug 27 '19

How do *you* pronounce sudo?

Muhammad profile image
Full Stack Web Dev