Being A Non-Coding Contributor

 I am not a programmer. With that last statement many would be surprised to also learn I am heavily involved with a software project.

Though I don't write code, I do handle a lot at the project tracking site. Bug reports, documentation, Answering questions, writing FAQs and blueprints.

I write most of the blueprints for the project, act as the bug report manager and I am the main contact for answering questions when they come in. Even had to answer one question in Spanish though I barely speak a word of it. Love translation programs.

The point is I am doing a lot for the project, freeing up time for the developers handling the day to administration that would otherwise fall behind. Its also a statement that even non-coders can become big time contributors to projects.

This is an important realization for people. You don't have to write code to help on a project. There are many aspects of project development that you can help with:

Specification Tracking: Drafting Blueprints for developers to work from. You only need a basic understanding of software operations and standards to do this. Blueprinting a feature basically involves stating what the feature is, how it should work and even in some cases how it should look. Most often you will most likely build a Blueprint from a bug report, as many bug reports are feature (or lack of) requests.

Bug Tracking: This one is a lot harder because some bug reports are really questions, some are feature requests and some are legitimate issues. Experience in beta testing will be very helpful here. Also knowing the software that is being developed is vital as well. Basically you have to decide if the bug reported is one of the above three. If its a question or a feature request then obviously its not a bug and should be reclassified appropriately. Keep in mind though you may decide to make a report a question only to later find out its actually a real bug. However running the issue as a question allows you to create a much more accurate bug report if necessary.

Answering Questions: This is usually where people can help the most. If the software project proves to be popular (as the one I am working on has) among users then people are going to need some level of support. Helping others fix small to large issues or referring them to the correct FAQ can be tremendously helpful to the developers. They don't always have the time to answer a question. The hardest part of dealing with a question is narrowing things down till a resolution is reached. This is a great way in honing your trouble shooting skills. Sometimes you will know what the answer is, or you know there is a FAQ that has the answer. One should always refer the question to the available FAQ if possible before stepping into the world of step by step trouble shooting. Most questions I work on find themselves becoming a FAQ. This is because it keeps me from having to trouble shoot the same issues over and over when I can send the user straight to the answer. Does the FAQ I send them to always work? Nope, but I either update that FAQ with more information or create a new one when done trouble shooting that particular issue.

Step by step trouble shooting is very tedious because its all done by email. Sometimes you will give an answer and sometimes you will need ask a question. I honestly have a sense of accomplishment when I help someone resolve an issue. Especially when we spent days working on it. (Yes I have had those happen and yes they are now FAQs.)

One of the last things I do is try to get people involved. Coders, interface designers and graphic artists in my case. I even try to find people to help me do the day to day stuff. Our project is small but popular. More popular than we expected to become really.

Small to large projects are always looking for help. Non-coders can be very helpful in the right project. It is time consuming but well worth it if one is looking to get a sense of being part of the community.