Refactor: Align with docs-as-code 2.0.0

.gitignore

@@ -11,6 +11,7 @@ user.bazelrc
 
 # docs build artifacts
 /_build*
+docs/ubproject.toml
 
 # Vale - editorial style guide
 .vale.ini

MODULE.bazel

@@ -13,7 +13,7 @@
 
 module(
     name = "score_platform",
-    version = "0.4.0",
+    version = "0.4.1",
     compatibility_level = 0,
 )
 
@@ -73,5 +73,5 @@ bazel_dep(name = "rules_java", version = "8.15.1")
 #
 ###############################################################################
 bazel_dep(name = "score_tooling", version = "1.0.2")
-bazel_dep(name = "score_docs_as_code", version = "1.4.0")
-bazel_dep(name = "score_process", version = "1.2.1")
+bazel_dep(name = "score_docs_as_code", version = "2.0.0")
+bazel_dep(name = "score_process", version = "1.3.1")

docs/conf.py

@@ -15,7 +15,6 @@
 
 project = "S-CORE"
 project_url = "https://eclipse-score.github.io/score"
-project_prefix = "S-CORE_"
 version = "0.1"
 
 extensions = [

docs/contribute/contribution_request/feature_request.rst

@@ -25,7 +25,7 @@ This Guideline is based on or references following documents:
 
 * :ref:`Contribution Guideline <contribute_contribution_guideline>`
 * :ref:`Change Management Plan <change_mgmt_plan>`
-* :need:`Feature Template <PROCESS_gd_temp__change_feature_request>`
+* :need:`Feature Template <gd_temp__change_feature_request>`
 
 Creation of Feature Request
 ================================
@@ -82,7 +82,7 @@ First of all, change the status of *Feature Request* to "in Progress" state.
 *Feature Requests*, that stay in the status "Draft" longer as 4 weeks, will be deleted.
 Afterwards create a PR with your proposal in the `/docs/features <https://github.com/eclipse-score/score/tree/main/docs/features>`_ score repository.
 There you will find currently existing features as subfolders. Please choose the one that fits your *feature request* the most or
-create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :need:`Feature Template <PROCESS_gd_temp__change_feature_request>`.
+create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :need:`Feature Template <gd_temp__change_feature_request>`.
 You should try to put as much information as possible, as a good exhaustive description is a prerequisite for *feature request* to be accepted.
 
 It is important to understand, that *feature request* consists of an GitHub Issue, that is used to track organizational information and

docs/contribute/contribution_request/index.rst

@@ -95,9 +95,9 @@ A Pull Request (**PR**) is the **ONLY** way to contribute **CODE** to the *S-COR
 
 The figure below shows a simplified workflow for a PR.
 
-* The contributor (:need:`Contributor <PROCESS_rl__contributor>`) starts by creating a PR:  `Creating a Pull Request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request>`_.
+* The contributor (:need:`Contributor <rl__contributor>`) starts by creating a PR:  `Creating a Pull Request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request>`_.
 * Required reviewers will be automatically assigned based on the contributed content (via CODEOWNERS).
-* If the content fullfils the review and acceptance criteria, a committer (:need:`Committer <PROCESS_rl__committer>`) will approve the *PR* and thus it can be merged.
+* If the content fullfils the review and acceptance criteria, a committer (:need:`Committer <rl__committer>`) will approve the *PR* and thus it can be merged.
 
 .. figure:: _assets/score_contribution_request_simple.drawio.svg
   :width: 600
@@ -108,7 +108,7 @@ The figure below shows a simplified workflow for a PR.
 
 Content in general may contain features, requirements, architectural designs, modules, components, detailed designs, implementations and source code, tests, process descriptions, any documentations, guidelines, tutorials, tools, or infrastructure topics and more of the *S-CORE* project. In case of doubt or for any other input we strongly encourage to open a *GitHub Issue* (:need:`doc__issue_guideline`) first.
 
-The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor <PROCESS_rl__contributor>`) must use for his *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
+The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor <rl__contributor>`) must use for his *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
 
 The content of any *PR* is the commit content and the description as well as the comments given in GitHub and is kept in a versioned repository, their revision history is the historical record of the PR.
 
