We highly appreciate external contributions to RapidMiner (formerly YALE). Before sending in any contributions, you have to comply with the following instructions.

• Please use the latest CVS version for your development.
• The preferred format of contributions is a patch file against the latest CVS version. However, we of course also accept the set of changed or new code files.
• Please make sure that you follow the coding standards described below.
• Use existing classes as a guide for your own coding. This not only helps to get a better insight in the concepts of RapidMiner but also ensure a unique coding style.
• Important: you have to complete, sign, and send to us a Joint Copyright Assignment form.

Submitting Contributions

Please submit new code via the feature request tracker where you can submit new feature requests (link in the upper left corner of the page). In these requests you can also attach (patch) files.

Coding Conventions

We highly appreciate all contributions - if they strictly follow the standards cited here! Following the coding standards is very nice for us but we are checking and formatting the code before it will included and it is no problem if not all requirements are fulfilled. Just try to meet as many as possible.

1. Please use the latest CVS version for contributions. Backward compatibility is an issue and changes in interfaces or even formats should be rare. However, those changes are possible for major releases, since we strongly believe that it is better for all developers to have some additional work (which is eased by the great refactoring tools of today's IDEs (Integrated Development Environments)) but an improved program than having to live with bad design decisions for all times.
2. The coding standards follow the SUN Java coding conventions including the programming practices but with one big exception: variables should be declared and initialized directly before they are used and not at the beginning of the current block (see section 6.3).
3. The short licence text of RapidMiner (copy from another source file) must be placed without changes _before_ the package statement.
4. The package should have the same package structure as RapidMiner itself.
5. After the package statement all imports should follow without wildcards, i.e. import java.util.* should not be used.
6. Each class / interface MUST have a class comment directly before the first class line including the actual comment text and an author tag (@author) containing the full name of the author and a version tag (@version) with the macro $Id$ which will be replaced by CVS:

    

   /** 
   * The comment... 
   * 
   * @author Ingo Mierswa 
   * @version $Id$ 
   */ 
   

    

   You can use HTML for the comment but please do not use physical markup (<b>,<i>, or <tt>) since the operator reference of the RapidMiner tutorial will be automatically generated from the class comments.
7. Start with static declarations and constants, followed by the fields, followed by the constructors, followed by all abstract methods, followed by all non static method implementations, followed by all static methods.
8. Write the class following the conventions stated above. If the class is an operator, please refer to the documentation for a description of the necessary methods. The following hold for the implementation of operators:
   1. The first method after the abstract method should be apply().
   2. The last method of the operator should be getParameterTypes().
   3. All other non abstract and non static methods should be placed in between.
   This additional structure eases the search for class elements.

One last request: please try to make short classes and methods and avoid double code parts. Long or double code parts are almost always indicators for something going wrong.