5.13 KB
Newer Older
# How to contribute to Orfeo ToolBox ?
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Thank you for taking the time to contribute to OTB! This document will guide you
through the workflow and best practices you need to know to send your

There are many ways to contribute to OTB:

* [Reporting a bug](#reporting-bugs)
* [Making a feature request](#feature-requests-and-discussions)
* [Improving documentation](#documentation-improvements)
* [Contributing code (C++, Python, CMake, etc.)](#code-contribution)
* [Publishing a remote module](#remote-modules)

Our main workflow uses GitLab for source control, issues and task tracking. We
use a self-hosted gitlab instance:


Remember to check out also our [developers mailing list](!forum/otb-developers/join),
where we discuss some features, improvements and high level project planning.
You are welcome to ask questions there as a beginner or future OTB contributor!

## Reporting bugs

If you have found a bug, you can first [search the existing issues](
27 28
to see if it has already been reported.

If it's a new bug, please [open a new issue on GitLab](
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
The 'Bug' issue template will help you provide all important information and
help fixing the bug quicker. Remember to add as much information as possible!

## Feature requests and discussions

Feature requests are welcome! Generally you are welcome to simply [open an issue](
and discuss your idea there.

For complex and potentially controvertial ideas, we use Request for Comments.
RFCs are normal issues but which will need more discussion from the community
and usually a formal PSC vote. For this, use the 'Request for Comments' issue
template on gitlab. Older RFCs live on the [wiki](
More long term ideas are collected on the wiki [Wishlist](

For more peripheral contributions which do not belong in the main OTB
repository [Remote Modules](#remote-modules) are also a great option.

## Documentation improvements

The two main OTB documentations are the [Software Guide](
and the [CookBook](  Their sources are
hosted in the main OTB repository in the `Documentation/` directory. Then, to
contribute documentation use the same workflow as for code contributions (see

See also the [Compiling documentation](
wiki page for help on building the Sphinx and Latex source.

## Code contribution

The OTB workflow is based on GitLab [Merge Requests](
Clone the repository, create a feature branch, commit your changes, push the
feature branch to a fork (or the main repository if you are a core developer),
then send a merge request.

Note that we also accept PRs on our [GitHub mirror](

### Commit message

On your feature branch, write a good [commit message](
short and descriptive. If fixing an issue or bug, put the issue number in the
commit message so that GitLab can [crosslink it](
You can prefix your commit message with an indicating flag (DOC, BUG, PKG,
TEST, SuperBuild, etc.) or the name of the module you are changing.

75 76 77 78 79 80 81 82 83 84
Standard prefixes for OTB commit messages:

    BUG: Fix for runtime crash or incorrect result
    COMP: Compiler error or warning fix
    DOC: Documentation change
    ENH: New functionality
    PERF: Performance improvement
    STYLE: No logic impact (indentation, comments)
    WIP: Work In Progress not ready for merge

85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109
For example, here are some good commit messages:

    BUG: #1701 Warn users if parameter string is unset
    DOC: Fix typo in Monteverdi French translation
    COMP: Allow GeoTIFF and TIFF to be disabled when no 3rd party drags them
    Learning/Unsupervised: Add KMeans Shark implementation

### Merge request

Your contribution is ready to be added to the main OTB repository? Send a Merge
Request against the `develop` branch on GitLab using the merge request

The merge request will then be discussed by the community and the core OTB
team. Larger contributions will require code review and a formal PSC vote.

## Remote modules

[Remote Modules]( are the prefered way if your contribution is about adding new classes or
application to bring new features to OTB. Remote modules are just like regular
modules, except they are not distributed inside OTB source code. Under some
conditions (dependencies, official acceptance process, etc.), we are also able
to distribute your remote module in the official standalone binaries. See [the wiki](
for more information.