diff --git a/contribution-process.md b/contribution-process.md
new file mode 100644
index 0000000000000000000000000000000000000000..1ca73485663413b340e6a81ce3982f6bfacfa82d
--- /dev/null
+++ b/contribution-process.md
@@ -0,0 +1,57 @@
+## Contributions process to specs
+
+### Overview of the process
+
+The steps below describe the process for contribution and integration of Change Requests using GitLab repositories.
+
+#### 1. Contributor reserve a contribution name in the oneM2M portal
+
+The contributor generates a new CR in the oneM2M portal so that a "contribution name" is generated.
+
+#### 2. Contributor creates a new branch for changes
+
+The contributor creates a new branch for the contribution. See [Gitlab's branching documentation for more details](https://docs.gitlab.com/ee/user/project/repository/branches/).
+The branch shall be based on the latest status of the release candidate branch as start point.
+The branch name shall reflect to "contribution name" generated by the oneM2M portal in the previous step.
+
+#### 3. Contributor commits changes to the branch
+
+The contributor makes a set of changes (either modifications or additions) to the newly-created branch.
+
+This activity can be executed in several ways:
+
+*  Via the web interface of Gitlab (either the "Edit" button or the "Web IDE")
+*  Via Git (by using a Git client locally)
+
+A contribution can be composed of a set of commits or just one commit that includes all desired changes.
+
+#### 3. Contributor creates and submits a merge request
+
+The contributor ensures that, once the contribution is ready, the contribution branch is locked (protected) and raises a Merge Request from the branch containing their changes named as the contribution branch.
+
+The submitted Merge Request shall include some description by filling the contribution template.
+
+
+#### 4. Contributor prepares and makes available a contribution on the ETSI Portal.
+
+The contributor uploads the autogenerated CR to the oneM2M portal. This autogenerated CR contains the changes submitted, the contribution details as coverpage and a link to the new Merge Request. 
+
+For example, Merge request XYZ proposes to merge branch "XYZ" into branch Release-X (latest status which should be tagged as X.Y.Z version). 
+ 
+#### 5. The usual contribution approval process of document is held leading to the approval of the contribution on the Portal (and minuted in the meeting report)
+
+The rapporteur applies the Merge Request XYZ. 
+
+In case of conflict, the rapporteur fixes the conflict by rebasing the contribution branch and/or fixing the conflict locally. The contribution needs to go to the normal approval process once again.
+
+#### 6. The usual contribution approval process of document is held leading to revisions required – either due to email discussion , or discussion during a meeting – the Merge Request is renamed to 
+XYZR1 (to reflect that it is being revised), and then the contribution branch is unlocked (unprotected) so that the contributor submits the required revisions. The contributor locks (protects) the contribution branch 
+once the revision is ready. The autogenerated revised CR is submitted to the oneM2M portal. The process continues to step 5.
+
+#### 7. The usual contribution approval process of document is held leading to the rejection of the contribution (and minuted in the meeting report)
+
+The rapporteur closes the Merge Request XYZ. 
+
+#### 8. Rapporteur produces a new baseline
+
+The rapporteur creates a new tag on the branch Release-X to indicate a new baseline named X.Y.Z. A new baseline is autogenerated and the rapporteur uploads it to the portal.