Contributing to an open source project
There are many ways to contribute to an open source project, and anyone can contribute, regardless of their skills. For instance, you can be active on the project mailing list and issue tracker, or you can supply patches. The developers' mailing list is the most appropriate place to ask for help when making one's first contributions. Let's look at some of the most common activities. [NEED TO IMPROVE INTRO]
The senior members of the project are always keen to know more about how users engage with its outputs and how they would like them to look. They therefore welcome feedback about the project in the form of discussions on users' mailing lists and feature requests added to the issue tracker. Usually, people are cautious about making requests or providing constructive criticism, for fear of seeming impolite or ungrateful, but this feedback is vital to the life of the project. Without it, the project cannot improve its usability, and usability is a key element that makes the project stand out among its competitors. Users should, therefore, be encouraged in every possible way to send along their ideas and suggestions. At the same time, they should be made aware that, while not every feature request will be implemented, each comment will be carefully considered and feedback will be provided on how important that request is perceived to be.
A simple and low-level way to help the project is by answering user questions. In addition to helping novice users, this activity will also help developers, as answering questions takes precious time they could otherwise spend adding features and fixing bugs. Helping others is also an excellent way for users to learn more about the project themselves. Another side effect is that those who help others are more likely to receive help when they need it. Finally, the archives produced by answering user questions form an important part of the project documentation, which is constantly being updated.
The lifeblood of any open source project is its users: more users means more opportunities for success. Feedback from users on what they want helps to ensure that the product is of increasingly good quality. You can help the project to attract new users by telling people about the project and encouraging them to try it out.
== Design and implementation == [<!> I'M CONFUSED ABOUT THE WORD 'DESIGN' HERE: IT SEEMS THAT WE MEAN SOFTWARE DESIGN, AS OPPOSED TO WEB DESIGN, WHICH IS DISCUSSED IN 5.6? CAN WE CLARIFY HERE?]
In a software development project, programming is often thought of as the most important form of contribution. While it is obviously critical, a good design and a useful feature set are also vital. It is important that all significant code contributions are discussed on the developers' mailing list before implementation. This allows the project to ensure that the design is appropriate and the user experience is not adversely affected. Smaller contributions, such as bug fixes, can be provided as patches on the issue tracker without discussion.
Quality assurance (QA) is one of the most important elements of any project. It is also something almost anyone can contribute to. Users can help by testing release candidates before they are formally released, while programmers can help by fixing bugs identified in the issue tracker. Another important element of quality assurance is keeping people informed of activity on issues in the issue tracker. For example, each new issue should be examined and commented on. Duplicates should be marked as such and workarounds should be highlighted.
Graphics and art
Programmers are rarely good at interface and web design. Users with graphics or art skills can create icons, logos, banners, labels and other artwork. These will be seen every day and used throughout the project and its products. Users with such skills should be encouraged to join the developers' mailing list and submit their artwork proposals via the list.
Documentation is critical to new users. One of the best ways in which users can contribute to the project is by documenting their own experiences in the form of tutorials, guides, HOW TOs or FAQs. They don't have to be perfect: in most cases, a skeleton document with bullet-point instructions is better than nothing at all. Those who use the document will ask supplementary questions and, once they understand, will help to pad out the details.
Some of the kinds of documentation that can be contributed to a project are described below.
User FAQs (frequently asked questions) are an excellent place to start contributing to a project. One can contribute by supplying patches as described below. Non-technical people can simply post a note in the issue tracker with a proposed FAQ entry. [<!> PATCHES NOT DESCRIBED BELOW]
HOW-TOs and tutorials
These are short, self-contained documents, and generally a great place to start for both users and contributors. If one enjoys a particular feature, documenting it for others is an extremely welcome contribution.
Writing a comprehensive user guide for the project is a hard job that requires a lot of time and effort. Additions, clarifications and corrections to the documentation from users is very much appreciated. The users' mailing list archives contain a lot of material that can be easily converted into paragraphs for the user guide, and the community is always willing to help documentation authors.
To contribute to the developer guide, one needs some technical expertise. If you have such expertise, this is a great place to start gaining an understanding of how to develop with or for the project. Existing documentation can be improved, or new content can be written. Plenty of useful material can be found in the developers' mailing list archives, and the developers themselves are usually happy to help documentation authors.
The default language for most projects is UK English, [<!> IT WAS UK ENGLISH FOR PROJECT X. IF WE GO FOR MORE GENERAL 'MOST PROJECTS', SHOULD WE CHANGE TO 'UK OR US ENGLISH' - IF INDEED THIS IS THE CASE?] which may not be helpful to users in other regions of the world. Committed users can make a huge difference by translating the project into other languages. These users should be encouraged to join the developers' mailing list to find out how to share their translation work.
Monetary donations and developer support
For an open development project, money is less important than active contribution. However, some people or organisations are cash rich and time poor. Providing a secure, popular, easy-to-use mechanism for accepting donations will allow various categories of sponsors to express their appreciation for the project as a whole. At the same time, some users may find that a particular developer, or group of developers, have been especially helpful, and they may want to send them some kind of reward. A voucher for an online store usually goes down well and is easy to provide. This should be done privately rather than through the public lists.
If someone wants to make a significant donation, they can sponsor a developer to implement some new feature or fix some bugs. On joining the developer mailing list, they can be pointed in the direction of an independent third party, who will help find the right developer and handle cash transactions.
[<!> NEED A CONCLUSION]