You don't need to be a software developer to contribute to the ODF Toolkit. To be successful this project requires a range of different skills, levels of involvement and degrees of technical expertise. So, if you want to get involved in the ODF Toolkit, there is almost certainly a role for you.
We are looking for people to:
All of these contributions help to keep a project active and strengthen the community. The project team and the broader community will therefore welcome and encourage participation, and attempt to make it as easy as possible for people to get involved.
Your first engagement with the project should be to subscribe to our mailing lists.
The most important thing about engaging with any opensource project is that everyone is equal. All people with an opinion are entitled to express that opinion and, where appropriate, have it considered by the community.
To some the idea of having to establish consensus in a large and distributed team sounds inefficient and frustrating. Don't despair though, we still use the Apache Way, which has a set of simple processes to ensure things proceed at a good pace.
As in ASF projects we don't like to vote. Most of the time we work with the consensus building techniques documented below.
Lazy consensus is the first, and possibly the most important, consensus building tool we have. Essentially lazy consensus means that you don't need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.
Sometimes lazy consensus is not appropriate. In such cases it is necessary to make a proposal to the mailing list and discuss options. There are mechanisms for quickly showing your support or otherwise for a proposal and building consensus amongst the community.
Once there is a consensus people can proceed with the work under the lazy consensus model.
Occasionally a "feel" for consensus is not enough. Sometimes we need to have a measurable consensus. For example, voting might be a good tool before adding a new committers or to approve a release.