How to contribute

We are thankful for every contribution!

First of all, we are happy about every piece of code/documentation that you contribute! Since we have not got a publicly writable Subversion repository, there are some things that you should know before sending contributions. This is mainly to save us integration work, but also to save you frustration, in case something is implemented in parallel.

The following paragraphs address some important points, but if you are in doubt about something, feel free to ask on the mailinglist

Documentation contributions

If you have spent some time to figure out how some things work, which are currently undocumented but regularly used in MITK, you may want to share your knowledge with other users. Sometimes even some short lines of explanation help to learn about new classes.

Classes in MITK are documented using doxygen. So it is easiest for us, if you send us pieces of documentation as expected by the doxygen parser. For some formatting issues, you may want to read the doxygen manual, especially the list of keywords. Check the source of mitk::DataTreeFilter for some example formatting (and doxygen usage).

Code contributions

Generally, the above paragraphs about documentation are valid for code as well (i.e. please document your code!).

Before you start coding

To avoid redundant/parallel implementations, you should consider telling us your plans before you really start coding. Preferably, you use the MITK mailing list, so everybody knows about your plans.

Announcing your ideas has the additional advantage that we may provide some useful hints/ideas/suggestions, that may save you work.

Some rules

There are some rules about naming classes and files. Please try to follow them!

If you change existing classes, please start from the latest Subversion revision! Occasionally check for updates of these classes or tell us if you want to get notified of updates, so that merging will result in less conflicts. One thing you should not do, is create copies of the MITK files you are about to change and simply omit the mitk:: namespace or the Qmitk part in class names. This makes it extremely difficult to produce diffs between your code and the original code.

We greatly appreciate if you provide tests for any newly introduced classes.

When your code compiles without errors (and warnings)

Once you have implemented something, you can send it via the mailing list for small changes or preferably open a bug at our BugTracking and add your patch as an attachment there.