XStream is nothing without contributions from the user community. There are many ways to contribute. We are constantly working on the software and documentation, so it's a good idea to contact the team. For question about usage or possible misbehavior, please contact us on the mailing list. This is also the place to discuss further development of XStream.

## Help

The correct place if you are looking for help is the mailing list. You get there a much wider audience from other users and also the developers are reading and answering there your questions.

## Documentation

One of the traditional weak points of open source software is the documentation. Any help with this aspect of the project will be welcomed with open arms, or at the very least with open email clients!

## Examples

We are working on one or two examples of using XStream, but we can always do with more.

## Feature Requests

We eat our own dogfood, but we're also happy to feed other people's dogs (if you'll excuse a stretched dachshund metaphor!). If you want to request a new feature you can either make a request through the issue tracker or by sending a message to the mailing list. The benefit of any new features will be discussed on the mailing list, so its a good idea to sign up so that you can stick your oar in.

## Bug Reports

You can report bugs through the issue tracker interface or in case you are in doubt whether it is really a bug or just a wrong usage, you may ask first posting to the mailing list. Additional brownie points are awarded for bug reports that include a failing unit test.

## Bug Fixes

If you want lots of brownie points, send a fix along with your bug report and failing unit test. Bug fixes are best sent as patches that we can apply to the codebase. Remember to tell us which version the patch should be applied against, or we'll get very confused. To be accepted into the codebase, patches must be released under the same license as XStream itself.

## New Code

If you have a new feature request, then we'll listen extra hard if you show us how it works. A new feature might be best implemented as a patch to an existing class or as a new class. The XStream API contains many extension points that allow new functionality to be integrated into the framework. We are rather anal about testing, so if you send us some code without any tests we will probably ask you to write the tests tests as well before we add it to the codebase.

## Write Your Own XStream Extension

If you have a project that builds upon XStream we will be happy to announce your project on the XStream site.

## Become a Committer

We follow the former Codehaus manifesto when it comes to expanding the core team.

1. The Codehaus recognizes that some committers, based upon metrics, longevity and appointed management, have greater say on a project than others.
2. The Codehaus is a place where people are encouraged to get on with code rather than tie their projects up with bureaucracy.
3. The Codehaus encourages projects to strive for quality and for frequent small releases.
4. The Codehaus encourages committers to be respectful friends, meet up with each other as often as possible. Face-to-face is superior to email.
5. The Codehaus stands in favour of diversity (where appropriate) over enforced convergence and homogeneity.
6. The Codehaus places a high bar on entry for committers. Referral is a common means. A new committer is expected to show strong character elements as well as a talent for code. Maturity and wisdom (possibly in advance of years if a youngster) should be demonstrated.
7. New committers to an existing project are expected to ease themselves in with small and deferrent commits to start, and greater free-will may be assumed later.
8. The Codehaus encourages people to be brief in email and to honor internet etiquette. Ten furlongs of text justifying a position is poor form; better would be a (failing) unit test.
9. In case of disagreement, The Despots are right.