process: correct typos

Issue-ref: resolves #21 Signed-off-by: Philipp Ahmann <[email protected]>
eclipse-score · Dec 9, 2024 · 6d30dd1 · 6d30dd1
1 parent 80c9672
commit 6d30dd1
Show file tree

Hide file tree

Showing 8 changed files with 9 additions and 6 deletions.
diff --git a/docs/index.rst b/docs/index.rst
@@ -21,6 +21,6 @@ Documentation
 
    stakeholder_requirements/index.rst
    tool_requirements/index.rst
-   process_description/index.rst
+   process/index.rst
    features/index.rst
    platform_management_plan/index.rst
diff --git a/docs/platform_management_plan/project_management.rst b/docs/platform_management_plan/project_management.rst
@@ -98,7 +98,10 @@ Technical committees
   of work from the beginning (e.g. definition of the architecture) till the end
   (e.g. integration tests) and are usually assigned to the *SCORE* main integration project or to one particular software module. *Cross-functional teams* work independently from each other on *GitHub* issues in the assigned software module. *Cross-functional teams* consist of the contributors, who can specify requirements, define architecture, develop source code and implement tests afterwards. *Project Leads* and *Committers* are also *Contributors* and effectively work on processing of *GitHub* issues.
 
-  Cross-functional team usually consists of the following roles: Project Lead, Safety Manager, Quality Manager, Security Manager, Committers and Contributors. Every *cross-functional* team has at least one committer who can approve and merge the Pull Requests of the Contributors.
+  *Cross-functional team* usually consists of the following roles: Project Lead, Safety Manager, Quality Manager, Security Manager, Committers and Contributors. Every *cross-functional* team has at least one committer who can approve and merge the Pull Requests of the Contributors.
+
+  In case *Cross-functional team* needs to request a new repository, this can be done be extending the `otterdog configuration file <https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet>`_ and creating a new PR, that should be approved by the *Project Leads*.
+
 
 Meeting Structure
 -----------------
@@ -160,17 +163,17 @@ as defined by the *Eclipse Foundation Project Handbook*. Software module committ
 and software module project leads are responsible for managing the software module as if it were
 a normal *Eclipse child project*. The election of the project leads and committers for software module projects should be done using the main integration *SCORE* project mailing list, *[email protected]*. This means, that the decision who will be the project lead and committer of the new software module will be taken by the project leads and committers of the main *SCORE* project respectively. The elected project leads or committers of the software modules are not automatically project leads and committers of the main integration *SCORE* project. Typically, before becoming a project lead or a committer of the main integration *SCORE* project, you need to build up a good reputation by contributing to the main integration *SCORE* project and being project lead or committer for one of the software modules.
 
-That should be a normal procedure, that before introducing a new *Eclipse child project* for a software module, it should first reside as a repository in the main *SCORE* project. If the software module later would be moved to a real standalone *Eclipse child project*, e.g., as there is a wish to use this software module independent of the *SCORE* project, then the elected project leads and committers of the software module will be simply taken over as project leads and committers of the new *Eclipse child project* and their tasks will stay the same. Further in this document differentation between a software module and  *Eclipse child project* will be done only if necessary. For the software module that resides in the separate repository of the main *SCORE* project, the configuration and the control
+That should be a normal procedure, that before introducing a new *Eclipse child project* for a software module, it should first reside as a repository in the main *SCORE* project. If the software module later would be moved to a real standalone *Eclipse child project*, e.g., as there is a wish to use this software module independent of the *SCORE* project, then the elected project leads and committers of the software module will be simply taken over as project leads and committers of the new *Eclipse child project* and their tasks will stay the same. Further in this document differentiation between a software module and  *Eclipse child project* will be done only if necessary. For the software module that resides in the separate repository of the main *SCORE* project, the configuration and the control
 of who is committer and project lead is done using
 `CODEOWNER files <https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners>`_
-located in the subfolders of the corresponding repository of the software module.
+located in the subfolder of the corresponding repository of the software module.
 
 Main task of project leads is planning and prioritizing of activities, and together with the committers maintaining of the backlog and ensuring, that the software development is done according to process described in the main SCORE project. The planning should be done as described in the `Planning`_ chapter. A more detailed description of PLs' and Committers' activities is given in *Eclipse Foundation Project Handbook*.
 
 The main project *SCORE* has certainly also project leaders and committers, but
 their roles are slightly different compared to the software module committers and
 project leads. The role of the *SCORE* project as the central project is, as already
-described, to ensure proper integration of multiple softwarre modules, provide common
+described, to ensure proper integration of multiple software modules, provide common
 integration guidelines and mechanisms, e.g. build toolchain. Additionally *SCORE* project
 takes care of all overarching topics, as e.g. roadmap and milestone planning or
 definition of cross-functional topics. Therefore there exist number of additional

diff --git a/...s_description/guidelines/branch/index.rst → docs/process/guidelines/branch/index.rst b/...s_description/guidelines/branch/index.rst → docs/process/guidelines/branch/index.rst
diff --git a/..._description/guidelines/general/index.rst → docs/process/guidelines/general/index.rst b/..._description/guidelines/general/index.rst → docs/process/guidelines/general/index.rst
@@ -102,7 +102,7 @@ can be in a different order.
 
     platform-integration-tests/                     -> Integration tests on reference hardware.
 
-    process/process_model/                          -> process definition including workflows, workproducts, roles, guidance [WP_PROCESS_DEFINITION]
+    process/                                        -> process definition including workflows, workproducts, roles, guidance [WP_PROCESS_DEFINITION]
 
     registry/                                       -> infrastructure configuration
 

diff --git a/...cess_description/guidelines/git/index.rst → docs/process/guidelines/git/index.rst b/...cess_description/guidelines/git/index.rst → docs/process/guidelines/git/index.rst
diff --git a/.../process_description/guidelines/index.rst → docs/process/guidelines/index.rst b/.../process_description/guidelines/index.rst → docs/process/guidelines/index.rst
diff --git a/docs/process_description/index.rst → docs/process/index.rst b/docs/process_description/index.rst → docs/process/index.rst
diff --git a/docs/process_description/templates/index.rst → docs/process/templates/index.rst b/docs/process_description/templates/index.rst → docs/process/templates/index.rst