## Aims

Maintenance of a library by decentralized team requires communication. It is important that developers follow guidelines laid down by the community to ensure that the code they create can be successfully maintained by others.

## Guidelines

Developers are asked to comply with the following development guidelines. Code that does not comply with the guidelines including the word must will not be committed. Our aim will be to fix all of the exceptions to the "should" guidelines prior to a release.

### Contributing

Getting Started

1. Download the Commons RNG source code. Follow the instructions under the heading "Repository Checkout" on the Git at the ASF page. The git url for the current development sources of Commons RNG is
http://gitbox.apache.org/repos/asf/commons-rng.git
https://apacheid@gitbox.apache.org/repos/asf/commons-rng.git
(where apacheid should be replaced by each committer Apache ID) for committers read-write access.
2. Like most commons components, Commons RNG uses Apache Maven as our build tool. The sources can also be built using Ant (a working Ant build.xml is included in the top level project directory). To build Commons RNG using Maven, you can follow the instructions for Building a project with Maven. Launch Maven from the top-level directory in the checkout of Commons RNG trunk. No special setup is required, except that currently to build the site (i.e. to execute Maven's "site" goal), you may need to increase the default memory allocation (e.g. export MAVEN_OPTS=-Xmx512m) before launching Maven.
3. Be sure to join the commons-dev and commons-user email lists and use them appropriately (make sure the string "[RNG]" starts the Subject line of all your postings). Make any proposals here where the group can comment on them.
4. Setup an account on JIRA and use it to submit patches and identify bugs. Read the directions for submitting bugs and search the database to determine if an issue exists or has already been dealt with.

See the Commons RNG Issue Tracking Page for more information on how to search for or submit bugs or enhancement requests.

5. Generating patches: The requested format for generating patches is the Unified Diff format, which can be easily generated using the git client or various IDEs.
git diff -p > patch
Run this command from the top-level project directory (where pom.xml resides).

Contributing ideas and code

Follow the steps below when making suggestions for additions or enhancements to Commons RNG. This will make it easier for the community to comment on your ideas and for the committers to keep track of them. Thanks in advance!

1. Start with a post to the commons-dev mailing list, with [RNG] at the beginning of the subject line, followed by a short title describing the new feature or enhancement; for example, "[RNG] New cryptographically secure generator". The body of the post should include each of the following items (but be as brief as possible):
• A concise description of the new feature / enhancement
• References to definitions and algorithms. Using standard definitions and algorithms makes communication much easier and will greatly increase the chances that we will accept the code / idea
• Some indication of why the addition / enhancement is practically useful
2. Assuming a generally favorable response to the idea on commons-dev, create a JIRA ticket using the the feature title as the short description. Incorporate feedback from the initial posting in the description.
3. Submit code as attachments to the JIRA ticket. Please use one ticket for each feature, adding multiple patches to the ticket as necessary. Use the git diff command to generate your patches as diffs. Please do not submit modified copies of existing java files. Be patient (but not too patient) with committers reviewing patches. Post a *nudge* message to commons-dev with a reference to the ticket if a patch goes more than a few days with no comment or commit.

### Coding Style

Commons RNG follows Code Conventions for the Java Programming Language. As part of the maven build process, style checking is performed using the Checkstyle plugin, using the properties specified in checkstyle.xml. Committed code should generate no Checkstyle errors. One thing that Checkstyle will complain about is tabs included in the code code. Please make sure to set your IDE or editor to use spaces instead of tabs.

Committers should configure the git repository or global settings for:

user.name
user.email

These settings define the identity and mail of the committer. See Customizing Git - Git Configuration in the git book for explanation about how to configure these settings and more.

### Documentation

• Committed code must include full javadoc.
• All component contracts must be fully specified in the javadoc class, interface or method comments, including specification of acceptable ranges of values, exceptions or special return values.
• External references or full statements of definitions for all the terms used in component documentation must be provided.
• Commons RNG javadoc generation supports embedded LaTeX formulas via the MathJax javascript display engine. To embed mathematical expressions formatted in LaTeX in javadoc, simply surround the expression to be formatted with either $$and$$ for inline formulas (or $and$ to have the formula appear on a separate line). For example, $$a^2 + b^2 = c^2$$ will render an in-line formula saying that (a, b, c) is a Pythagorean triplet: $$a^2 + b^2 = c^2$$.
See the MathJax and LaTex documentation for details on how to represent formulas and escape special characters.
• Implementations should use standard algorithms and references or full descriptions of all algorithms should be provided.

### Exceptions

• Exceptions generated by Commons RNG are all unchecked.
• All public methods advertise all exceptions that they can generate. Exceptions must be documented in Javadoc and the documentation must include full description of the conditions under which exceptions are thrown.

### Unit Tests

• Committed code must include unit tests.
• Unit tests should provide full path coverage.
• Unit tests should verify all boundary conditions specified in interface contracts, including verification that exceptions are thrown or special values (e.g. Double.NaN, Double.Infinity) are returned as expected.