@@ -132,23 +132,23 @@ The figure below gives an overview about all the possible steps for a *PR* until
 Create a PR
 -----------
 
-The contributor (:need:`Contributor <PROCESS_rl__contributor>`) creates a PR.
+The contributor (:need:`Contributor <rl__contributor>`) creates a PR.
 
-Reviewers will be automatically assigned (:need:`Committer <PROCESS_rl__committer>`) based on the contributed content (ruleset as defined by the committers). In addition several checks for the contributed content (ToDo: Link to the description of the checks) will be started.
+Reviewers will be automatically assigned (:need:`Committer <rl__committer>`) based on the contributed content (ruleset as defined by the committers). In addition several checks for the contributed content (ToDo: Link to the description of the checks) will be started.
 
 Review and merge a PR
 ---------------------
 
-A *PR* is reviewed with all content that adds/modifies it. As long as a *PR* requires further work by the contributor (:need:`Contributor <PROCESS_rl__contributor>`), the *PR* is not approved and thus not merged and further changes are requested. Once the contributor (:need:`Contributor <PROCESS_rl__contributor>`) considers all review comments as resolved, :need:`Contributor <PROCESS_rl__contributor>` can re-request a review. The committer (:need:`Committer <PROCESS_rl__committer>`) reviews the *PR* content according the *S-CORE* review and acceptance criteria (ToDo link here to the criteria).
-Further the contributor (:need:`Contributor <PROCESS_rl__contributor>`) must resolve found issues from the automated checks, if they do not pass.
+A *PR* is reviewed with all content that adds/modifies it. As long as a *PR* requires further work by the contributor (:need:`Contributor <rl__contributor>`), the *PR* is not approved and thus not merged and further changes are requested. Once the contributor (:need:`Contributor <rl__contributor>`) considers all review comments as resolved, :need:`Contributor <rl__contributor>` can re-request a review. The committer (:need:`Committer <rl__committer>`) reviews the *PR* content according the *S-CORE* review and acceptance criteria (ToDo link here to the criteria).
+Further the contributor (:need:`Contributor <rl__contributor>`) must resolve found issues from the automated checks, if they do not pass.
 
-As long as the *PR* does not meet the defined criteria and the checks does not pass, it will not be approved. If it does not follow the required templates, based on the provided content or the templates are not filled out properly, the committer as reviewer (:need:`Committer <PROCESS_rl__committer>`) will place the *PR* to the "Draft" state.
+As long as the *PR* does not meet the defined criteria and the checks does not pass, it will not be approved. If it does not follow the required templates, based on the provided content or the templates are not filled out properly, the committer as reviewer (:need:`Committer <rl__committer>`) will place the *PR* to the "Draft" state.
 
-It is then the responsibility of the contributor (:need:`Contributor <PROCESS_rl__contributor>`) to add the missing information and to re-start the contribution by placing the *PR* back for review.
+It is then the responsibility of the contributor (:need:`Contributor <rl__contributor>`) to add the missing information and to re-start the contribution by placing the *PR* back for review.
 
 To change from "Draft" to "Open" see `Changing the stage of a pull request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request>`_.
 
-At any point the contributor (:need:`Contributor <PROCESS_rl__contributor>`) may decide not to continue with the PR, then the contributor (:need:`Contributor <PROCESS_rl__contributor>`) just closes the PR.
+At any point the contributor (:need:`Contributor <rl__contributor>`) may decide not to continue with the PR, then the contributor (:need:`Contributor <rl__contributor>`) just closes the PR.
 
 .. _what_is_a_github_issue:
 

docs/contribute/development/development_environment.rst

@@ -16,7 +16,7 @@
    :id: doc__develop_environment
    :status: valid
    :safety: ASIL_B
-   :realizes: PROCESS_wp__sw_development_plan
+   :realizes: wp__sw_development_plan
 
 .. _setting_up_dev_env: