<html>
<!--
Copyright (C) 2005, 2006 Joe Walnes.
Copyright (C) 2006, 2007, 2013, 2015 XStream committers.
All rights reserved.
The software in this package is published under the terms of the BSD
style license a copy of which has been included with this distribution in
the LICENSE.txt file.
Created on 29. January 2005 by Joe Walnes
-->
<head>
<title>How to Contribute</title>
</head>
<body>
<p>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 <a href="mailing-lists.html">mailing list</a>. This is also the place to discuss further
development of XStream.</p>
<h2 id="help">Help</h2>
<p>The correct place if you are looking for help is the <a href="mailing-lists.html">mailing list</a>. You
get there a much wider audience from other users and also the developers are reading and answering there
your questions.</p>
<h2 id="documentation">Documentation</h2>
<p>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!</p>
<h2 id="examples">Examples</h2>
<p>We are working on one or two examples of using XStream, but we can always do with more.</p>
<h2 id="feature-requests">Feature Requests</h2>
<p>We eat our own dogfood, but we're also happy to feed other people's dogs (if you'll excuse
a stretched <span style="text-decoration:line-through">dachshund</span> metaphor!). If you want to
request a new feature you can either make a request through the <a href="issues.html">issue tracker</a>
or by sending a message to the <a href="mailing-lists.html">mailing list</a>. 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.</p>
<h2 id="bug-reports">Bug Reports</h2>
<p>You can report bugs through the <a href="issues.html">issue tracker</a> 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
<a href="mailing-lists.html">mailing list</a>. Additional brownie points are awarded for bug reports that
include a failing unit test.</p>
<h2 id="patches">Bug Fixes</h2>
<p>If you want <em>lots</em> 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 <a href="license.html">same license as XStream itself</a>.</p>
<h2 id="new-code">New Code</h2>
<p>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.</p>
<h2 id="your-own-extension">Write Your Own XStream Extension</h2>
<p>If you have a project that builds upon XStream we will be happy to announce your
project on the XStream site.</p>
<h2 id="become-committer">Become a Committer</h2>
<p>We follow the former Codehaus manifesto when it comes to expanding the core team.</p>
<ol>
<li>The Codehaus recognizes that some committers, based upon metrics, longevity and appointed
management, have greater say on a project than others.</li>
<li>The Codehaus is a place where people are encouraged to get on with code rather than tie
their projects up with bureaucracy.</li>
<li>The Codehaus encourages projects to strive for quality and for frequent small releases.</li>
<li>The Codehaus encourages committers to be respectful friends, meet up with each other as often
as possible. Face-to-face is superior to email.</li>
<li>The Codehaus stands in favour of diversity (where appropriate) over enforced convergence and
homogeneity.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>In case of disagreement, The Despots are right.</li>
</ol>
</body>
</html>