Hopefully my previous post on contributing to open source code at any skill level inspired you to get coding on an open source project, or at least look into joining a project or two. I’m back with four more ways to contribute to an open source project, this time with no coding at all! Again, you don’t have to be a programming wizard to do any of these things! All it takes is some time and a commitment.
Let’s get started.
Listen up!
Working with other people is one of the great things about open source projects. What a great way to build team work and communication skills! Part of being on a team/project means understanding the community you are joining and how it works. Walking into a project and saying “Hi, I’m new and don’t know what’s going on … and here’s what I think this project should be doing” will not be taken very well. Some (cough, very few) projects will welcome that sort of approach. Listen up so you know what the project needs and how you can help.
1. Join a project email list: If you are new to open source, you may not realize that the mailing list is the main method of communication surrounding the development of the open source project. If you don’t sign up for the distro list, you will likely miss out on key information! Sign up for the main user-oriented list and the core developer list to start listening effectively.
2. Follow the project blog: Blogs maintained by the project’s core developers and contributors often give information about future and previous releases. This is great way to get caught up on the project without having to ask another team member to catch you up. Self-sufficiency is an appreciated trait to have, especially in open source teams!
What do you do if there is no project blog (or the blog isn’t updated)? Check for the project’s planet site. A planet site aggregates news and blog entries from many sources related to the project (not just the blog). If there is a planet site, like planet.gnome.org or planet.mysql.com, start there. Just search Google for “planet <projectname>.”
Work with Tickets
Code is the heart of any open source project, but don’t be discouraged if you “can’t code”. Writing code is not the only want to contribute! In fact, maintenance of code and the systems surrounding the code often are often overshadowed by the rush to create new feature and fix bugs. Focusing on these areas is an easy way to get your foot in the door!
Most open source projects have a publicly visible issue ticketing system that is linked from the project’s website and included in the documentation. This system is the primary path of communication between users and developers. Keeping the ticket system current is a great way to help the project. Talk to the project leader if you need special permissions to view the tickets — they will most likely be thrilled that you want to help!
3. Diagnose a bug: In case you didn’t know … bugs are often poorly reported i.e. don’t have all the necessary information needed to fix an issue. Diagnosing and triaging a bug will help project developers save time because they will not have to figure out the specifics of the problem. For example, if a user reports, “The software doesn’t work when I do X,” you could spend some time figuring out the specifics of that problem. Is it repeatable? Can you create a set of steps to cause the problem repeatedly? Are you able to narrow down the problem?
Don’t worry if you can’t figure out what caused the ticketed problem. The effort put into narrowing down the circumstances will make it easier for someone else to fix it. Remember to include everything you tested/discovered/solved to the ticket in the support system for all to see.
4. Close fixed bugs: Often bugs are fixed in the codebase but the accompanying ticket(s) that reported them don’t get updated inside the ticketing system. Cleaning up closed tickets can be time-consuming but it’s valuable to the whole project.
Here’s how to do a clean sweep:
- Start by querying the ticket system for tickets older than a year and see if the bug reported still exists.
- Check the project’s release change log to see if the bug was fixed and can be closed. If it’s known to be fixed, note the version number in the ticket and close it.
- Try to recreate the bug with the latest version of the software. If it can’t be recreated with the latest version, note that in the ticket and close it. If it still exists, note that in the ticket as well and leave it open.
What are other ways you can contribute to an open source project without knowing how to code? Please discuss in the comments below.
Image Credit: Flickr, rahuldlucca