Organization

The MULTIPLY platform is divided into several components. For each of these components there is a repository on GitHub. To guarantee that coding conventions are followed, the rights to write to a repository are restricted. For each repository, there is one repository manager and one deputy. They will have writing rights. Others who want to work on one of the repositories should create a fork of the repository ( https://help.github.com/articles/fork-a-repo/ ), implement their changes there and then create a pull request ( https://help.github.com/articles/creating-a-pull-request-from-a-fork/ ) . The repository manager (or the deputy) should then review the pull request and either accept it or give feedback on what needs to be changed so that the request will be accepted. In particular, repository managers should make sure that

• conventions are adhered to
• new functionality is working (tests are created)
• old functionality is still working (old tests still work)

The repository managers and their deputies - as agreed on during the Coding Workshop - are:

Repository	Manager	Deputies	Link
Coarse Res Pre-Processing	José (UCL)	Tonio (BC)	https://github.com/multiply-org/coarse-res-pre-processing
Data Access	Tonio (BC)	Olaf (BC)	https://github.com/multiply-org/data-access
Emulation Framework	José (UCL)	Tonio (BC)	https://github.com/multiply-org/emulation-framework
Forward Operators	Thomas W. (LMU)	Tonio (BC)	https://github.com/multiply-org/forward-operators
High Res Pre-Processing	Feng (UCL)	Olaf (BC)	https://github.com/multiply-org/high-res-pre-processing
Inference Engine	José (UCL)	Tonio (BC)	https://github.com/multiply-org/inference-engine
Prior Engine	Joris (UL)	Tonio (BC) / Thomas R. (LMU)	https://github.com/multiply-org/prior-engine
Post-Processing	Joris (UL)	Tonio (BC)	https://github.com/multiply-org/post-processing
SAR Pre-Processing	Thomas W. (LMU)	Tonio (BC)	https://github.com/multiply-org/sar-pre-processing

Orchestration is - for now - included in multiply-core, to where everyone in the MULTIPLY Team has writing rights. If it is moved to another directory, the repository manager will be Tonio and the deputy Olaf. There is not yet a dedicated manager or deputy for the visualization repository.

Versioning

As each component is independent of the others, they have their own version number that increases independently of the other components. For assigning versions, please use the Semantic Versioning Scheme ( http://semver.org ) and PEP-440 ( https://www.python.org/dev/peps/pep-0440/ ). In a nutshell, for a three digit version (such as x.y.z)

• the first digit shall be increased when a change has been introduced that makes it incompatible to older versions
• the second digit shall be increased when new functionality has been added and it still is compatible to older versions
• the third digit shall be increased when minor changes (such as bug fixes) have been made and it still is compatible to older versions Versions under development shall be indicated by a trailing .devX, where X is any number. Version 0.4.dev2 is then higher than 0.4.dev1 which is higher than 0.3, but all are lower than 0.4.

Setting up the project

To access python code (or else) from other MULTIPLY repositories than the one you are working on, it will be necessary to execute the following command in the repository you want to use: python setup.py develop . This will cause that an egg-file is placed in your Python's site-packages directory, which holds a reference to the repository code. The python package in that repository can now be used in your repository (or whenever calling python, for that matter). When the code is changed, this change will also be available in the site-packages directory, meaning that you will always work with the latest version.