An easy first step is to just report the problem with the documentation when you find it. Something can’t get fixed if it’s not found, and reporting bugs should be pretty simple through the github interface for your standard project.
As for contributing fixes, you’ll need to have a little experience with forking, creating pull-requests etc, but the nice thing is that these are basically free to play around with for open source projects on git-hub (or bitbucket). Most documentation will be in one of a few basic formats in the project’s source code (markdown is popular, as is re-structured text for python projects). These are usually designed to be relatively easy to edit, and are fairly simple to find tutorials and introductions for.
Another way you can help out without fixing bugs is by triaging existing bugs. Not all projects need these, but a lot of larger ones have a problem with just sorting through bugs to find what matters, what’s urgent, what’s a duplicate, or a won’t fix etc. Many are more than happy to welcome a new volunteer on board who can just read through new tickets as they come in and set labels such as ‘duplicate’ or ‘blocker’. Being involved in the process in this way, you can then follow along seeing how the existing core developers go about fixing bugs, and pick up from there.
An easy first step is to just report the problem with the documentation when you find it. Something can’t get fixed if it’s not found, and reporting bugs should be pretty simple through the github interface for your standard project.
As for contributing fixes, you’ll need to have a little experience with forking, creating pull-requests etc, but the nice thing is that these are basically free to play around with for open source projects on git-hub (or bitbucket). Most documentation will be in one of a few basic formats in the project’s source code (markdown is popular, as is re-structured text for python projects). These are usually designed to be relatively easy to edit, and are fairly simple to find tutorials and introductions for.
Another way you can help out without fixing bugs is by triaging existing bugs. Not all projects need these, but a lot of larger ones have a problem with just sorting through bugs to find what matters, what’s urgent, what’s a duplicate, or a won’t fix etc. Many are more than happy to welcome a new volunteer on board who can just read through new tickets as they come in and set labels such as ‘duplicate’ or ‘blocker’. Being involved in the process in this way, you can then follow along seeing how the existing core developers go about fixing bugs, and pick up from there.