diff --git a/.env b/.env
new file mode 100644
index 00000000..a98ee355
--- /dev/null
+++ b/.env
@@ -0,0 +1,2 @@
+PYTHONPATH=${workspaceFolder}/_extensions
+
diff --git a/.gitignore b/.gitignore
index ce8efd59..6c272cae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,16 +4,3 @@ MODULE.bazel.lock
# Ruff
.ruff_cache
-
-# docs:incremental and docs:ide_support build artifacts
-/_build
-
-# Python
-.venv
-
-# Vale - editorial style guide
-.vale.ini
-styles/
-
-# direnv - folder-specific bash configuration
-.envrc
diff --git a/.gitlint b/.gitlint
index 34bc3336..53a3c5ce 100644
--- a/.gitlint
+++ b/.gitlint
@@ -32,6 +32,11 @@ regex=^[a-z_-]+: .+$
# First line of the commit message body must be empty. (second line of the commit message)
[body-first-line-empty]
+# Body must contain a reference to an issue
+# 'see' will act as a form of reference from commits to issues without closing them.
+[body-match-regex]
+regex=Issue-ref: (see|close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved) #(\d+)
+
#Ignores the title if it starts with Revert or Merge
[ignore-by-title]
regex=(^Revert |^Merge )
diff --git a/.vscode/settings.json b/.vscode/settings.json
index f93460ff..abba7d2c 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -4,53 +4,29 @@
"files.trimTrailingWhitespace": true,
"editor.insertSpaces": true,
"editor.tabCompletion": "on",
-
- // Default for any filetype
+ "editor.wordWrap": "wordWrapColumn",
+ "editor.wrappingIndent": "same",
+ "editor.wordWrapColumn": 100,
"editor.rulers": [
100
],
- //
- //
-
- // Python Settings
- "[python]": {
- // In python using 80 characters per line is the standard.
- "editor.rulers": [
- 79
- ],
- },
// RST Settings
"[restructuredtext]": {
- "editor.tabSize": 3,
+ "editor.tabSize": 3,
},
- //
- //
- // Esbonio 0.x (Current)
- // see https://github.com/swyddfa/esbonio/blob/0.x/docs/lsp/getting-started.rst
- // and https://github.com/swyddfa/esbonio/blob/0.x/docs/lsp/editors/vscode/_configuration.rst
- "esbonio.server.pythonPath": "${workspaceFolder}/.venv_docs/bin/python",
- "esbonio.sphinx.srcDir": "${workspaceFolder}/docs",
- "esbonio.sphinx.confDir": "${workspaceFolder}/docs",
- "esbonio.sphinx.buildDir": "${workspaceFolder}/_build",
- "esbonio.server.logLevel": "info",
- // Do not auto-install. We'll use the one in the venv.
- "esbonio.server.installBehavior": "nothing",
- // Enable port forwarding for preview if working on remote workstation
- "remote.autoForwardPorts": true,
- "remote.autoForwardPortsSource": "process",
- //
- //
- // Esbonio 1.x (Preview)
- "esbonio.sphinx.pythonCommand": [
- ".venv_docs/bin/python"
- ],
- "esbonio.sphinx.buildCommand": [
- "docs",
- "_build",
- "--jobs",
- "auto"
+
+ // Python emnvironment
+ "python.envFile": "${workspaceFolder}/.env",
+
+ // Restructured Text
+ "restructuredtext.linter.doc8.extraArgs": [
+ "--config",
+ "${workspaceFolder}/docs/doc8.ini"
],
- // default is "error", which doesn't show anything.
- "esbonio.logging.level": "warning"
+
+ // Sphinx-Needs
+ "ubcode.srcDir": "${workspaceFolder}/docs",
+ "ubcode.needsJson": "${workspaceFolder}/docs/needs.json",
+
}
diff --git a/MODULE.bazel b/MODULE.bazel
index f2ecaac0..0a05c11a 100644
--- a/MODULE.bazel
+++ b/MODULE.bazel
@@ -46,10 +46,6 @@ pip.parse(
)
use_repo(pip, "pip_sphinx")
-# Additional Python rules provided by aspect, e.g. an improved version of
-# `py_binary`. But more importantly, it provides `py_venv`.
-bazel_dep(name = "aspect_rules_py", version = "1.0.0")
-
###############################################################################
#
# Packaging dependencies
diff --git a/README.md b/README.md
index 42ef3425..d8a32989 100644
--- a/README.md
+++ b/README.md
@@ -16,60 +16,14 @@ $ bazel run //:format.fix
## Documentation
-Score supports multiple methods for generating documentation, tailored to different workflows:
-1. **Bazel-based builds** for clean, sandboxed outputs.
-2. **Incremental builds** for quick iterations during development.
-3. **IDE integration** for live previews, live warnings and even faster iterations.
-
-### Bazel-based Build
-
-This method ensures clean and isolated documentation builds in a controlled Bazel environment.
-It is best suited for CI pipelines or production-ready outputs, although it takes longer compared to
-incremental builds.
-
-```sh
-bazel build //docs:docs
+Use //docs:docs target to build the documentation.
```
-The output will be located in bazel-bin/docs/docs/_build/html.
-
-
-### Incremental build
-
-For local changes and faster feedback, use the incremental build.
-This method generates the documentation directly in the _build directory.
-
-```sh
-bazel run //docs:incremental
+$ bazel build //docs:docs
```
-Unlike IDE integration, which renders only the current file, this approach is ideal for quickly
-verifying edits across the entire documentation during development.
-
-### IDE integration
+The output directory can be found under ```bazel-bin/docs/docs/_build/html```.
-For live previews, warnings, and linting during development,
-integrate Esbonio with your IDE (e.g., VS Code):
-
-```sh
-bazel run //docs:ide_support
+If you need to update pip dependencies, after modifying the requirements file, regenerate the lock file:
+```
+bazel run //docs:requirements.update
```
-
-VS Code: Install the Esbonio extension in VS Code. After installation, restart your IDE.
-You should now have live preview available when you open a `.rst` file.
-Note: if the extension was already installed when you ran the `ide_support` command,
-you will need to restart your IDE.
-
-For features like type detection in conf.py or extensions,
-point your IDE to the .venv_docs virtual environment.
-
-Re-run //docs:ide_support if you update Sphinx extensions or other dependencies.
-
-### Notes
-#### Output Locations
-* Bazel builds output to bazel-bin/docs/docs/_build/html.
-* Incremental builds output to _build.
-
-#### Troubleshooting
-* Restart your IDE if live previews or warnings are not working after running ide_support.
-* Ensure your virtual environment is up-to-date by re-running //docs:ide_support when dependencies
- change.
diff --git a/docs/BUILD b/docs/BUILD
index 4b784a86..426c0756 100644
--- a/docs/BUILD
+++ b/docs/BUILD
@@ -11,33 +11,6 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-# Multiple approaches are available to build the same documentation output:
-#
-# 1. **Esbonio via IDE support (`ide_support` target)**:
-# - Listed first as it offers the least flexibility in implementation.
-# - Designed for live previews and quick iterations when editing documentation.
-# - Integrates with IDEs like VS Code but requires the Esbonio extension.
-# - Requires a virtual environment with consistent dependencies (see 2).
-#
-# 2. **Directly running Sphinx in the virtual environment**:
-# - As mentioned above, a virtual environment is required for running esbonio.
-# - Therefore, the same environment can be used to run Sphinx directly.
-# - Option 1: Run Sphinx manually via `.venv_docs/bin/python -m sphinx docs _build --jobs auto`.
-# - Option 2: Use the `incremental` target, which simplifies this process.
-# - Usable in CI pipelines to validate the virtual environment used by Esbonio.
-# - Ideal for quickly generating documentation during development.
-#
-# 3. **Bazel-based build (`docs` target)**:
-# - Runs the documentation build in a Bazel sandbox, ensuring clean, isolated builds.
-# - Less convenient for frequent local edits but ensures build reproducibility.
-#
-# **Consistency**:
-# When modifying Sphinx extensions or configuration, ensure all three methods
-# (Esbonio, incremental, and Bazel) work as expected to avoid discrepancies.
-#
-# For user-facing documentation, refer to `/README.md`.
-
-load("@aspect_rules_py//py:defs.bzl", "py_venv")
load("@pip_sphinx//:requirements.bzl", "all_requirements", "requirement")
load("@rules_pkg//pkg:mappings.bzl", "pkg_files")
load("@rules_pkg//pkg:tar.bzl", "pkg_tar")
@@ -45,10 +18,6 @@ load("@rules_python//python:defs.bzl", "py_library")
load("@rules_python//python:pip.bzl", "compile_pip_requirements")
load("@rules_python//sphinxdocs:sphinx.bzl", "sphinx_build_binary", "sphinx_docs")
-# all_requirements include esbonio which we don't need most of the time.
-# Hint: the names are e.g. "@@rules_python~~pip~pip_sphinx//esbonio:pkg"
-sphinx_requirements = [name for name in all_requirements if not "esbonio" in name] + [":extensions"]
-
sphinx_docs(
name = "docs",
srcs = glob([
@@ -74,7 +43,7 @@ sphinx_docs(
sphinx_build_binary(
name = "sphinx_build",
- deps = sphinx_requirements,
+ deps = [":extensions"] + all_requirements,
)
py_library(
@@ -86,11 +55,6 @@ py_library(
imports = ["."],
)
-# In order to update the requirements, change the `requirements.txt` file and run:
-# `bazel run //docs:requirements`.
-# This will update the `requirements_lock.txt` file.
-# To upgrade all dependencies to their latest versions, run:
-# `bazel run //docs:requirements -- --upgrade`.
compile_pip_requirements(
name = "requirements",
src = "requirements.txt",
@@ -116,19 +80,3 @@ pkg_tar(
name = "github-pages",
srcs = [":html_files"],
)
-
-# Run-time build of documentation, incl. incremental build support.
-py_binary(
- name = "incremental",
- srcs = ["incremental.py"],
- deps = sphinx_requirements,
-)
-
-# Virtual python environment for working on the documentation (esbonio).
-# incl. python support when working on conf.py and sphinx extensions.
-py_venv(
- name = "ide_support",
- venv_name = ".venv_docs",
- # Until release of esbonio 1.x, we need to install it ourselves so the VS Code extension can find it.
- deps = sphinx_requirements + [requirement("esbonio")],
-)
diff --git a/docs/_assets/css/score.css b/docs/_assets/css/score.css
index 8c1d130e..031bffd2 100644
--- a/docs/_assets/css/score.css
+++ b/docs/_assets/css/score.css
@@ -170,7 +170,6 @@ div.score_banner {
#videowrapper{
position: relative;
overflow: hidden;
- margin-bottom: 50px;
}
#fullScreenDiv{
@@ -210,7 +209,7 @@ div.score_banner {
/* font-size: 4.5em; */
font-size: 8.0cqw;
font-weight: 900;
- margin-bottom: 20px;
+
/* Is somehow cool with image/video title background */
/*animation: fadeIn 3s; */
}
diff --git a/docs/_assets/css/score_design.css b/docs/_assets/css/score_design.css
deleted file mode 100644
index 268ca781..00000000
--- a/docs/_assets/css/score_design.css
+++ /dev/null
@@ -1,20 +0,0 @@
-/* ########################### */
-/* SPHINX-DESIGN configs only! */
-/* ########################### */
-
-.score-grid .sd-card-header {
- background-color: var(--pst-color-secondary) !important;
- color: var(--pst-color-text-muted);
- font-weight: 900;
- font-size: 1.2em;
-
-}
-.score-grid .sd-card-body {
- text-align: justify;
-}
-
-details.sd-dropdown summary.sd-card-header + div.sd-summary-content
-{
- background-color: transparent;
-
-}
diff --git a/docs/_assets/css/score_needs.css b/docs/_assets/css/score_needs.css
index ebc69be5..8ab71c08 100644
--- a/docs/_assets/css/score_needs.css
+++ b/docs/_assets/css/score_needs.css
@@ -70,8 +70,3 @@ html[data-theme="dark"] {
background-color: var(--pst-color-table-row-zebra-high-bg);
}
-html[data-theme="dark"] {
- --sn-color-need-bg-head: #20242b;
- --sn-color-datatable-label: var(--pst-color-text-base)
-}
-
diff --git a/docs/_extensions/metamodel.py b/docs/_extensions/metamodel.py
index b979936a..c8d29887 100644
--- a/docs/_extensions/metamodel.py
+++ b/docs/_extensions/metamodel.py
@@ -29,91 +29,6 @@
color="#BFD8D2",
style="node",
),
- # Process
- dict(
- directive="req", # = std_req
- title="Requirement",
- prefix="R_",
- color="#BFD8D2",
- style="node",
- ),
- dict(
- directive="role", # = Einzelne Leute der Codeowner Gruppe
- title="Role",
- prefix="RL_",
- color="#DCB239",
- style="actor",
- ),
- dict(
- directive="team", # = Codeowners
- title="Team",
- prefix="TE_",
- color="#DCB239",
- style="node",
- ),
- dict(
- directive="workproduct", # = work_product
- title="Workproduct", # = Work Product
- prefix="WP__",
- color="#DDDD00",
- style="artifact",
- ),
- dict(
- directive="workflow",
- title="Workflow",
- prefix="WF__",
- color="#FFFF00",
- style="process",
- ),
- dict(
- directive="process",
- title="Process",
- prefix="PR__",
- color="#DCB239",
- style="frame",
- ),
- dict(
- directive="guidance",
- title="Guidance",
- prefix="GD__",
- color="#DCB239",
- style="file",
- ),
- dict(
- directive="gd_req",
- title="Process Requirement",
- prefix="GD_REQ__",
- color="#DCB239",
- style="file",
- ),
- dict(
- directive="gd_temp",
- title="Process Template",
- prefix="GD_TEMP__",
- color="#DCB239",
- style="file",
- ),
- dict(
- directive="gd_chklst",
- title="Process Checklist",
- prefix="GD_CHKLST__",
- color="#DCB239",
- style="file",
- ),
- dict(
- directive="gd_guidl",
- title="Process Guideline",
- prefix="GD_GUIDL__",
- color="#DCB239",
- style="file",
- ),
- dict(
- directive="document",
- title="Document",
- prefix="DOC__",
- color="#DCB239",
- style="file",
- ),
]
# Define extra options for needs object
@@ -139,65 +54,5 @@
"style_start": "-up",
"style_end": "->",
},
- {
- "option": "implements",
- "incoming": "implements by",
- "outgoing": "implements",
- },
- # process links
- { # team -> role
- "option": "contains",
- "incoming": "is part of",
- "outgoing": "consists of",
- },
- { # workflow -> role
- "option": "responsible",
- "incoming": "is reponsible for",
- "outgoing": "responsible",
- },
- { # workflow -> role
- "option": "approver",
- "incoming": "is approver for",
- "outgoing": "approving",
- },
- { # workflow -> role
- "option": "supporter",
- "incoming": "is supporter for",
- "outgoing": "supporting",
- },
- { # process -> role
- "option": "owner",
- "incoming": "is process owner for",
- "outgoing": "process owner",
- },
- { # process -> workflow
- "option": "includes",
- "incoming": "is included in",
- "outgoing": "includes workflow",
- },
- { # workflow -> workproduct
- "option": "output",
- "incoming": "is output from",
- "outgoing": "has output",
- },
- { # workflow -> workproduct
- "option": "input",
- "incoming": "is input from",
- "outgoing": "has input",
- },
- { # workflow -> guidance
- "option": "guidance",
- "incoming": "is guiding",
- "outgoing": "has guidance",
- },
- { # workproduct -> req
- "option": "compliance-wp",
- "incoming": "complies to",
- "outgoing": "is complying with",
- },
- { # guidance -> req
- "option": "compliance-gd",
- "incoming": "complies to",
- "outgoing": "is complying with",
- },
+ {"option": "implements", "incoming": "implements by", "outgoing": "implements"},
]
diff --git a/docs/conf.py b/docs/conf.py
index aa7d3ca2..6f9a7cbd 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -17,7 +17,83 @@
# https://www.sphinx-doc.org/en/master/usage/configuration.html
# from process.process_model_configuration import *
-from _extensions import metamodel, layouts
+# from _extensions import metamodel, layouts
+
+class metamodel:
+ needs_types = [
+ # Requirements
+ dict(
+ directive="stkh_req",
+ title="Stakeholder requirements",
+ prefix="STKH_REQ__",
+ color="#BFD8D2",
+ style="node",
+ ),
+ dict(
+ directive="tool_req",
+ title="Tool Requirements",
+ prefix="TOOL_REQ__",
+ color="#BFD8D2",
+ style="node",
+ ),
+ ]
+
+ # Define extra options for needs object
+ needs_extra_options = [
+ "security",
+ "safety",
+ "level",
+ "rationale",
+ "mitigated_by",
+ "reqtype",
+ "codelink",
+ "testlink",
+ "reqcovered",
+ "testcovered",
+ ]
+
+ needs_extra_links = [
+ # TODO: Refer process document for the usage of links
+ {
+ "option": "satisfies",
+ "incoming": "is satisfied by",
+ "outgoing": "satisfies",
+ "style_start": "-up",
+ "style_end": "->",
+ },
+ {"option": "implements", "incoming": "implements by", "outgoing": "implements"},
+ ]
+
+class layouts:
+ needs_layouts = {
+ "score": {
+ "grid": "complex",
+ "layout": {
+ "head_left": [
+ '<>',
+ ],
+ "head": [
+ 'status: **<>**',
+ 'security: **<>**',
+ 'safety: **<>**',
+ ],
+ "head_right": [
+ '<> '
+ ],
+ "meta_left": [
+ '<>',
+ "<>",
+ ],
+ "meta_right": [],
+ "footer_left": ["<>"],
+ "footer": ['<>'],
+ "footer_right": [],
+ },
+ },
+ }
+
+ needs_global_options = {"layout": "score"}
+
# -- Project information -----------------------------------------------------
@@ -31,12 +107,13 @@
# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
extensions = [
- "sphinx_design",
"sphinx_needs",
]
templates_path = ["_templates"]
+suppress_warnings = ["config.cache"]
+
# Enable numref
numfig = True
@@ -48,12 +125,18 @@
html_css_files = [
"css/score.css",
"css/score_needs.css",
- "css/score_design.css",
]
html_theme_options = {
"navbar_align": "content",
- "header_links_before_dropdown": 5,
+ "header_links_before_dropdown": 3,
+ "external_links": [
+ {"name": "SCORE", "url": "https://eclipse-score.github.io"},
+ {
+ "name": "Eclipse",
+ "url": "https://projects.eclipse.org/projects/automotive.score",
+ },
+ ],
"icon_links": [
{
"name": "GitHub",
diff --git a/docs/doc8.ini b/docs/doc8.ini
new file mode 100644
index 00000000..8fb0e5c0
--- /dev/null
+++ b/docs/doc8.ini
@@ -0,0 +1,2 @@
+[doc8]
+ignore-path-errors=D004
\ No newline at end of file
diff --git a/docs/features/communication/ipc/index.rst b/docs/features/communication/ipc/index.rst
index ce7b68d1..86b1dd85 100644
--- a/docs/features/communication/ipc/index.rst
+++ b/docs/features/communication/ipc/index.rst
@@ -11,6 +11,539 @@
#
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
+ #
+ # Authors
+ # @hartmannnico,
+
+
+Communication Framework
+#######################
+
+* Purpose - why and what do we need this for
+* Scope and context diagram
+* QoS requirements
+* Error handling
+* ASIL requirements (hashing, integrity, ...)
+* Interoperability
+
+The Communication Framework handles the safe, secure and performant exchange of information between software and/or hardware components of the S-CORE stack.
+
+Communication covers information exchange between endpoints residing in
+
+* the same or different process, running on
+* the same or different operating systems, deployed on
+* the same or different compute devices, built into
+* the same or different devices.
+
+In current communication designs (SOME/IP, Protobuf, zenoh) communication on networks is at the centerpoint of considerations. We believe this to be the wrong approach for software defined machines. Network based communication circles around protocols based on a wire based communication paradigm, requiring serialization and segmentation of data.
+
+Instead, we promote a memory centered core paradigm and put Inter-Process Communication (IPC) into our conceptional focus. This allows for true zero copy design, does not segment or serialize data and fosters significantly higher performance in algorithms. As a bonus, it provides easy gateway mechanisms into serial communication like Ethernet and CAN.
+
+The communication framework is independent of the domain of the application it is used in.
+
+General Architecture
+--------------------
+
+The communication framework defines two central groups of elements:
+
+* Information Elements
+* Infrastructure Elements
+
+While the former carry the information exchanged, the latter provide the means through which the information is exchanged.
+
+Information Elements
+````````````````````
+
+There are three fundamental concepts of information exchange defined. One communication element represents each concept:
+
+* **Topics**: A topic is the information carrier for **data**. A unique Id identifies a topic while a *data type* defines it's memory layout. The topic carries zero or multiple *values*. A value represents a single instances of the data type. See `Topics`_, `Names`_, `Data Types`_.
+* **Remote Procedures**: A remote procedure is the information carrier for **execution** progress. A Id handle identifies the remote procedure together with an ordered set of named *parameters*. Each parameter defined by a data type. A caller of a remote procedure can cause it's activation by invoking the remote procedure with passed *arguments*. An argument is a single value instance for a parameter. See `Remote Procedures`_, `Names`_, `Data Types`_.
+* **Events**: An event is the information carrier for runtime **synchronization**. A unique Id identifies the event. It signals the change of state. There is no data conveyed with the event. See `Events`_, `Names`_.
+
+While the Id uniquely identifies an information element within the communication framework, it can also have a *name* as alias to conveniently identify the element. While the Id may not be publicly known, the *name* allows for public lookup.
+
+
+Infrastructure Elements
+```````````````````````
+
+Infrastructure elements provide the means through which the information exchange executes.
+We define three fundamental building elements:
+
+* **Endpoints**: Endpoints are both the source and the target of every information exchange in teh communication framework. An endpoint providing information is consequently called a *provider*. With the same logic a *consumer* is an endpoint consuming information. Endpoints have an *Id* that uniquely identifies the endpoint within a node.
+* **Nodes**: A node is an entity in the communication system that hosts several endpoints. It is the central element of the communication fabric by connecting endpoints and routing data. Nodes have an *Id* that uniquely identifies the node within a fabric. A node itself is also an endpoint.
+* **Links**: A link is the fundamental abstraction of a connection between any two nodes. A link conveys information between nodes.
+
+The combination of NodeId and EndpointId we also refer to as *address*. As nodes are also endpoints, they implicitly have an address.
+
+Nodes and endpoints may also be identified by a *name* that resolves into references to these elements. See `Names`_, `References`_.
+
+Connecting nodes though links creates a mesh of nodes that can mutually exchange information utilizing the above concepts. The boundary of the mesh is at the sole discretion of the deployment and may span from a single application into a connected cloud environment.
+
+The entirety of connected nodes within a mesh we call *fabric*.
+
+.. admonition:: Design Note
+
+ From a perspective of safety, a node also encapsulates a single safety domain. Links provide the means for separating safety domains and thus allow for mixed criticality applications.
+
+^^^^ End of Big Picture ^^^^
+
+Names
+-----
+
+A name is an UTF-8 tag of an element. The underlying Unicode standard is `release 16.0.0 `_.
+
+All codepoints are valid in a name with the exception of the following codepoints:
+
+* the *control* codepoints ```` to ``F``
+* the *dot* separator, codepoint ``FULL STOP``: ``.`` ``E``
+* the *path separator*, codepoint ``SOLIDUS``: ``/`` ``F``
+* the *wildcard* marker, codepoint ``ASTERISK``: ``*`` ``A``
+* the *any* marker, codepoint ``QUESTION MARK``: ``?`` ``F``
+
+Forbidden as first character in a name is
+
+* the *reference* marker codepoint ``AMPERSAND``: ``&`` ````. It's use is discouraged in names in general.
+
+Further discouraged is the use of the *whitespace* codepoint ``SPACE``: `` `` ````.
+
+Element names prefixed with an underS-CORE ``LOW LINE``: ``_`` ``F`` are regarded to have *private* visibility within the scope they are defined in. While references to private elements are possible, name resolution ony works from within the namespace they are defined in.
+
+.. admonition:: Design Note
+
+A name is not a property of an element itself.
+Instead, a name acts as an *alias* to obtain an element *reference*.
+See _`References`.
+
+
+Namespaces
+----------
+
+A namespace is a named scope in which the definition of the elements topic, remote procedures, event and recursively namespace is valid.
+
+General rules of names apply to namespace names.
+
+Namespaces can be nested.
+The path separator between the names is the unicode codepoint ``SOLIDUS``: ``/`` ``F``.
+
+::
+
+ This/is/a/nested/namespace
+
+
+The namespace name ``/`` is reserved and refers to the global namespace.
+*Global* here means visible with respect to a certain realm that is not further defined. A realm can be a vehicle with it's attached cloud environment or just an application context. It is up to deployment to define the scope of the global namespace.
+
+The namespace name ``super`` is reserved and refers to the parent namespace of the namespace where ``super`` is used. The use of ``super`` in the global namespace is an error.
+
+The namespace name ``package`` is reserved for future use. It must appear as first name in a path.
+
+
+Scoping Rules
+`````````````
+
+Namespaces isolate a naming scope from another. Within a namespace element names must be unique.
+
+Elements in one namespace are by default not visible to elements in other namespaces.
+
+::
+
+ namespace A
+ topic T: Int8 // This is T in A
+
+ namespace B
+ topic T: Float64 // This is T in B
+
+The topics ``A/T`` and ``B/T`` are different.
+
+Namespaces can be nested, i.e. within a namespace another namespace can exist.
+
+::
+
+ namespace A
+ topic T: Int8 // This resides in namespace A
+
+ namespace Aa
+ topic T: Int8 // This T resides in namespace A/Aa
+
+
+A namespace can *use* elements of another namespace thus making it visible under a given or implied local name.
+
+::
+
+ namespace A
+ topic Important: Int8
+
+ namespace Aa
+ topic Nested: Int8
+
+ namespace B
+ use A/Important // makes topic "Important" visible in B
+ use A/Aa // makes namespace "Aa" visible in B
+
+ algorithm
+ access Important
+ access Aa/Nested
+
+A ``use`` clause may end with the wildcard ``ASTERISK``: ``*`` ``A``. This indicates the mapping of all elements of the given namespace into the current scope.
+
+::
+
+ namespace A
+ topic One: Int8
+ topic Two: Int8
+
+ namespace B
+ use A/* // makes One and Two visible in B
+
+ algorithm
+ access One // valid, One is visible in B
+ access Two // valid, Two is visible in B
+
+
+Within a namespace, elements from another namespace are visible without an explicit use when a resolving path is given.
+
+::
+
+ namespace A
+ topic Important: Int8
+
+ namespace B
+ algorithm
+ access A/Important
+
+
+Handles
+-------
+
+A handle is a numeric value that uniquely refers to an individual element in the communication system.
+
+The numeric value can safely be transported through the communication system and shall be resolvable into a reference of the original element.
+
+Data Types
+----------
+
+Data types describe the inner structure of data entities known as values.
+A specific data type will always have the identical memory layout, independent from compiler, operating system and controller architecture.
+
+
+Primitive Types
+```````````````
+
+Primitive data types consist of a single element with no further inherent structure.
+The following primitive data types and their Rust and C++ representation are defined:
+
+========= ========== ========= ========================== ====== ============================
+Data Type Class Rust C++ Size Description
+========= ========== ========= ========================== ====== ============================
+Bool Boolean ``bool`` ``bool`` 1 A boolean value, true or false
+Int8 Integer ``i8`` ``int8_t`` 1 An 8 bit signed integer
+UInt8 Integer ``u8`` ``uint8_t`` 1 An 8 bit unsigned integer
+UInt128 Integer ``u128`` ``uint128_t`` 16 An 128 bit unsigned integer
+Float16 Floating ``f16`` ``float16_t`` 2 An IEEE 756 32 bit floating point
+Float32 Floating ``f32`` ``float``, ``float32_t`` 4 An IEEE 756 32 bit floating point
+Float64 Floating ``f64`` ``double``, ``float64_t`` 8 An IEEE 756 64 bit floating point
+BFloat16 Floating ``bf16`` ``bfloat16_t`` 2 A Google brain float 16 floating point
+TFloat32 Floating ``tf32`` ``tfloat32_t`` 4 An NVIDIA tensor float 32 floating point
+Char String ``char`` ``char32_t`` 4 A unicode codepoint (32 bit)
+String String ``str`` - n/a A UTF-8 encoded text
+Handle Reference - - 8 A 64 bit unsigned integer handle
+========= ========== ========= ========================== ====== ============================
+
+The type ``Byte`` may be used as alias for ``UInt8``.
+The type ``Handle`` may be used as alias for ``UInt64``.
+
+Tuples
+``````
+
+Tuples are ordered collections of arbitrary data types. A tuple shall be expressed by parentheses:
+``(Int8, Float32)``.
+
+The empty Tuple `()` is called the *unit* type, identifying the type with no data. The unit type can carry the one and only one value `()`.
+
+There is no explicit Data Type for neither `Empty`, `Void` or `None`.
+
+
+Structs
+```````
+
+A struct is an ordered collection of named arbitrary data types called fields:
+
+::
+
+ struct MyStruct {
+ field1: Int8,
+ field2: Float32
+ }
+
+Arrays
+``````
+
+Arrays are ordered collections of data elements of the same type with a fixed length. A single element is addressed by an *index*:
+
+::
+
+ Char[32]
+
+
+Tensors
+```````
+
+A Tensor is a multi-dimensional array of numerical values that generalizes scalars, vectors, and matrices to higher dimensions, commonly used in mathematics, physics, and machine learning.
+
+The number of dimensions is called the *rank* or *order* of the Tensor.
+The vector of dimensions with the Tensor's rank is called the *shape* of the Tensor.
+
+::
+
+ Tensor
+
+The 5x5 kernel of a CNN layer with 128 features.
+
+List
+````
+
+A List is an ordered collection of data elements of the same type with a variable length. A single element is addressed by an *index*:
+
+::
+
+ List
+
+HashMap
+```````
+
+A HashMap is an unordered collection of data element of the same type with variable length. A single element is addressed by a *key* of a specific data type.
+
+::
+
+ HashMap
+
+
+Pointers
+````````
+
+There are no data types defined for pointers to data types.
+
+References
+``````````
+
+The communication framework allows for three potential classes of references:
+
+* References to data types
+ There are no data types defined for references to data types.
+
+* References to information elements
+
+ * Topic References, data type ``TopicRef``
+ * Remote Procedure References, data type ``FnRef``
+ * Event References, data type ``EventRef``
+
+* References to infrastructure elements
+ Currently we do not define references to infrastructure elements.
+ However, for conceptual symmetry reasons and application value they
+ might come up in future versions.
+
+The `AMPERSAND`: `&` `` as first character in a path is defined as the marker for references to information elements.
+
+In names and paths the reference marker to an information element of a path.
+
+::
+
+ &/Body/Doors/Windows/LeftFront/Position
+
+References the topic of the top left windows's position.
+
+A Reference shall have a corresponding unique handle. The communication framework shall be able to dispatch handles of references like any other value of a data type. The underlying value type for handles should be ``UInt64`` and must have lockfree atomic read and write operations available.
+
+The application should not have access to handles directly, but only to the references themselves. We call the conversion of a handle into a reference “resolution of the handle”.
+
+The operations granted through a reference to an information item shall be identical to the operations of the information item itself.
+
+
+.. admonition:: Implementation Note
+
+ Internally, the communication framework may actually only pass TopicRef's to the application. From a semantic view it makes no difference to hold a TopicRef or a Topic directly.
+
+.. admonition:: Implementation Note
+
+A ``TopicRef`` is *not* the same as ``&Topic`` as it may require additional validity checks.
+
+
+Topics
+------
+
+A topic is an information carrier for data elements. Data elements have a data type and zero to multiple values, following the format and layout defined by the type.
+
+Publisher & Subscriber
+``````````````````````
+
+A topic follows the publisher/subscriber pattern. This means
+
+- A topic exists on it's own. The framework's data communication system owns the topic.
+- A topic can have zero or one publishers. The publisher updates ('publishes') new data into the topic.
+- A topic can have zero or multiple subscribers. A subscriber consumes the data published into the topic.
+
+Queue
+`````
+
+A topic stores it's values in a queue with a given depth. The queue has a policy that defines the behavior of new data published. There are four policies when the queue is full:
+
+- Ignore: New data is ignored.
+- Overwrite oldest: New data overwrites the oldest element. This makes the topic a ring buffer.
+- Replace latest: New data replaces the latest element, ensuring that the most recent update is always available. A typical use case is when you need to have the newest value at all times while still keeping track of the oldest value that has not been processed.
+- Error: Writing new data to the topic raises an error at the subscriber (and potentially in the topic)
+
+Namespace and Name
+``````````````````
+
+A topic can have a name that exists within a namespace. The name is not an attribute of the topic itself. Instead, it is an alias to the topic's reference that allows access to the data of the topic.
+
+Lifetime
+````````
+
+Once created, the topic belongs to the communication framework which determines it's lifetime.
+
+A topic must live while it is in use, i.e. it has a publisher and/or subscribers.
+
+
+Remote Procedures
+-----------------
+
+A remote procedure is an invokable information element that receives a set of values ('arguments') following a given signature ('parameters') individual to each invocation.
+
+The invocation happens asyncronously. I.e. the invocation of a remote procedure returns immediately to the invoker.
+
+Synchronous behavior is achievable by two intertwined remote procedures. See Result.
+
+**Discussion**: An alternative to intertwined RPCs is the use of a Future mechanism. The advantage of the RPC reference based approach is the symmetry in invocation and result transmission. One implementation achieves both.
+
+Result
+``````
+
+A remote procedure may produce a result that is returned to the caller. The result also has a data type and consists of a single value.
+
+.. note::
+
+ Instead of passing back the result from the procedure the caller may pass a result-return reference that is a remote procedure itself. This way the framework may have a straight-forward way of implementing a Future mechanism that completes upon reception of the response call.
+
+Name & Namespace
+````````````````
+
+A remote procedure may have a name that exists in a namespace. The name is not a property of the remote procedure, but acts as an alias to a unique RPC reference associated with the remote procedure.
+
+Publishing & Discovery
+``````````````````````
+
+Attaching a name to a remote procedure means to publish the remote procedure.
+The communication framework owns both the name and the namespace.
+
+Thus, publishing a remote procedure under a name also provides the means to discover it.
+
+Interfaces & Services
+`````````````````````
+
+There is no specific structure defined as an 'Interface' or 'Service'. Instead, an interface as collection of remote procedures can be seen as a collection of remote procedures within a specific namespace that represents the interface.
+
+Lifetime
+````````
+
+Once created, the remote procedure belongs to the communication framework which determines it's lifetime.
+
+It must exist as long as references to it exist.
+
+Events
+------
+
+An event is an information element that communicates the change of a state. An event has no value.
+The main purpose of an event is to support runtime orchestration.
+
+.. note:: An Event is not the same as a topic with no data. Topic mechanisms are designed to convey values. Events convey occurrences of state changes.
+
+Publisher & Subscriber
+``````````````````````
+
+An event follows the publisher/subscriber pattern. This means
+
+- An event exists on it's own. The framework's data communication system owns the event.
+- An event can have zero or one publishers. The publisher updates ('publishes') new occurrences of associated state changes into the event. This is called 'triggering the event'.
+- An event can have zero or multiple subscribers, also called 'listeners'. A subscriber consumes the state change notifications.
+
+Immediate Events & Queued Events
+````````````````````````````````
+
+An event is designed to convey an immediate notification of the associated state change. However for cases where a subscriber cannot react immediately an event occurrence may be latched in a queue for deferred processing. This is called an 'Event Queue'. The framework may opt to offer event queues on top of immediate event propagation.
+
+Namespace and Name
+``````````````````
+
+An event can have a name that exists within a namespace. The name is not an attribute of the event itself. Instead, it is an alias to the event's reference that allows triggering and listening to the event.
+
+Lifetime
+````````
+
+Once created, the event belongs to the communication framework which determines it's lifetime.
+
+An event must live while it is in use, i.e. it has a publisher and/or subscribers.
+
+
+Zero Copy
+---------
+
+Zero-Copy data exchange is defined as concurrent access to data by a sender and a receiver without alternation of the memory location or layout of the data in the process of the exchange.
+
+This includes:
+
+- No serialization of data
+- No deserialization of data
+- No moving of data in memory
+
+Data Properties
+```````````````
+
+To meet zero-copy requirements data require to be:
+
+- Coherent - All data belonging to a data item must occupy adjacent memory locations.
+- Relocatable - The correct interpretation of a data item is independent from it's address in memory.
+- Atomic - Access to the data item is an atomic operation. To achieve this the data requires one of two access modes:
+
+ - Lockfree Access - No thread lock is required to read or write the data. This is the preferred property of zero-copy data.
+ - Mutually Exclusive Access - A thread lock (mutex) is required to access the data.
+
+Buffers
+```````
+
+In general zero-copy requires that data locations and layout are owned by the communication framework. Obviously these locations must be placed in shared memory to allow access from both producer and consumer side, should these lie in different processes or operating systems or even compute devices.
+
+A data storage memory location is called a 'buffer'. The communication framework executes buffer allocation and deallocation. It shall provide references to these buffers that can be shared between the communication partners.
+
+From a data producer side as well as from a data consumer side this means that the data is accessed directly through a buffer reference to the data.
+
+DMA
+```
+
+As large amount of data are often produced or consumed by hardware the communication framework shall be able to provide raw access to buffers for direct memory access (DMA) capabilities of the underlying platforms.
+
+Safety
+------
+
+We base this document on the ISO 26262-1:2018 released in December 2018.
+
+Exchange of information through information elements always involves an information producer and one or many information consumers. As these can be part of different functions or partitions in the context of the application purpose. As such these partitions are likely to differ in their safety requirements and are thus domains of different safety levels.
+
+The communication framework shall support safety integrity level ASIL-B. The communication framework shall also provide means for information exchange in mixed-criticallity applications where sender and receiver reside in domains of different safety classification.
+
+
+Security
+--------
+
+We base this document on the ISO/SAE 21434 released in August 2021.
+
+Communication and data exchange at the boundaries within the communication framework is subject of security considerations.
+
+The communication framework shall support the following principal security capabilities:
+
+- Authenticaion: Unambigous identification of the communication elements, especially producers and consumers of data.
+- Authorization: A set of rules granting or denying access to communication operations based on the Authentication of participants in the communication framework.
+- Protection: Means to protect the integrity of data received by consumers.
+- Encryption: Means to protect the content of data in transit.
-Inter-process Communication
-###########################
+The definition of requirements for appropriate cryptographic hashing and encryption algorithms is not part of this document.
diff --git a/docs/features/frameworks/fixed-execution-order/index.rst b/docs/features/frameworks/fixed-order-execution/index.rst
similarity index 95%
rename from docs/features/frameworks/fixed-execution-order/index.rst
rename to docs/features/frameworks/fixed-order-execution/index.rst
index 78749f0a..2727669b 100644
--- a/docs/features/frameworks/fixed-execution-order/index.rst
+++ b/docs/features/frameworks/fixed-order-execution/index.rst
@@ -12,5 +12,5 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-Fixed execution order framework
+Fixed order execution Framework
###############################
diff --git a/docs/features/frameworks/index.rst b/docs/features/frameworks/index.rst
index c6d8efe1..7a8bd6c5 100644
--- a/docs/features/frameworks/index.rst
+++ b/docs/features/frameworks/index.rst
@@ -18,4 +18,4 @@ Frameworks
.. toctree::
- fixed-execution-order/index.rst
+ fixed-order-execution/index.rst
diff --git a/docs/features/index.rst b/docs/features/index.rst
index c4b3282d..16a5c809 100644
--- a/docs/features/index.rst
+++ b/docs/features/index.rst
@@ -12,7 +12,7 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-.. _features:
+.. _Platform_Features:
Features
========
diff --git a/docs/features/infrastructure/bazel_registry.rst b/docs/features/infrastructure/bazel_registry.rst
deleted file mode 100644
index d30e82d7..00000000
--- a/docs/features/infrastructure/bazel_registry.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Bazel registry
-##############
-
-Documentation
-**************
-
-Description
-===========
-
-Score, as a multi repository projects requires a setup of it's own
-registry, that will help managing the dependencies between various
-parts.
-
-The registry is located at:
-https://github.com/eclipse-score/bazel_registry
-
-In order to use it the following lines need to be added to the .bazelrc
-file of a module:
-
-.. code::
-
- common --registry=https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/
- common --registry=https://bcr.bazel.build
-
-Score registry is set as first registry with the fallback to Bazel's
-central registry for other open source modules.
-
-References
-==========
-
-- Bazel external dependency management:
- https://bazel.build/external/overview#bzlmod
-- Bazel central registry browser: https://registry.bazel.build/
-- Bzlmod usage examples:
- https://github.com/bazelbuild/examples/tree/main/bzlmod\
diff --git a/docs/features/infrastructure/index.rst b/docs/features/infrastructure/index.rst
index 7c5fad59..bc30b1e5 100644
--- a/docs/features/infrastructure/index.rst
+++ b/docs/features/infrastructure/index.rst
@@ -12,8 +12,6 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-.. _infrastructure_feratures:
-
################
Infrastructure
################
@@ -36,5 +34,4 @@ that are used for development.
:titlesonly:
:maxdepth: 1
- bazel_registry.rst
config_as_code.rst
diff --git a/docs/features/integration/index.rst b/docs/features/integration/index.rst
index d5047a99..6ec37f42 100644
--- a/docs/features/integration/index.rst
+++ b/docs/features/integration/index.rst
@@ -12,8 +12,6 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-.. _integration_features:
-
Integration
###########
diff --git a/docs/incremental.py b/docs/incremental.py
deleted file mode 100644
index 25a3acb4..00000000
--- a/docs/incremental.py
+++ /dev/null
@@ -1,42 +0,0 @@
-# *******************************************************************************
-# Copyright (c) 2024 Contributors to the Eclipse Foundation
-#
-# See the NOTICE file(s) distributed with this work for additional
-# information regarding copyright ownership.
-#
-# This program and the accompanying materials are made available under the
-# terms of the Apache License Version 2.0 which is available at
-# https://www.apache.org/licenses/LICENSE-2.0
-#
-# SPDX-License-Identifier: Apache-2.0
-# *******************************************************************************
-
-import os
-import sys
-
-try:
- from sphinx.cmd.build import main as sphinx_main
-except ImportError:
- sys.exit(
- "This script must be run from Bazel via `bazel run //docs:incremental`"
- " (sphinx not installed)."
- )
-
-workspace = os.getenv("BUILD_WORKSPACE_DIRECTORY")
-if not workspace:
- sys.exit(
- "This script must be run from Bazel via `bazel run //docs:incremental`"
- " (BUILD_WORKSPACE_DIRECTORY not set)."
- )
-
-# sphinx will print relative paths to the current directory.
-# Change to the workspace root so that the paths are readable and clickable.
-os.chdir(workspace)
-sphinx_main(
- [
- "docs",
- "_build",
- "--jobs",
- "auto",
- ]
-)
diff --git a/docs/index.rst b/docs/index.rst
index ba1f0d19..9d2c6eb9 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -23,7 +23,6 @@ Documentation
-
.. raw:: html
@@ -36,77 +35,11 @@ Documentation
-Welcome & Overview
-------------------
-
-**Welcome to the Software documentation of the SCORE project.**
-
-If this is the first time you get in touch with SCORE, the `SCORE main page `__
-may be a good starting point to receive first insights of the project itself.
-
-Software artifacts
-~~~~~~~~~~~~~~~~~~
-
-.. grid:: 1 1 3 3
- :class-container: score-grid
-
- .. grid-item-card::
-
- Requirements
- ^^^
- Analyse :ref:`Stakeholder ` or :ref:`Tool ` requirements for
- the work with and implementation inside SCORE.
- Or get the complete picture on the :ref:`requirements` page.
-
-
-
- .. grid-item-card::
-
- Features
- ^^^
- :ref:`Features ` are the heart of the SCORE software.
- Understand the internal details of :ref:`Infrastructure `
- or :ref:`Integration ` Features.
-
- .. grid-item-card::
-
- Releases
- ^^^
- Our release roadmap can be found under :ref:`releases`.
- Including an overview about integrated software modules and their repository location.
-
-
-Project structure and processes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. grid:: 1 1 2 2
- :class-container: score-grid
-
- .. grid-item-card::
-
- Process
- ^^^
- Understand how we work, by reading our :ref:`Process description `.
- And receive tips & tricks for our used tool stack by reading the
- :ref:`Guidance `.
-
- .. grid-item-card::
-
- Platform Management Plan (PMP)
- ^^^
- Read about our project and organization structure in the
- :ref:`Project Handbook `.
- And learn how we deal with :ref:`safety_management` or care about :ref:`sw_verification`.
-
-.. dropdown:: Click to see the complete sitemap
-
- .. toctree::
- :maxdepth: 3
+.. toctree::
+ :maxdepth: 2
+ :glob:
- requirements/index
- features/index
- Releases
- process/index
- PMP
- SCORE
- Eclipse
+ requirements/index
+ features/index
+ process/index
+ platform_management_plan/index.rst
diff --git a/docs/platform_management_plan/_assets/contribution_request_label.png b/docs/platform_management_plan/_assets/contribution_request_label.png
deleted file mode 100644
index 86db87f5..00000000
Binary files a/docs/platform_management_plan/_assets/contribution_request_label.png and /dev/null differ
diff --git a/docs/platform_management_plan/_assets/issue_types.png b/docs/platform_management_plan/_assets/issue_types.png
deleted file mode 100644
index 2a059873..00000000
Binary files a/docs/platform_management_plan/_assets/issue_types.png and /dev/null differ
diff --git a/docs/platform_management_plan/_assets/roadmap_example.png b/docs/platform_management_plan/_assets/roadmap_example.png
deleted file mode 100644
index 88f85d37..00000000
Binary files a/docs/platform_management_plan/_assets/roadmap_example.png and /dev/null differ
diff --git a/docs/platform_management_plan/_assets/saga_status_workflow.svg b/docs/platform_management_plan/_assets/saga_status_workflow.svg
deleted file mode 100644
index d38685c7..00000000
--- a/docs/platform_management_plan/_assets/saga_status_workflow.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/platform_management_plan/_assets/sub_issues.png b/docs/platform_management_plan/_assets/sub_issues.png
deleted file mode 100644
index 1727e3df..00000000
Binary files a/docs/platform_management_plan/_assets/sub_issues.png and /dev/null differ
diff --git a/docs/platform_management_plan/_assets/traceability.png b/docs/platform_management_plan/_assets/traceability.png
deleted file mode 100644
index b213bf2e..00000000
Binary files a/docs/platform_management_plan/_assets/traceability.png and /dev/null differ
diff --git a/docs/platform_management_plan/change_management.rst b/docs/platform_management_plan/change_management.rst
deleted file mode 100644
index 392e4dd7..00000000
--- a/docs/platform_management_plan/change_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Change management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/config_management.rst b/docs/platform_management_plan/config_management.rst
deleted file mode 100644
index a67310ba..00000000
--- a/docs/platform_management_plan/config_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Config management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/documentation_management.rst b/docs/platform_management_plan/documentation_management.rst
deleted file mode 100644
index 3cfd616f..00000000
--- a/docs/platform_management_plan/documentation_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Documentation management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/index.rst b/docs/platform_management_plan/index.rst
index 157e8006..37788db0 100644
--- a/docs/platform_management_plan/index.rst
+++ b/docs/platform_management_plan/index.rst
@@ -12,8 +12,6 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-.. _pmp:
-
Platform Management Plan
========================
@@ -42,16 +40,3 @@ Platform Management Plan
:caption: Content
project_management
- stakeholder_management
- safety_management
- risk_management
- quality_management
- config_management
- tool_management
- release_management
- problem_resolution
- change_management
- requirements_management
- software_verification
- documentation_management
- software_development
diff --git a/docs/platform_management_plan/problem_resolution.rst b/docs/platform_management_plan/problem_resolution.rst
deleted file mode 100644
index 84ef2887..00000000
--- a/docs/platform_management_plan/problem_resolution.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Problem Resolution
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/project_management.rst b/docs/platform_management_plan/project_management.rst
index a973cf56..6109a0d9 100644
--- a/docs/platform_management_plan/project_management.rst
+++ b/docs/platform_management_plan/project_management.rst
@@ -12,8 +12,6 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
-.. _project_management_plan:
-
Project management plan
#######################
@@ -62,7 +60,7 @@ Steering of the project is done by two committees: *project lead circle* and *te
Each *Project Lead* is allowed to nominate one *Technical Lead*. The *Technical Leads* form the "Technical Lead Circle". In case of absence, a technical lead can nominate a deputy. *Technical Leads* have the following responsibilities:
- * Review and approval of contributions, e.g. *Feature Requests*, which add or modify SCORE platform features.
+ * Review and approval of *Contribution Requests*, which add or modify SCORE platform features.
* Project management of the platform development, e.g., creation of the roadmap.
* High-level project control and coordination between multiple software modules.
* Escalation instance for software module project leads and committers.
@@ -79,19 +77,20 @@ Technical committees
is to do a breakdown of platform sagas to the concrete tasks (see `Planning`_) .
Currently following *Communities* are defined in the *SCORE* project:
- * *Operational*: *community* for all kind of infra topics:
- compiler, IDE, build toolchain and etc. See `GitHub Discussions/Operational Community `_ for more.
+ * *Tooling/Infrastructure*: *community* for all kind of infra topics:
+ compiler, IDE, build toolchain and etc.
* *Testing*: *community* to clarify questions and define testing strategy
- for the 'SCORE' project. See `GitHub Discussions/Testing Community `_ for more.
+ for the 'SCORE' project
* *Software Architecture*: *community* for clarification of software architecture topics,
- e.g. discussion of new features or coding guidelines. See `GitHub Discussions/Architecture Community `_ for more.
+ e.g. discussion of new features or coding guidelines.
* *Software Development Process*: *community* for definition and maintaining
- of safety, security and quality software development process. See `GitHub Discussions/SW Dev Process Community `_ for more.
+ of safety, security and quality software development process.
The planning of the activities is done by every *Community* independent of other
teams. Each *Community* has a *Community Lead*, who is nominated by the *Technical lead circle*. The prioritization of some topics can be requested by the *Technical lead circle*
in order to achieve milestones on time. All important architectural decisions
- should be reported to the project as *Feature Request* to get the final approvement from the *Technical lead circle*.
+ should be reported to the project as *Contribution Request*
+ to get the final approvement from the *Technical lead circle*.
* **Cross functional teams**
@@ -103,7 +102,6 @@ Technical committees
In case *Cross-functional team* needs to request a new repository, this can be done be extending the `otterdog configuration file `_ and creating a new PR, that should be approved by the *Eclipse Project Security Team*.
- The *GitHub Discussions* for cross-functional teams can be found in the `Cross-functional teams section `_ of the main *SCORE* project.
Meeting Structure
-----------------
@@ -118,7 +116,6 @@ Meeting Structure
The *Project Lead Circle meeting* takes place usually once a week.
-
* **Technical Lead Circle meeting**
Regular participants of the *Technical Lead Circle meeting* are the *Technical Leads* of the main *SCORE* project. The main purpose of the meeting is the exchange between technical leads for fulfilling their responsibilities.
@@ -131,7 +128,7 @@ Meeting Structure
* **Committer Circle Meeting**
- Regular participants of the *Committer Circle meeting* are the *Committers* of the main *SCORE* project and of all software modules/child projects. The *Committer Circle Meeting* is lead by the *Technical Leads*. The main purpose of the meeting are in-depth technical discussions and evaluation of contributions, e.g. *Feature Requests*, that could not be approved in the *Technical Lead Circle meeting* and demand more technical discussions.
+ Regular participants of the *Committer Circle meeting* are the *Committers* of the main *SCORE* project and of all software modules/child projects. The *Committer Circle Meeting* is lead by the *Technical Leads*. The main purpose of the meeting are in-depth technical discussions and evaluation of the *Contribution Requests*, that could not be approved in the *Technical Lead Circle meeting* and demand more technical discussions.
The *Committer Circle meetings* are announced via *score-dev@eclipse.org* mailing list and are open for everyone who is registered to this mailing list. All meetings are documented as *GitHub Discussions* in `Committer Circle section `_ and can be read by everyone. Topics for the *Committer circle meetings* can be proposed only by regular participants and will be prioritized by the *Technical lead circle*. Proposals for agenda topics can be added as comment to the respective *GitHub Discussion* or sent to the *Technical lead circle Assistant*.
@@ -143,7 +140,7 @@ Platform consists of multiple repositories. The main repository, *SCORE*,
is the integration repository, where everything comes together. It contains:
* :ref:`stakeholder requirements `
-* documentation of all :ref:`platform features ` and features flags,
+* documentation of all :ref:`platform features ` and features flags,
feature requirements and architecture
* build system including *SCORE* specific *macros* and *rules*
* integration rules for software modules.
@@ -184,214 +181,4 @@ meetings, where such topics are discussed and decided, see `Steering committees`
Planning
========
-
-Planning infrastructure
-------------------------
-`GitHub issues `_ are used to plan and to track
-work. To be able to find issues faster and to filter for them more efficiently,
-we use labels.
-
-Labels
-^^^^^^
-To facilitate the organization and tracking of tickets related to the same feature
-or topic, labels are utilized for issues and pull requests. Labels are a powerful
-feature that allows you to search and filter tickets based on specific labels, and
-you can save these filters in a *GitHub Project* view. However, it is important
-to exercise caution when creating labels to avoid confusion and ensure easy tracking.
-
-It's worth noting that labels are associated with a repository, not a *GitHub Project*.
-To create new labels in the repository requires special rights and only
-*project leads* and *committers* should have this capability.
-
-For the main *SCORE* repository, there exist already some predefined labels:
-
-* *feature_request* label is used to identify *PRs* and *GitHub Issues* that are part
- of a *Feature request process*
-* *project_lead_circle* label is used to identify *PRs* and *GitHub Issues* that are relevant
- for *Project lead circle*
-* *tech_lead_circle* label is used to identify *PRs* and *GitHub Issues* that are relevant
- for *Technical lead circle*
-* *infrastructure* label is used to identify *PRs* and *GitHub Issues* that are relevant
- for *Tooling/Infrastructure Community*
-* *testing* label is used to identify *PRs* and *GitHub Issues* that are relevant for
- *Testing Community*
-* *software_architecture* label is used to identify *PRs* and *GitHub Issues* that are relevant
- for *Software Architecture community*
-* *software_development_process* label is used to identify *PRs* and *GitHub Issues* that are
- relevant for *Software Development Process Community*
-
- .. image:: _assets/contribution_request_label.png
- :width: 800
- :alt: Infrastructure overview
- :align: center
-
-Additionally, in the main *SCORE* repository there should exist a label for every
-software module.
-
-Every software module project, located in another repository, is free to define
-additionally its own labels. It is recommended to create labels at least
-for specific areas that may encompass multiple features.
-
-Types of tasks and structure
-------------------------------
-For better structuring of the tickets following *GitHub Issue* types are introduced
-in the main *SCORE* repository. It is recommended for all *child projects* to
-introduce the same types.
-
-.. image:: _assets/issue_types.png
- :width: 600
- :alt: Issue types overview
- :align: center
-
-* *Saga* *GitHub Issue* of type *Saga* is the highest level hierarchy and can not
- be a sub-issue of another ticket. If you want to group *Sagas* together, you will
- need to use labels. *Saga* can have multiple *Epics* as sub-issues. In really
- exceptional cases, also a *Story* can be a direct sub-issue of a *Saga* as well.
-* *Epic* *GitHub Issue* of type *Epic* groups multiple *Stories* together and is sub-issue
- of exactly one *Saga*. *Epics* can be also standalone *GitHub Issues* without being
- a child of any *Saga*. *Saga* should be the only way for grouping *Epics* together.
- Grouping standalone *Epics* with labels is not something, what we encourage you to do.
-* *Story* *GitHub Issue* of type *Story* is the lowest planning granularity and represents
- concrete task, that should be done, e.g. by a developer. Normally *Stories* are
- grouped together in an Epic. In some cases a *Story* can exist as a standalone *GitHub issue*.
- Grouping standalone *Stories* with labels is not something, what we encourage you to do.
-* *Bug* *GitHub Issue* of type *Bug* is used to report any kind of problems. It can be
- a standalone *GitHub Issue* or can be a sub-issue of an *Epic* or a *Saga*.
- It is also ok to use labels to group multiple *Bugs* that are related to the same topic.
-
-Main *SCORE* project defines templates for every type of *GitHub Issues*
-to ensure, that every ticket has all necessary information.
-
-For a better structuring of the *GitHub Issues*, we use a beta
-`sub-issue feature `_,
-that should be officially released in the beginning of 2025.
-*Sub-issue feature* allows to create a "parent-child" relationship between *GitHub Issues*.
-That allows better structuring of the project and helps to keep *GitHub Issues*, that
-are related to the same topic, together.
-
-.. image:: _assets/sub_issues.png
- :width: 600
- :alt: Sub issues overview
- :align: center
-
-
-Traceability
-^^^^^^^^^^^^
-To achieve a better traceability it is highly recommended to link all *PRs* to the corresponding
-*GitHub Issues*. If done properly, you will be able to see for every *GitHub Issue*
-all relevant source code changes. Normally *PRs* reference *GitHub issues* of type *Story*
-or of type *Bug*. How to link *PRs* to *GitHub Issues* is described in more details in this
-`guide `_.
-
-.. image:: _assets/traceability.png
- :width: 300
- :alt: Traceability overview
- :align: center
-
-GitHub Projects
-^^^^^^^^^^^^^^^
-*GitHub Projects* is a very powerful tool that allows creation of various views on
-the status of the project, helps to plan the work and to monitor the current progress.
-In particular, *GitHub Project* allows to extend *GitHub Issues* with following information:
-
-* objective
-* dependencies on other activities or information
-* responsible person
-* resources
-* mapping to work product
-* start, end, duration, effort
-
-Note: The information on start, end, duration, and effort may sometimes be complicated
-to estimate in the execution in an open source environment. Nevertheless, tasks
-should be planned as part of releases, which sets already an implicit
-duration and end date.
-
-Software module project leads shall also use *GitHub Project* for their planning. The overview of *GitHub Project* features can be found `here `_.
-
-Multiple *GitHub projects* are defined in the main *SCORE* project:
-
-* a separate project for every community
-* a project for technical lead circle
-* a (GitHub) *roadmap project* with the overview of all upcoming features & releases.
-
- As *GitHub Projects* are not restricted to one repository but
- can include information from multiple repositories of the same organization,
- *roadmap project* gives an overview of all *Sagas*, that are relevant for the roadmap,
- including those ones in the software modules. Prerequisite for this is that project
- leads of all software modules always assign their sagas to the *roadmap project*.
- All sagas in the *roadmap project* are extended with additional information
- as e.g. start date and due date, to keep the status of the project always transparent.
- Additionally, the main *SCORE* repository defines project wide milestones & releases,
- that are visible in the roadmap as well.
-
-.. image:: _assets/roadmap_example.png
- :width: 600
- :alt: Roadmap example
- :align: center
-
-Releases and milestones
-^^^^^^^^^^^^^^^^^^^^^^^^
-GitHub allows to define various milestones & releases for every repository. The definition of the milestones and releases is proposed by the *Technical Leads* and is approved by *Project Leads*.
-
-In the main *SCORE* project we use milestones to mark important stages of the project and map sagas or in some cases also other *GitHub Issues* to them.
-
-*Releases* are used for structuring of the development activities. Exact scheme for the releases of the *SCORE* will be provided here later.
-
-You can find "up to date" overview of the release plan and milestones in the following section `Score Releases `_.
-
-Planning process
-----------------
-Generally, every team is responsible for planning and managing of its backlog.
-For small improvements or clarifications, you can create *GitHub Issue* with a exhaustive
-description and map it to the topic using labels. For small improvements/bugs
-in the software modules you should create *GitHub Issues* directly in the repository
-of the submodule. The project leads and committers of the corresponding software module,
-circle or community will check the issue and in case they will accept it, they will
-take it over to one of their *GitHub Projects*. In case, the topic, that you raise in the issue has a big impact on the platform, you can be asked by the committers to raise a *Feature Request* and to do a POC in the `incubation repository `_ .
-
-Contribution to the project is described in more details in `Contribution Request Guideline `_.
-In general, everyone who wants to provide something new to the project, e.g. a new feature
-or a tool, should provide an exhaustive description, requirements and in some cases
-also initial draft of the architecture as part of the *Feature Request*.
-*Feature Requests* are regularly reviewed in the *Technical lead circle*
-and then get either accepted or declined.
-
-After the *Feature Request* was accepted, then the *Pull Request* with the
-*Feature Request* gets merged. The corresponding *GitHub Issue* gets a reference to the
-newly defined saga which plans the implementation of the feature request and afterwards *GitHub Issue* for *Feature Request* gets closed. The saga is at the beginning in the state *"Draft"*. Please be aware, that "status" of the tickets is modelled in *GitHub Project* as *GitHub Issues* do not provide the possibility to define additional states.
-
-The *Technical lead circle* is responsible for maintenance of the backlog with sagas,
-their prioritization and creation of the roadmap. Together with software module
-project leads and community leads in the "Committer circle" they go through the backlog, decide when and which saga should be implemented in which order and update the roadmap accordingly.
-
-As soon as the saga was planned for implementation, its state is changed to *"Open"*.
-As next step, a *GitHub Issue* of type *epic* is created as sub-issue of the saga
-and gets assigned to one of the *Communities* for refinement. The state of the saga changes from "Open" to "In Specification".
-
-.. image:: _assets/saga_status_workflow.svg
- :width: 900
- :alt: Planning workflow
- :align: center
-
-The members of the *Responsible Community* define or refine feature, process or tool requirements. They may also create feature architecture and high level component requirements for every involved software component. Depending on the feature scope, one of the cross-functional team can be requested to make a POC in the `incubation repository `_. Finally, *Responsible Community* does the break down of the corresponding *saga* to the tickets that can be assigned to the individual software modules or *communities*.
-As most of the software modules will have their own separate repository,
-then the detailed tracking of their work will also happen inside of that repository.
-However, the corresponding saga of the SCORE repository will still have a sub-issue of type epic,
-that will describe the work, that should be done inside of the software module for better planning.
-In the epic description there should be a link to the software module repository ticket,
-where the detailed information and break down to the stories can be found.
-For those communities or modules, that are part of the main *SCORE* repository,
-the break down to the stories should be done directly inside of the epic.
-
-As soon as the work on saga starts, its status is changed to "In Progress"
-and its sub-tickets get assigned to the project leads of the software modules
-or leads of the *communities*. During the development of the saga,
-we use "trunk based approach", it means, that we do not create any separate branches,
-but develop the software directly in the trunk/main using feature flag, that is marked as "experimental" at the beginning.
-
-The *Technical lead circle* regularly monitors the status of the sagas with the status
-"In Progress", resolves conflicts and updates the roadmap if necessary.
-
-As soon as the saga is implemented and fulfills to 100% our software development process requirements, the decision is taken in the *Technical lead circle* whether the feature should be
-officially available and in case of the positive decision, the feature flag status
-is changed from "experimental" to "official".
+coming soon
diff --git a/docs/platform_management_plan/quality_management.rst b/docs/platform_management_plan/quality_management.rst
deleted file mode 100644
index 26790b4b..00000000
--- a/docs/platform_management_plan/quality_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Quality management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/release_management.rst b/docs/platform_management_plan/release_management.rst
deleted file mode 100644
index 69b518f9..00000000
--- a/docs/platform_management_plan/release_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Release management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/requirements_management.rst b/docs/platform_management_plan/requirements_management.rst
deleted file mode 100644
index e2a6b5a4..00000000
--- a/docs/platform_management_plan/requirements_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Requirements management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/risk_management.rst b/docs/platform_management_plan/risk_management.rst
deleted file mode 100644
index 52cc1e13..00000000
--- a/docs/platform_management_plan/risk_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Risk management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/safety_management.rst b/docs/platform_management_plan/safety_management.rst
deleted file mode 100644
index 68db7dfa..00000000
--- a/docs/platform_management_plan/safety_management.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-.. _safety_management:
-
-Safety management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/software_development.rst b/docs/platform_management_plan/software_development.rst
deleted file mode 100644
index 4e07fb6d..00000000
--- a/docs/platform_management_plan/software_development.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Software Development
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/software_verification.rst b/docs/platform_management_plan/software_verification.rst
deleted file mode 100644
index 81ad2735..00000000
--- a/docs/platform_management_plan/software_verification.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-.. _sw_verification:
-
-Software Verification
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/stakeholder_management.rst b/docs/platform_management_plan/stakeholder_management.rst
deleted file mode 100644
index 237bea2d..00000000
--- a/docs/platform_management_plan/stakeholder_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Stakeholder Management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/platform_management_plan/tool_management.rst b/docs/platform_management_plan/tool_management.rst
deleted file mode 100644
index 623cdf08..00000000
--- a/docs/platform_management_plan/tool_management.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Tool Management
-------------------------
-
-Purpose
-+++++++
-
-Objectives and scope
-++++++++++++++++++++
-
-Approach
-++++++++
diff --git a/docs/process/guidance/contribution_request/_assets/score_contribution_request_simple.drawio.svg b/docs/process/guidance/contribution_request/_assets/score_contribution_request_simple.drawio.svg
deleted file mode 100644
index e6d6eb50..00000000
--- a/docs/process/guidance/contribution_request/_assets/score_contribution_request_simple.drawio.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/process/guidance/contribution_request/_assets/score_contribution_request_standard.drawio.svg b/docs/process/guidance/contribution_request/_assets/score_contribution_request_standard.drawio.svg
deleted file mode 100644
index 23c665f1..00000000
--- a/docs/process/guidance/contribution_request/_assets/score_contribution_request_standard.drawio.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/process/guidance/contribution_request/_assets/score_discussion_request_options.drawio.svg b/docs/process/guidance/contribution_request/_assets/score_discussion_request_options.drawio.svg
deleted file mode 100644
index 49de8399..00000000
--- a/docs/process/guidance/contribution_request/_assets/score_discussion_request_options.drawio.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/process/guidance/contribution_request/index.rst b/docs/process/guidance/contribution_request/index.rst
deleted file mode 100644
index d22ad07d..00000000
--- a/docs/process/guidance/contribution_request/index.rst
+++ /dev/null
@@ -1,150 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-###############################
- Contribution Request Guideline
-###############################
-
-.. gd_guidl:: Contribution Request Guideline
- :id: GD_GUIDL__Contr_Request_Guideline
- :status: valid
- :tags: contribution_management
-
-Contributions to the *SCORE* project are the key to grow the content including the code. Contributions may cover simple improvement proposals, bug or problem reports, but also more complex scope changes of features up to new feature requests. Depending on the contribution scope, several steps may be required to finally merge it within the *SCORE* repository.
-
-This guidline shall help the contributor (:need:`Contributor `) to find the right path for his contribution.
-
-For simple contributions, like fixing bugs or improvements, just creating a *PR* is sufficient.
-
-For more complex contributions, like adding a new feature, where it's unfitting to just open a PR, open an *GitHub Issue* to discuss with the community before starting work on it, would be the preferred way.
-
-You can also join our `Slack `_ for real-time discussions.
-
-The *SCORE* project defines a Contribution Request (**COR**) as any defined and allowed trigger to start the active contribution to the *SCORE* project. That means obviously that a *PR* is a Contribution Request.
-
-Summary:
-
-* You want to report something (like a bug) or start a discussion where you do not know the code solution yet, open a *GitHub Issue* (:need:`GD_GUIDL__Issue_Guideline`).
-* You want to manage complex coordination problems (planning activities) that require collaboration across multiple stakeholders, open a *GitHub Issue* (:need:`GD_GUIDL__Issue_Guideline`).
-* You want to propose a scope change of a feature or a new feature, open a *GitHub Issue* (:need:`GD_GUIDL__Issue_Guideline`) and add required PRs to that *GitHub Issue*.
-* You want to report a bug or problem including a code solution? Start with a *PR* (:need:`GD_GUIDL__Pull_Request_Guideline`).
-* You want to propose an improvement (also to a process or other work products) including a code solution? Start with a *PR* (:need:`GD_GUIDL__Pull_Request_Guideline`).
-
-Whenever your *PR* gets too big or involves committs of several contributors , we strongly encourage to open and link a *GitHub Issue*, so this can get better planned.
-
-For a *PR* to be merged, in any case an approval of a committer is needed. If the committer decides, that only a *PR* is not sufficient and a *GitHub Issue* is needed, then the contributor shall also create a corresponding *GitHub Issue*.
-
-*GitHub Issue* are categorized using various types. For categorizing of PRs using of labels, e.g. bug or improvement, is mandatory, see `Platform Management Plan `_.
-
-For all possibilites the project contains simple templates (provided by committers (:need:`Committer `)), in particular please use :ref:`Feature Request Template ` to request a new feature or changes to the existing one.
-
-*****************************
- What is a Pull Request (PR)?
-*****************************
-
-.. gd_guidl:: Pull Request Guideline
- :id: GD_GUIDL__Pull_Request_Guideline
- :status: valid
- :tags: contribution_management
-
-A Pull Request (**PR**) is the **ONLY** way to contribute **CODE** to the *SCORE* project.
-
-The figure below shows a simplified workflow for a PR.
-
-* The contributor (:need:`Contributor `) starts by creating a PR: `Creating a Pull Request (Github Docs) `_.
-* 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 `) will approve the *PR* and thus it can be merged.
-
-.. figure:: _assets/score_contribution_request_simple.drawio.svg
- :width: 600
- :align: center
- :alt: Simple *PR* based contribution request workflow overview
-
- Simple *PR* based contribution request workflow overview
-
-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 *SCORE* project. In case of doubt or for any other input we strongly encourage to open a *GitHub Issue* (:need:`GD_GUIDL__Issue_Guideline`) first.
-
-The *PR* should provide all required information of the new or changed content. Therefore the *SCORE* project provides content specific templates, which the contributor (:need:`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.
-
-This historical record is available by the normal git commands for retrieving older revisions, and can also be browsed on GitHub.
-
-**************************************
-Detailed *SCORE* Pull Request Workflow
-**************************************
-
-This chapter is only for optional read to understand the details for the Pull Request workflow defined in *SCORE*.
-
-The figure below gives an overview about all the possible steps for a *PR* until it is either accepted or rejected.
-
-.. figure:: _assets/score_contribution_request_standard.drawio.svg
- :width: 100%
- :align: center
- :alt: Detailed *SCORE* Pull request workflow overview
-
- Detailed *SCORE* Pull request workflow overview
-
-Create a PR
-===========
-
-The contributor (:need:`Contributor `) creates a PR.
-
-Reviewers will be automatically assigned (:need:`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 `), the *PR* is not approved and thus not merged and further changes are requested. Once the contributor (:need:`Contributor `) considers all review comments as resolved, :need:`Contributor ` can re-request a review. The committer (:need:`Committer `) reviews the *PR* content according the *SCORE* review and acceptance criteria (ToDo link here to the criteria).
-Further the contributor (:need:`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 `) will place the *PR* to the "Draft" state.
-
-It is then the responsibility of the contributor (:need:`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) `_.
-
-At any point the contributor (:need:`Contributor `) may decide not to continue with the PR, then the contributor (:need:`Contributor `) just closes the PR.
-
-
-What is a GitHub Issue?
-=======================
-
-.. gd_guidl:: Issue Guideline
- :id: GD_GUIDL__Issue_Guideline
- :status: valid
- :tags: contribution_management
-
-A *GitHub Issue* is the way to report bugs or propose improvements without knowing the solution and to request features (incl. scope changes).
-
-For creating *GitHub Issue* compare here: `Creating a GitHub Issue (Github Docs) `_.
-
-Create an *GitHub Issue* to collect feedback, before investing too much effort into a *PR*. *GitHub Issues* may be accompanied by draft *PRs* if code is to be shown.
-
-It can also be used to collect community input and for planning and tracking activities.
-
-The figure below shows options to report something.
-
-.. figure:: _assets/score_discussion_request_options.drawio.svg
- :width: 400
- :align: center
- :alt: Reporting options overview
-
- Reporting options overview
-
- .. toctree::
- :maxdepth: 1
- :glob:
-
- templates/index.rst
diff --git a/docs/process/guidance/contribution_request/templates/feature_request_template.rst b/docs/process/guidance/contribution_request/templates/feature_request_template.rst
deleted file mode 100644
index c52f757f..00000000
--- a/docs/process/guidance/contribution_request/templates/feature_request_template.rst
+++ /dev/null
@@ -1,136 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-.. _feature_request_template:
-
-Feature Request Template
-########################
-
-.. gd_temp:: Feature Request Template
- :id: GD_TEMP__Feat_Request_Template
- :status: valid
- :tags: contribution_request
-
-.. attention::
- Remove everything above when copying and filling the template.
-
-[Your Feature Name]
-===================
-
-.. document:: [Your Feature Name]
- :id: DOC__Your_Feature_Name
- :status: draft
- :safety: ASIL_D
- :tags: contribution_request, feature_request
-
-.. attention::
- The above directive must be updated according to your Feature.
-
- - Modify ``name`` to be your Feature Name
- - Modify ``id`` to be your Feature Name in upper snake case preceded by ``DOC_``
- - Adjust ``status`` to be ``valid``
- - Adjust ``asil`` according to your needs
- - Extend ``tags`` according to your needs, but please keep two default tags there
-
-
-Feature flag
-============
-
-To activate this feature, use the following feature flag:
-
-``experimental_[your_feature_name]``
-
- .. note::
- The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as
- long as the feature is not yet stable.
-
-
-Abstract
-========
-
-[A short (~200 word) description of the contribution being addressed.]
-
-
-Motivation
-==========
-
-[Clearly explain why the existing platform/project solution is inadequate to address the topic that the Feature Request solves.]
-
- .. note::
- The motivation is critical for Feature Requests that want to change the existing features or infrastructure.
- It should clearly explain why the existing solution is inadequate to address the topic that the Feature Request solves.
- Feature Request submissions without sufficient motivation may be rejected.
-
-
-Rationale
-=========
-
-[Describe why particular design decisions were made.]
-
-
- .. note::
- The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
-
-
-Specification
-=============
-
-[Describe the requirements, architecture of any new feature.] or
-[Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]
-
- .. note::
- A Feature Request shall specify the stakeholder requirements as part of our platform/project.
- Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request).
-
-
-Backwards Compatibility
-=======================
-
-[Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.]
-
-
-Security Impact
-===============
-
-[How could a malicious user take advantage of this new feature?]
-
- .. note::
- If there are security concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
-
-
-
-Safety Impact
-=============
-
-[How could the safety be impacted by the new feature?]
-
- .. note::
- If there are safety concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
- ToDo - Link to the Safety Impact Method
-
-[What is the expected ASIL level?]
-[What is the expected classification of the contribution?]
-
- .. note::
- Use the component classification method here to classfiy your component, if it shall to be used in a safety context: (TODO: add link to component classification).
-
-
-License Impact
-==============
-
-[How could the copyright impacted by the license of the new contribution?]
-
-
-How to Teach This
-=================
diff --git a/docs/process/guidance/contribution_request/templates/index.rst b/docs/process/guidance/contribution_request/templates/index.rst
deleted file mode 100644
index b7878be6..00000000
--- a/docs/process/guidance/contribution_request/templates/index.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-.. _contribution_templates:
-
-#######################
- Contribution Templates
-#######################
-
-.. toctree::
- :maxdepth: 1
- :glob:
-
- feature_request_template.rst
diff --git a/docs/process/guidance/requirements/index.rst b/docs/process/guidance/requirements/index.rst
deleted file mode 100644
index 1b1a5824..00000000
--- a/docs/process/guidance/requirements/index.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-.. _requirement_guidance:
-
-######################
- Requirement Guidance
-######################
-
-.. toctree::
- :maxdepth: 1
- :glob:
-
- requirement_template.rst
diff --git a/docs/process/guidance/requirements/requirement_template.rst b/docs/process/guidance/requirements/requirement_template.rst
deleted file mode 100644
index e43703d8..00000000
--- a/docs/process/guidance/requirements/requirement_template.rst
+++ /dev/null
@@ -1,119 +0,0 @@
-..
- # *******************************************************************************
- # Copyright (c) 2024 Contributors to the Eclipse Foundation
- #
- # See the NOTICE file(s) distributed with this work for additional
- # information regarding copyright ownership.
- #
- # This program and the accompanying materials are made available under the
- # terms of the Apache License Version 2.0 which is available at
- # https://www.apache.org/licenses/LICENSE-2.0
- #
- # SPDX-License-Identifier: Apache-2.0
- # *******************************************************************************
-
-Requirement Templates
-~~~~~~~~~~~~~~~~~~~~~
-
-todo: add links to standards
-
-.. gd_temp:: Stakeholder Requirements Template
- :id: GD_TEMP__stakeholder_requirements_template
- :status: draft
- :tags: requirements_management
-
- | .. stkh_req::
- | :id: STHK_REQ__
- | :reqtype:
- | :security:
- | :safety:
- | :rational:
- | :status:
-
-
-.. gd_temp:: Feature Requirements Template
- :id: GD_TEMP__feature_requirements_template
- :status: draft
- :tags: safety
-
- | .. feat_req::
- | :id: FEAT_REQ____
- | :reqtype:
- | :security:
- | :safety:
- | :satisfies:
- | :status:
-
-
-.. gd_temp:: Component Requirements Template
- :id: GD_TEMP__component_requirements_template
- :status: draft
- :tags: safety
-
- | .. comp_req::
- | :id: COMP_REQ____
- | :reqtype:
- | :security:
- | :safety:
- | :satisfies:
- | :status:
-
-
-.. gd_temp:: Tool Requirements Template
- :id: GD_TEMP__tool_requirements_template
- :status: draft
- :tags: safety
-
- | .. tool_req::
- | :id: TOOL_REQ____
- | :reqtype:
- | :security:
- | :safety:
- | :satisfies:
- | :status:
-
-
-.. gd_temp:: Requirement Formulation Template
- :id: GD_TEMP__requirement_formulation
- :status: valid
- :tags: safety
-
- Requirements shall be specified according to the following schema:
-
- shall