Switch links to Eclipse for all migrated repos

CONTRIBUTING.md

@@ -4,23 +4,23 @@ SPDX-FileCopyrightText: Huawei Inc.
 SPDX-License-Identifier: CC-BY-4.0
 -->
 
--   [Gitlab contributions](#gitlab-contributions)
+-   [Gitlab Contributions](#gitlab-contributions)
     -   [Overview](#overview)
     -   [Commit Guidelines](#commit-guidelines)
     -   [Contributions to Documentation](#contributions-to-documentation)
--   [REUSE compliance](#reuse-compliance)
-    -   [SPDX information and REUSE standard](#spdx-information-and-reuse-standard)
-        -   [SPDX header example](#spdx-header-example)
-        -   [Substantial contributions](#substantial-contributions)
+-   [REUSE Compliance](#reuse-compliance)
+    -   [SPDX Information and REUSE Standard](#spdx-information-and-reuse-standard)
+        -   [SPDX Header Example](#spdx-header-example)
+        -   [Substantial Contributions](#substantial-contributions)
 -   [DCO sign-off](#dco-sign-off)
     -   [Overview](#overview-1)
     -   [Developer Certificate of Origin](#docs_dco)
 
-# Gitlab contributions
+# Gitlab Contributions
 
 ## Overview
 
-Oniro Project project handles contributions as [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) to relevant repositories part of the Oniro Project [GitLab instance](https://booting.oniroproject.org/distro/oniro). The flow for handling that is classic: fork-based merge requests. This means that once you have an account, you can fork any repository, create a branch with proposed changes and raise a merge request against the forked repository. More generic information you can find on the Gitlab's documentation as part of ["Merge requests workflow"](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html).
+Oniro Project project handles contributions as [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) to relevant repositories part of the Oniro Project [GitLab instance](https://gitlab.eclipse.org/eclipse/oniro-core). The flow for handling that is classic: fork-based merge requests. This means that once you have an account, you can fork any repository, create a branch with proposed changes and raise a merge request against the forked repository. More generic information you can find on the Gitlab's documentation as part of ["Merge requests workflow"](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html).
 
 ## Commit Guidelines
 
@@ -89,15 +89,15 @@ Signed-off-by: Joe Developer <joe.developer@example.com>
 
 In Oniro Project, the documentation usually stays with the respective code repositories. This means that contributing to documentation is not in any way different than contributing to code. The processes, contribution guidelines are to remain the same. The only difference is that documentation files are to be released under `Creative Commons License version 4.0`.
 
-Documentation that doesn't link directly to one specific repository, is available in the [docs repository](https://booting.oniroproject.org/distro/docs).
+Documentation that doesn't link directly to one specific repository, is available in the [docs repository](https://gitlab.eclipse.org/eclipse/oniro-core/docs).
 
 In terms of file format, the project unifies its documentation as `ReStructuredText` files. A RestructuredText primer is available as part of the Sphinx [documentation](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html).
 
 As a rule of thumb, anything that ends up compiled in the project documentation is to maintain the RestructuredText file format. Text files that are not meant to be compiled as part of the project's documentation can be written in [Markdown](https://daringfireball.net/projects/markdown/). For example, a repository `README` file can be written in Markdown as it doesn't end up compiled in the project-wide documentation.
 
-# REUSE compliance
+# REUSE Compliance
 
-## SPDX information and REUSE standard
+## SPDX Information and REUSE Standard
 
 All projects and files for an hosted project **MUST** be [REUSE](https://reuse.software/) compliant. REUSE requires SPDX information for each file, rules for which are as follows:
 
@@ -113,7 +113,7 @@ Some files will make an exception to the above rules as described below:
 -   Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
 -   license files (for example `common-licenses` in bitbake layers)
 
-### SPDX header example
+### SPDX Header Example
 
 Make sure all of your submitted new files have a licensing statement in the headers. Please make sure that the license for your file is consistent with the licensing choice at project level and that you select the correct SPDX identifier, as in the following example for Apache 2.0 license:
 
@@ -125,7 +125,7 @@ Make sure all of your submitted new files have a licensing statement in the head
  */
 ```
 
-### Substantial contributions
+### Substantial Contributions
 
 Therefore, if your contribution is only a patch directly applied to an existing file, then you are not required to do anything. If your contribution is an entire new project, or a substantial, copyrighted contribution, you **MUST** make sure that you do that following the [IP Policy](https://booting.oniroproject.org/distro/governance/ip-policy) and that you comply with REUSE standard to include the licensing information where they are required.