Wir freuen uns über externe Beiträge zu RapidMiner (vormals YALE) und integrieren diese bei entsprechender Qualität gerne. Bevor Sie uns Ihre Beiträge schicken, folgen Sie bitte den folgenden Anweisungen.

• Bitte nutzen Sie nur die neuste RapidMiner-Version aus dem CVS für Ihre Entwicklung.
• Die bevorzugte Format Ihrer Beiträge ist eine Patch-Datei bezogen auf die neuste RapidMiner-Version aus dem CVS. Aber natürlich akzeptieren wir auch die Menge der geänderten oder neuen Quellcode-Dateien als Beitragsform.
• Stellen Sie bitte sicher, dass Sie den unten beschriebenen Programmierrichtliníen (Coding Standards) folgen.
• Nutzen Sie bitte existierende Quellcode-Klassen als Orientierung für Ihre eigene Programmierung. Dies hilft Ihnen nicht nur, bessere Einblicke in die grundlegenden Konzepte von RapidMiner zu bekommen, sondern garantiert auch einen einheitlichen Programmierstil, der für eine gute Qualität, Wartbarkeit und Erweiterbarkeit von RapidMiner wünachenswert ist.
• Wichtig: Damit wir Ihren Beitrag berücksichtigen können, müssen Sie ein Formular über die Teilung Ihres Urheberrechts (Copyrights) an Ihrem Beitrag mit uns ausfüllen, unterschreiben und uns schicken: Joint Copyright Assignment Formular. Sie behalten weiterhin alle Nutzungs- und Verwertungsrechte an Ihren Beiträgen, räumen uns aber diese Rechte gleichermaßen ein.

Zusendung von Beiträgen

Bitte senden Sie uns Ihren neuen Quellcode über den Feature Request Tracker, also die Erweiterungswunschverfolgung, bei der sie Erweiterungswünsche mit submit new (Link in der linken oberen Ecke der Web-Seite) abschicken können. Bei diesen Erweiterungswünschen können Sie auch Patch- oder Quellcode-Dateien als Anhänge (Attachements) mitschicken.

Programmierrichtlinien (Coding Standards)

Wir freuen uns über alle Beiträge -- vorausgesetzt sie folgen den hier beschriebenen Programmierstandards! Wenn Sie diesen Programmierstandards folgen, erleichtern Sie uns die Integration Ihrer Beiträge ins Gesamtsystem erheblich. Wir prüfen und formatieren Ihren Quellcode, bevor wir ihn integrieren, dass heißt es ist kein Problem, wenn Sie nicht alle Programmierrichtlinien vollständig erfüllen. Versuchen Sie einfach, so viele wie möglich zu erfüllen. Vielen Dank dafür.

1. Benutzen Sie bitte die neuste RapidMiner-Version aus dem CVS für Ihre Beiträge. Rückwärtskompatibilität ist ein Thema und Änderungen in Interfaces oder sogar (Datei)formaten sind sehr selten. Trotzdem sind derartige Änderungen bei neuen Hauptversionen möglich, weil wir denken, daß es für alle Entwickler besser ist, etwas zusätzliche Arbeit zu haben, die zudem von den Refactoring Tools der heutigen Entwicklungsumgebungen (IDEs) unterstützt wird, und hinterher eine verbessertes Programm zu haben, als für alle Zeit mit schlechten früheren Design-Entscheidungen leben zu müssen.
2. Unsere Programmierrichtlinien (Coding Standards) folgen den SUN Java Coding Conventions inklusive den Programming Practices, jedoch mit einer großen Ausnahme: Variablen sollten deklariert und initialisiert werden direkt ehe sie benutzt werden und nicht schon am Anfang des aktuellen Blocks (siehe Abschnitt 6.3).
3. Der kurze RapidMiner-Lizenztext, den Sie sich einfach aus einer anderen RapidMiner-Quellcode-Datei kopieren können, muß in unveränderter Form _vor_ der package Anweisung in der Quellcode-Datei platziert werden.
4. Ihr Package sollte die selbe Package-Struktur haben wie RapidMiner selbst.
5. Nach der package Anweisung sollten alle import Anweisungen folgen, und zwar ohne Platzhalter (Wildcards) zu verwenden, d.h. z.B. import java.util.* sollte nicht verwendet werden.
6. Jede Klasse (class) und jede Schnittstelle (interface) _muß_ einen Klassenkommentar haben, und zwar vor der ersten Quellcode-Zeile der Klasse und neben dem eigentlichen Kommentartext auch ein Autor-Tag (@author) mit dem vollen Namen des Autors und ein Versions-Tag (@version) mit dem Makro $Id$, das durch das CVS mit der aktuellen RapidMiner-Versionsinformation ersetzt wird, beinhalten:

    

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

    

   Sie können HTML-Elemente in den Kommentaren nutzen, aber verwenden Sie bitte keinen physikalischen Markup (<b>,<i>, or <tt>), weil die Operatorreferenz des RapidMiner-Tutorials automatisch aus den Klassenkommentaren generiert wird.
7. Beginnen Sie die Implementation Ihrer Klasse mit statischen Deklarationen und Konstanten, gefolgt von Feldern, gefolgt von Konstruktoren, gefolgt von allen abstrakten Methoden, gefolgt von allen nicht-statischen Methodenimplementationen, gefolgt von allen statischen Methoden.
8. Implementieren Sie Ihre Klasse entsprechend den oben genannten Konventionen. Wenn es sich bei Ihrer Klasse um einen neuen RapidMiner-Operator handelt. Bitte orientieren Sie sich bezüglich der für einen Operator erforderlichen Methoden an der entsprechenden Beschreibung in der RapidMiner-Dokumentation. Die folgenden Dinge gelten für die Implementierung von Operatoren:
   1. Die erste Methode nach etwaigen abstrakten Methoden sollte die Methode apply() sein.
   2. Die letzte Methode des Operators sollte getParameterTypes() sein.
   3. Alle anderen nicht-abstrakten und nicht-statischen Methoden sollten dazwischen platziert werden.
   Diese zusätzliche Struktur erleichtert die Suche nach Klassenelementen.

Eine letzte Bitte: Versuchen Sie bitte, kurze Klassen und Methoden zu programmieren und doppelte oder redundante Quellcode-Anteile zu vermeiden. Lange oder doppelte Quellcode-Teile sind fast immer ein Anzeichen dafür, dass etwas falsch oder zumindest sehr ungünstig modelliert oder umgesetzt wird.