I’m not too sure about that, actually. I’ve always wanted to volunteer in open source, but have found parts of the learning curve pretty close to vertical. As a high school student with substantial experience in programming and algorithms à la the USACO and other diversions but barely any in actual development (project organization, version control, etiquette &c.), I find it a bit of a Catch-22 that open source usually demands basic development skills but that the best way to acquire those same skills is apparently open source (or an internship). I’ve found [resources that are supposed to help with the process] but none of them really seem to lower the activation energy quite enough.
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.
Figure out what technologies the open-source project uses, then google “X tutorial” for each such X. Or get an book on X. Build a simple app of your own using X, then start to extend it by searching an X reference for information on what you want to be able to do. Google ruthlessly whenever you run in to problems. (Professional software developers are Googling constantly.)
You may want to check out OpenHatch, a project that, among other things, organizes open-source projects you can help with by difficulty and language. This should help a lot with the learning curve. There are also some “missions” for beginners that teach development skills like how to use version control or apply a patch.
Edit: Huh, looks like all the available tasks are “bitesize” difficulty right now. I don’t recall that being the case before.
Working on your own projects first, even if they’re small things and not likely to be used by other people, could be an easier way to learn the basics. Building things from scratch can be easier than trying to understand someone else’s code.
The using git, installing things on Linux, and co-ordinating with people already on the project were the parts of the learning curve that I still struggled with after learning programming in college. If you have any friends who do open source, maybe ask them to help you get set up to work on the same project? For the technical difficulties, I had to just keep googling and trying other things until I figured it out, in a lot of cases. It took a lot of patience to do it that way.
I’m not too sure about that, actually. I’ve always wanted to volunteer in open source, but have found parts of the learning curve pretty close to vertical. As a high school student with substantial experience in programming and algorithms à la the USACO and other diversions but barely any in actual development (project organization, version control, etiquette &c.), I find it a bit of a Catch-22 that open source usually demands basic development skills but that the best way to acquire those same skills is apparently open source (or an internship). I’ve found [resources that are supposed to help with the process] but none of them really seem to lower the activation energy quite enough.
Am I approaching this from the wrong angle?
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.
Figure out what technologies the open-source project uses, then google “X tutorial” for each such X. Or get an book on X. Build a simple app of your own using X, then start to extend it by searching an X reference for information on what you want to be able to do. Google ruthlessly whenever you run in to problems. (Professional software developers are Googling constantly.)
You may want to check out OpenHatch, a project that, among other things, organizes open-source projects you can help with by difficulty and language. This should help a lot with the learning curve. There are also some “missions” for beginners that teach development skills like how to use version control or apply a patch.
Edit: Huh, looks like all the available tasks are “bitesize” difficulty right now. I don’t recall that being the case before.
Actually, OpenHatch was going to be the target of the ill-formatted link in my comment. Sorry about that!
Working on your own projects first, even if they’re small things and not likely to be used by other people, could be an easier way to learn the basics. Building things from scratch can be easier than trying to understand someone else’s code.
The using git, installing things on Linux, and co-ordinating with people already on the project were the parts of the learning curve that I still struggled with after learning programming in college. If you have any friends who do open source, maybe ask them to help you get set up to work on the same project? For the technical difficulties, I had to just keep googling and trying other things until I figured it out, in a lot of cases. It took a lot of patience to do it that way.