1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting. Not glamorous, but it will let you understand the software structure and development practices.
2) Get involved in a more marginal project where they need all the help they can get, and contributing a new feature is easier.
3) Make your own project, like a webapp, that’s more aligned with the typical design and features of project you might be interested in, letting you understand relevant aspects of design and version control that USACO won’t teach. Don’t expect anyone else to contribute, this is just a fun project for you to build your skills.
1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting.
For a high school student it’s not straightfoward to know the step by step process he has to go through to contrubute bug-fixes or even documentation.
If you want to edited an Wikipedia page that’s a lot more straightforward than editing the documentation of an average open source project.
I personally have edited Wikipedia plenty of time and can’t remember contributing to open source documentation because the complexity of figuring out how to go about contributing is too high to bother in particular cases where I see something that might be fixed.
A step by step guide about how to go about fixing a simple bug would be very helpful.
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.
There are three ways to approach it.
1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting. Not glamorous, but it will let you understand the software structure and development practices.
2) Get involved in a more marginal project where they need all the help they can get, and contributing a new feature is easier.
3) Make your own project, like a webapp, that’s more aligned with the typical design and features of project you might be interested in, letting you understand relevant aspects of design and version control that USACO won’t teach. Don’t expect anyone else to contribute, this is just a fun project for you to build your skills.
For a high school student it’s not straightfoward to know the step by step process he has to go through to contrubute bug-fixes or even documentation.
If you want to edited an Wikipedia page that’s a lot more straightforward than editing the documentation of an average open source project.
I personally have edited Wikipedia plenty of time and can’t remember contributing to open source documentation because the complexity of figuring out how to go about contributing is too high to bother in particular cases where I see something that might be fixed.
A step by step guide about how to go about fixing a simple bug would be very helpful.
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.