diff --git a/.gitlab/merge_request_templates/request_for_changes.md b/.gitlab/merge_request_templates/request_for_changes.md index 1683fac2c3b38dce963bfcc9472b3d19caf3723c..0f49873998b82139ab80fa96fe710300cca68a67 100644 --- a/.gitlab/merge_request_templates/request_for_changes.md +++ b/.gitlab/merge_request_templates/request_for_changes.md @@ -30,4 +30,4 @@ List remaining open issues if any, and additional notes. ### Copyright -[ ] I've signed the ORFEO ToolBox Contributor License Agreement +The copyright owner is *COPYRIGHT OWNER (OR OWNER'S AGENT)* and has signed the ORFEO ToolBox Contributor License Agreement diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c41028ef8a899bf37a9fa42db51a85ef805a9006..985c8e349de0fdee5191f10d5e6b56167e6c6ae7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,7 +13,7 @@ There are many ways to contribute to OTB: * [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: +use a self-hosted GitLab instance: [`https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb`](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb) @@ -62,7 +62,7 @@ which we will manually merge. On your feature branch, write a good [commit message](https://xkcd.com/1296/): short and descriptive. If fixing an issue or bug, put the issue number in the -commit message so that GitLab can [crosslink it](https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html). +commit message so that GitLab can [cross-link it](https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html). You can prefix your commit message with an indicating flag (DOC, BUG, PKG, TEST, SuperBuild, etc.). @@ -113,7 +113,7 @@ Again, the second branch name is optional. For users without push access to [otb-devutils repository](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils.git), the modification can be asked through a merge requests to this repository. -Once the feature branch is registered for testing, it should appear in the *FeatureBranches* section of the [OTB dashboard](https://dash.orfeo-toolbox.org/index.php?project=OTB) next day (remember tests are run on a nighlty basis). +Once the feature branch is registered for testing, it should appear in the *FeatureBranches* section of the [OTB dashboard](https://dash.orfeo-toolbox.org/index.php?project=OTB) next day (remember tests are run on a nightly basis). Do not forget to remove the feature branch for testing once it has been merged. @@ -133,10 +133,14 @@ Agreement](https://www.orfeo-toolbox.org/cla/ccla-en.doc) (CCLA) form if you are contributing on behalf of your company or another entity which retains copyright for your contribution. +The copyright owner (or owner's agent) must be mentioned in headers of all +modified source files and also added to the [NOTICE +file](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/raw/develop/NOTICE). + ## Remote modules [Remote Modules](https://wiki.orfeo-toolbox.org/index.php/Remote_Modules) are -the prefered way if you wish to make your apps and filters available to the +the preferred way if you wish to make your apps and filters available to the community while keeping control and maintenance of their sources. Remote modules are just like regular modules, except they are not distributed inside OTB source code. Under some conditions (dependencies, official acceptance @@ -144,13 +148,13 @@ process, etc.), we are also able to distribute your remote module in the official standalone binaries. See [the wiki](https://wiki.orfeo-toolbox.org/index.php/Remote_Modules) for more information. -## Gitlab guidelines +## GitLab guidelines -In order to organize the issues in our Gitlab instance, we use both labels and +In order to organize the issues in our GitLab instance, we use both labels and milestones. The [milestones](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/milestones) should be used to track in which release a feature is merged. -Gitlab can then provide a summary of all features and bugs added to a given release +GitLab can then provide a summary of all features and bugs added to a given release version. Regarding labels, we use the following set: