The idea behind the organization of the Coalevo project is to encourage an open, collaborative and consensus-based development process. This process depends on individual volunteers which become involved and increasingly responsible in organizing the development based on merit (it's a Meritocracy).

The first thing you should know when you are interested in contributing to this project are its Project Guidelines. These Guidelines define the roles that one can represent and establish the base procedures for the development process itself.

The by far most important role in the Project plays the User. On one hand, the user community can help the project with passive contributions like reporting bugs and making feature requests. On the other hand they can help each other (giving Tips or answering Questions of other Users).

A User can become a Contributor when he starts to actively contribute to the project submitting documentation or documentation patches as well as code and code patches, which will be incorporated into the project by a Committer who assumes the responsibility.

With frequency, amount and quality of contributions a Contributor can become a Committer. When this happens, write access to the process repositories will be granted as soon as the Contributor Agreement (CA) has been signed and received by the VFI.

Note

The Contributor Agreement has the purpose of clarifying the intellectual property rights for contributions, as well as to establish terms of use of the project infrastructure (which might be provided by third parties requesting such terms of use from the VFI itself.
This agreement is for your protection as a Contributor as well as the protection of the VFI and its users; it does however, not change your rights to use your own Contributions for any other purpose. Please read it carefully before signing.

How to Contribute

Rule number one is don't let yourself be intimidated by the level of appearent expertise required for this "stuff".

When you see something that you think should be added, or that doesn't seem to work quite right for you, remember rule one and start to investigate the existing related code and documentation.
On the way it is likely that you will get more and more familiar with the codebase. Don't hesitate to ask when you don't understand why this is happening, don't forget to mention that you are investigating the issue to help out. This discussion of ideas will help you and others to gain knowledge and to become more involved and known to the active developer community. At some point in time you might propose a patch or a new piece of code or documentation that is accepted into the codebase.

Iterating the above a few times, probably with bigger chunks of code or documentation, you will gain more understanding and at some point in time it will become evident that your expertise has raised you far above the dummy level and you can get nominated and elected for committer status.

Note

It all starts by becoming familiar enough with the existing codebase and documentation to be able to understand it and often involves "how does this work" type questions on the developer list. Don't feel bad about it, absolutely NONE of us knew anything about the internals of the Coalevo project, before we started working on it.

Note

We have integrated JIRA with SVN and Fisheye, so you may find it interesting to see resolved/closed Issues and trace how they have been implemented in code. This is a great way to learn how to get around in the codebase, make updates and add new stuff.