diff --git a/docs/contribute/index.rst b/docs/contribute/index.rst index 3fe9efa118c..12235863c7b 100644 --- a/docs/contribute/index.rst +++ b/docs/contribute/index.rst @@ -56,7 +56,7 @@ How is S-CORE organized Eclipse S-CORE is an open source project, so everyone is welcome to contribute. Since we are organized within the Eclipse Foundation, you must have an Eclipse Foundation account to participate - please see :ref:`contribution_attribution` for details. -The project is structured into various :ref:`technical committees `, that include communities which focus on cross-cutting topics and feature teams responsible for the implementation of specific functionalities. Their meetings are public; feel free to join or review the minutes via our `GitHub Discussions `_. +The project is structured into various :ref:`communities `, which focus on cross-cutting topics and :ref:`feature teams ` responsible for the implementation of specific functionalities. Their meetings are public; feel free to join or review the minutes via our `GitHub Discussions `_. Additionally, two :ref:`steering committees `, the Technical Lead Circle and the Project Lead Circle, oversee the overall steering and planning of S-CORE. 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 2a059873808..00000000000 Binary files a/docs/platform_management_plan/_assets/issue_types.png and /dev/null differ diff --git a/docs/platform_management_plan/_assets/project_organization.svg b/docs/platform_management_plan/_assets/project_organization.svg deleted file mode 100644 index 41d80dd4ca6..00000000000 --- a/docs/platform_management_plan/_assets/project_organization.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Main SCORE Project
Main SCORE
integration repo
SCORE GitHub organization
Software Module Repo
Software Module Repo
Software Module Repo
CODEOWNER
  • Software Module PLs
  • Software Module Committers
CODEOWNER
  • SCORE PLs
  • SCORE Committers
CODEOWNER
  • Software Module PLs
  • Software Module Committers
CODEOWNER
  • Software Module PLs
  • Software Module Committers
Software Module Repo
Software Module Repo
Software Module
GitHub organization
CODEOWNER
  • Software Module PLs
  • Software Module Committers
Software Module can later
become an Eclipse Child Project
 \ No newline at end of file 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 88f85d37e7e..00000000000 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 d38685c7d45..00000000000 --- a/docs/platform_management_plan/_assets/saga_status_workflow.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Draft
Saga Status Workflow
Open
In Progress
Closed
Saga is created and
ready to be planned.
Saga is part of the official
roadmap and is assigned
to a dedicated milestone.
Saga is in
implementation
and testing.
In Specification
Feature architecture,
requirements and
component requirements
are defined.

Break down to epics
is finished
Saga is finished,
feature is officially
available.
 \ No newline at end of file diff --git a/docs/platform_management_plan/_assets/score_change_request_workflow_simple.drawio.svg b/docs/platform_management_plan/_assets/score_change_request_workflow_simple.drawio.svg index 9b49ebc1bc9..a50bb7b559e 100644 --- a/docs/platform_management_plan/_assets/score_change_request_workflow_simple.drawio.svg +++ b/docs/platform_management_plan/_assets/score_change_request_workflow_simple.drawio.svg @@ -1,4 +1,1083 @@ - - - -









status:
closed














status:...









status:
in implementation















status:...




















status:
open

















status:...





status:
in review










status:...
ISSUE
[Open]
ISSUE...
creates
creates
Contributor
Contributor
Change Request
Change Request
ISSUE
[Closed]
ISSUE...
ISSUE
[Open]
ISSUE...





CR status:
rejected










CR status:...
ISSUE
[Closed as not planned]
ISSUE...

status:
     No Status
status:...
Projects
Projects

status:
Todo
status:...
Projects
Projects
ISSUE
[Open]
ISSUE...

status:
     In Progress
status:...
Projects
Projects

status:
     Done
status:...
Projects
Projects
Creation
Creation
Analysis
Analysis
Implement and
Monitor
Implement and...
Close
Close
PR
[Open]
PR...
PR
[Draft]
PR...
PR
[Open]
PR...
PR
[Draft]
PR...
PR
[Merged]
PR...
PR
[Closed]
PR...
OR
OR
OR
OR
PR
[Open]
PR...
PR
[Draft
PR...
OR
ORText is not SVG - cannot display \ No newline at end of file + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ closed +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ in implementation +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ open +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ status: +
+ in review +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Open] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + +
+
+
+ creates +
+
+
+ + + creates + + + + + + + + + + + + + + +
+
+
+ + + Contributor + + +
+
+
+ + + Contributor + + + + + + + + + + + + + + + +
+
+
+ Change Request +
+
+
+ + + Change Request + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Closed] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Open] +
+
+
+ + + Issue... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ CR status: +
+ rejected +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + CR status:... + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Closed as not planned] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ No Status +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Todo +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Open] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ In Progress +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Done +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + +
+
+
+ + + Creation + + +
+
+
+ + + Creation + + + + + + + + + + + +
+
+
+ + + Analysis + + +
+
+
+ + + Analysis + + + + + + + + + + + + + + +
+
+
+ + + Implement and +
+ Monitor +
+ + +
+
+
+ + + Implement and... + + + + + + + + + + + + + + +
+
+
+ + + Close +
+ + +
+
+
+ + + Close + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ PR +
+ [Open] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ PR +
+ [Draft] +
+
+
+ + + PR... + + + + + + + + + + + + + + + +
+
+
+ PR +
+ [Open] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ PR +
+ [Draft] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ PR +
+ [Merged] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ PR +
+ [Closed] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ OR +
+
+
+ + + OR + + + + + + + + + + + +
+
+
+ OR +
+
+
+ + + OR + + + + + + + + + + + + + + + + + + + +
+
+
+ PR +
+ [Open] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ PR +
+ [Draft] +
+
+
+ + + PR... + + + + + + + + + + + +
+
+
+ OR +
+
+
+ + + OR + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_problem_resolution_overview.drawio.svg b/docs/platform_management_plan/_assets/score_problem_resolution_overview.drawio.svg index bad4080cb2b..bceb9cde4be 100644 --- a/docs/platform_management_plan/_assets/score_problem_resolution_overview.drawio.svg +++ b/docs/platform_management_plan/_assets/score_problem_resolution_overview.drawio.svg @@ -1,4 +1,87 @@ - - - -
Problem
Report
Problem...
ISSUE
ISSUE
Problem Template
Problem TemplateText is not SVG - cannot display \ No newline at end of file + + + + + + + + + + + + + + +
+
+
+ Problem +
+ Report +
+
+
+ + + Problem... + + + + + + + + + + + + + + + + +
+
+
+ ISSUE +
+
+
+ + + ISSUE + + + + + + + + + + + +
+
+
+ Problem Template +
+
+
+ + + Problem Template + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio - Copy.svg:Zone.Identifier b/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio - Copy.svg:Zone.Identifier new file mode 100644 index 00000000000..e69de29bb2d diff --git a/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio.svg b/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio.svg index 087dbc9b5a5..ecdb16ead2c 100644 --- a/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio.svg +++ b/docs/platform_management_plan/_assets/score_problem_resolution_workflow_simple.drawio.svg @@ -1,4 +1,1057 @@ - - - -









status:
closed














status:...









status:
in implementation















status:...




















status:
open

















status:...





status:
in review










status:...
ISSUE
[Open]
ISSUE...
creates
creates
Contributor, Committer
Contributor, Committer
Problem
Report
Problem...
ISSUE
[CLOSED]
ISSUE...
ISSUE
[OPEN]
ISSUE...





CR status:
rejected










CR status:...
ISSUE
[CLOSED AS NOT PLANNED]
ISSUE...

status:
     No Status
status:...
Projects
Projects

status:
Todo
status:...
Projects
Projects
ISSUE
[OPEN]
ISSUE...

status:
     In Progress
status:...
Projects
Projects

status:
     Done
status:...
Projects
Projects
ISSUE
ISSUE
PR
PR
Change
Request
Change...
PR
PR
:
:
SUB-
ISSUE
SUB-...
ISSUE
ISSUE
:
:
Creation
Creation
Analysis
Analysis
Initiate and
Monitor
Initiate and...
Close
Close
PR
PRText is not SVG - cannot display \ No newline at end of file + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ closed +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ in implementation +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ open +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ status: +
+ in review +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Open] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + +
+
+
+ creates +
+
+
+ + + creates + + + + + + + + + + + + + + +
+
+
+ + + Contributor, Committer + + +
+
+
+ + + Contributor, Committer + + + + + + + + + + + + + + + +
+
+
+ Problem +
+ Report +
+
+
+ + + Problem... + + + + + + + + + + + +
+
+
+ + + Issue + + +
+ [Closed] +
+
+
+ + + Issue... + + + + + + + + + + + +
+
+
+ + + + Issue + + +
+ + [Open] + + +
+
+
+ + + Issue... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ CR status: +
+ rejected +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + CR status:... + + + + + + + + + + + +
+
+
+ + Issue + +
+ + [Closed as not planned] + +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ No Status +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Todo +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ + + + + Issue + + +
+ + [Open] + + + +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ In Progress +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Done +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + +
+
+
+ ISSUE +
+
+
+ + + ISSUE + + + + + + + + + + + +
+
+
+ PR +
+
+
+ + + PR + + + + + + + + + + + + + + + +
+
+
+ Change +
+ Request +
+
+
+ + + Change... + + + + + + + + + + + +
+
+
+ PR +
+
+
+ + + PR + + + + + + + + + + + + + + + + +
+
+
+ + + : + + +
+
+
+ + + : + + + + + + + + + + + + + + + + +
+
+
+ SUB- +
+ ISSUE +
+
+
+ + + SUB-... + + + + + + + + + + + + + + + + +
+
+
+ ISSUE +
+
+
+ + + ISSUE + + + + + + + + + + + +
+
+
+ + + : + + +
+
+
+ + + : + + + + + + + + + + + + + + +
+
+
+ + + Creation + + +
+
+
+ + + Creation + + + + + + + + + + + +
+
+
+ + + Analysis + + +
+
+
+ + + Analysis + + + + + + + + + + + + + + +
+
+
+ + + Initiate and +
+ Monitor +
+ + +
+
+
+ + + Initiate and... + + + + + + + + + + + + + + +
+
+
+ + + Close +
+ + +
+
+
+ + + Close + + + + + + + + + + + + + + + + + + +
+
+
+ PR +
+
+
+ + + PR + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_project_management_issue_status_flow.drawio.svg b/docs/platform_management_plan/_assets/score_project_management_issue_status_flow.drawio.svg new file mode 100644 index 00000000000..6a74378b2a6 --- /dev/null +++ b/docs/platform_management_plan/_assets/score_project_management_issue_status_flow.drawio.svg @@ -0,0 +1,865 @@ + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ closed +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ in implementation +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ status: +
+ open +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ status: +
+ in review +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + status:... + + + + + + + + + + + + + + + +
+
+
+ Issue +
+ [Open] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + +
+
+
+ creates +
+
+
+ + + creates + + + + + + + + + + + + + + +
+
+
+ + + Contributor + + +
+
+
+ + + Contributor + + + + + + + + + + + + + + + +
+
+
+ Any Activity +
+
+
+ + + Any Activity + + + + + + + + + + + +
+
+
+ + + Issue + + +
+ [Closed] +
+
+
+ + + Issue... + + + + + + + + + + + +
+
+
+ + + + Issue + + +
+ + [Open] + + +
+
+
+ + + Issue... + + + + + + + + + + + +
+
+
+
+
+
+
+
+ CR status: +
+ rejected +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + + CR status:... + + + + + + + + + + + +
+
+
+ + Issue + +
+ [Closed as not planned] +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Backlog +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Ready +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + +
+
+
+ + + + + Issue + + +
+ + [Open] + + + +
+
+
+ + + Issue... + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ In Progress +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ Done +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + +
+
+
+ + + Prepare + + +
+
+
+ + + Prepare + + + + + + + + + + + + + + +
+
+
+ + + Work On + + +
+
+
+ + + Work On + + + + + + + + + + + + + + +
+
+
+ + + Close +
+ + +
+
+
+ + + Close + + + + + + + + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + + + +
+
+
+
+ status: +
+ On Hold +
+
+
+ + + status:... + + + + + + + + + + + +
+
+
+ Projects +
+
+
+ + + Projects + + + + + + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_project_management_issue_types.drawio.svg b/docs/platform_management_plan/_assets/score_project_management_issue_types.drawio.svg new file mode 100644 index 00000000000..9d090eafb6c --- /dev/null +++ b/docs/platform_management_plan/_assets/score_project_management_issue_types.drawio.svg @@ -0,0 +1,375 @@ + + + + + + + + + + +
+
+
+ Team Repository +
+
+
+ + + Team Repository + + + + + + + + + + + +
+
+
+ Root Repository +
+
+
+ + + Root Repository + + + + + + + + + + + + + + + +
+
+
+ Product Increment +
+
+
+ + + Product Increment + + + + + + + + + + + +
+
+
+ Epic +
+
+
+ + + Epic + + + + + + + + + + + + + + + +
+
+
+ Task +
+
+
+ + + Task + + + + + + + + + + + + + + + +
+
+
+ Feature Request +
+
+
+ + + Feature Request + + + + + + + + + + + + + + + +
+
+
+ Task +
+
+
+ + + Task + + + + + + + + + + + +
+
+
+ Bug +
+
+
+ + + Bug + + + + + + + + + + + + +
+
+
+ ARC +
+
+
+ + + A... + + + + + + + + + + + + +
+
+
+ TLC +
+
+
+ + + T... + + + + + + + + + + + + +
+
+
+ Team +
+
+
+ + + T... + + + + + + + + + + + + +
+
+
+ Team +
+
+
+ + + T... + + + + + + + + + + + + +
+
+
+ Team +
+
+
+ + + T... + + + + + + + + + + + + +
+
+
+ Team +
+
+
+ + + T... + + + + + + + + + + + +
+
+
+ Parent +
+
+
+ + + Parent + + + + + + + + + + + +
+
+
+ Child +
+
+
+ + + Child + + + + + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_project_management_kanban.drawio.svg b/docs/platform_management_plan/_assets/score_project_management_kanban.drawio.svg new file mode 100644 index 00000000000..f936e3b36bd --- /dev/null +++ b/docs/platform_management_plan/_assets/score_project_management_kanban.drawio.svg @@ -0,0 +1,268 @@ + + + + + + + + + + + + + + + + + + + + + +
+
+
+ Backlog +
+
+
+ + + Backlog + + + + + + + + + + + + +
+
+
+ Ready +
+
+
+ + + Ready + + + + + + + + + + + + +
+
+
+ In Progress +
+
+
+ + + In Progress + + + + + + + + + + + + +
+
+
+ Done +
+
+
+ + + Done + + + + + + + + + + + + +
+
+
+ On Hold +
+
+
+ + + On Hold + + + + + + + + + + + + + +
+
+
+ + Newly created + +
+
+
+ + + Newly created + + + + + + + + + + + + +
+
+
+ Ready to be picked up (DoR) +
+
+
+ + + Ready to be picked up (DoR) + + + + + + + + + + + + +
+
+
+ Work in Progress +
+
+
+ + + Work in Progress + + + + + + + + + + + + +
+
+
+ Work is Done (DoD) +
+
+
+ + + Work is Done (DoD) + + + + + + + + + + + + +
+
+
+ Work is Paused +
+
+
+ + + Work is Paused + + + + + + + + + + + + +
+
+
+ Standard Kanban View +
+
+
+ + + Standard Kanban... + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_project_management_organization_orgchart.drawio.svg b/docs/platform_management_plan/_assets/score_project_management_organization_orgchart.drawio.svg new file mode 100644 index 00000000000..966078c3348 --- /dev/null +++ b/docs/platform_management_plan/_assets/score_project_management_organization_orgchart.drawio.svg @@ -0,0 +1,736 @@ + + + + + + + + + + + + + + + + + + + +
+
+
+ Feature Team: BAS +
+
+
+ + + Feature Team: BAS + + + + + + + + + + + +
+
+
+ Feature Team: COM +
+
+
+ + + Feature Team: COM + + + + + + + + + + + +
+
+
+ Feature Team: CFG +
+
+
+ + + Feature Team: CFG + + + + + + + + + + + +
+
+
+ Feature Team: FEO +
+
+
+ + + Feature Team: FEO + + + + + + + + + + + +
+
+
+ Feature Team: KYR +
+
+
+ + + Feature Team: KYR + + + + + + + + + + + +
+
+
+ Feature Team: ... +
+
+
+ + + Feature Team: ... + + + + + + + + + + + +
+
+
+ Feature Team: PER +
+
+
+ + + Feature Team: PER + + + + + + + + + + + +
+
+
+ Community: Process +
+
+
+ + + Community: Process + + + + + + + + + + + +
+
+
+ Steering: Project / Tech Lead Circle +
+
+
+ + + Steering: Project / Tech Lead Circle + + + + + + + + + + + +
+
+
+ Project Management +
+
+
+ + + Project Management + + + + + + + + + + + +
+
+
+ Security Management +
+
+
+ + + Security Management + + + + + + + + + + + +
+
+
+ Quality Management +
+
+
+ + + Quality Management + + + + + + + + + + + +
+
+
+ Safey Management +
+
+
+ + + Safey Management + + + + + + + + + + + +
+
+
+ Community: Marketing and Communication +
+
+
+ + + Community: Marketing and Communication + + + + + + + + + + + +
+
+
+ Community Integration and Release +
+
+
+ + + Community Integration and Release + + + + + + + + + + + +
+
+
+ External Communication +
+
+
+ + + External Communication + + + + + + + + + + + +
+
+
+ Release Management +
+
+
+ + + Release Management + + + + + + + + + + + +
+
+
+ Community: Architecture +
+
+
+ + + Community: Architecture + + + + + + + + + + + +
+
+
+ Community: Infrastructure +
+
+
+ + + Community: Infrastructure + + + + + + + + + + + +
+
+
+ Change Management +
+
+
+ + + Change Management + + + + + + + + + + + +
+
+
+ Software Verification +
+
+
+ + + Software Verification + + + + + + + + + + + +
+
+
+ Software Development +
+
+
+ + + Software Development + + + + + + + + + + + +
+
+
+ Community: Testing +
+
+
+ + + Community: Testing + + + + + + + + + + + +
+
+
+ Problem Resolution +
+
+
+ + + Problem Resolution + + + + + + + + + + + +
+
+
+ Tool Management +
+
+
+ + + Tool Management + + + + + + + + + + + +
+
+
+ Config Mangement +
+
+
+ + + Config Mangement + + + + + + + + + + + +
+
+
+ Feature Development +
+
+
+ + + Feature Development + + + + + + + + + + + +
+
+
+ Docu Management +
+
+
+ + + Docu Management + + + + + + + + + + + +
+
+
+ Internal Communication +
+
+
+ + + Internal Communication + + + + + + + + + + + +
+
+
+ Cross functional Community +
+
+
+ + + Cross functional Community + + + + + + + + + + + +
+
+
+ Steering Committee +
+
+
+ + + Steering Committee + + + + + + + + + + + +
+
+
+ Legend +
+
+
+ + + Legend + + + + + + + + + + + +
+
+
+ Development Team +
+
+
+ + + Development Team + + + + + + + + + + + +
+
+
+ Process Area +
+
+
+ + + Process Area + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/_assets/score_project_management_planning_overview.drawio.svg b/docs/platform_management_plan/_assets/score_project_management_planning_overview.drawio.svg new file mode 100644 index 00000000000..4eba9c3dc96 --- /dev/null +++ b/docs/platform_management_plan/_assets/score_project_management_planning_overview.drawio.svg @@ -0,0 +1,358 @@ + + + + + + + + + + + +
+
+
+
+ + + REPOSITORY: + + MAIN-TEAM-REPO + +
+
+ + OWNERSHIP: + + TEAM +
+
+ + GITHUB-PROJECT: + + TEAM-Specific +
+
+
+
+ + + REPOSITORY: MAIN-TEAM-REPO... + + + + + + + + + + + + +
+
+
+
+ + + REPOSITORY: + + S-CORE ROOT + +
+
+ + OWNERSHIP: + + TLC +
+
+ + GITHUB-PROJECT: + + S-CORE Roadmap +
+
+
+
+ + + REPOSITORY: S-CORE ROOT... + + + + + + + + + + + +
+
+
+ Product Increment +
+
+
+ + + Product Increment + + + + + + + + + + + + +
+
+
+
+ + + REPOSITORY: + + S-CORE ROOT + +
+
+ + OWNERSHIP: + + ARC +
+
+ + GITHUB-PROJECT: + + Feature Requests +
+
+
+
+ + + REPOSITORY: S-CORE ROOT... + + + + + + + + + + + +
+
+
+ Feature Request +
+
+
+ + + Feature Request + + + + + + + + + + + + +
+
+
+
+ + + REPOSITORY: + + MAIN-TEAM-REPO + +
+
+ + OWNERSHIP: + + TEAM +
+
+ + GITHUB-PROJECT: + + TEAM-Specific +
+
+
+
+ + + REPOSITORY: MAIN-TEAM-REPO... + + + + + + + + + + + +
+
+
+ Epic +
+
+
+ + + Epic + + + + + + + + + + + + +
+
+
+ 1 Parent : n Children +
+
+
+ + + 1 Parent : n Children + + + + + + + + + + + +
+
+
+ Task +
+
+
+ + + Task + + + + + + + + + + + + + + + +
+
+
+ Bug +
+
+
+ + + Bug + + + + + + + + + + + + + + + +
+
+
+ Task +
+
+
+ + + Task + + + + + + + + + + + +
+
+
+ Task +
+
+
+ + + Task + + + + + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/platform_management_plan/project_management.rst b/docs/platform_management_plan/project_management.rst index 1f0cb7b1eaa..456f2a38301 100644 --- a/docs/platform_management_plan/project_management.rst +++ b/docs/platform_management_plan/project_management.rst @@ -20,496 +20,865 @@ :realizes: wp__project_mgt :tags: platform_management -Project management plan -####################### +.. _pmp_pm_plan: -Project organization -==================== +Project Management Plan +----------------------- + +Purpose ++++++++ +The purpose of the Project Management Plan is to define + +- how to manage, analyse and control changes of the work products during the project life cycle. +- the project stakeholder and how to communicate with them. +- how and where to create and maintain the project schedule. +- how to track planned work. +- how and where to escalate. + +Objectives and Scope +++++++++++++++++++++ + +Project Management Goals and Definition of Done +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* The stakeholders/stakeholder groups and organization are defined: + - :ref:`Org Chart and structure description ` is available and up to date. +* Communication and reporting paths are described: + - Team Overview with meeting structure is available & Slack channels are established and maintained. + - Meetings are scheduled in the Eclipse SDV calendar. +* The scope of the work is defined. + - S-CORE Handbook (:need:`doc__platform_handbook`) is available and up to date. + - :ref:`Features ` are described. +* Project Plan is planned and followed: + - Roadmap with :ref:`Milestones ` and :ref:`Releases ` are available and up to date. + - S-CORE Handbook (:need:`doc__platform_handbook`) is available and up to date. + - :ref:`Features ` are described. +* Escalation paths are described. +* All Reviews are performed according to their definitions, the respective templates are used. + +.. _pmp_pm_organization: + +Project Organization +++++++++++++++++++++ + + +Org Chart and Main Platform Management Plan Responsibilities +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. image:: _assets/score_project_management_organization_orgchart.drawio.svg + :width: 900 + :alt: Infrastructure overview + :align: center .. _pmp_pm_steering_committees: -Steering committees -------------------- -Steering of the project is done by two committees: *project lead circle* and *technical lead circle*. +Steering Committees +^^^^^^^^^^^^^^^^^^^ +Steering of the project is done with the help of *Committees*. + +.. _PLCMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-PLC-team +.. _PLCSPK: https://github.com/orgs/eclipse-score/teams/automotive-score-PLC-lead +.. _PLCMM: https://github.com/eclipse-score/score/wiki/PLCM +.. _PLCSLC: https://sdvworkinggroup.slack.com/archives/PLC +.. _PLCBKL: https://github.com/orgs/eclipse-score/projects/PLC + +.. _TLCMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-TLC-team +.. _TLCSPK: https://github.com/orgs/eclipse-score/teams/automotive-score-TLC-lead +.. _TLCMM: https://github.com/eclipse-score/score/wiki/TLCM +.. _TLCSLC: https://sdvworkinggroup.slack.com/archives/C085F44D2CS +.. _TLCBKL: https://github.com/orgs/eclipse-score/projects/3 + +.. list-table:: Steering + :header-rows: 1 + :widths: 22,7,7,7,7,7,24 + + * - Purpose + - Members + - Speaker + - Meeting Minutes + - Slack Channel + - Backlog + - Owned Repository + * - .. _pmp_pm_plc: + + **PLC** + - **Project** + - **Lead** + - **Circle** + - **-----------** + - **-----------** + - **-----------------------** + + * - - Decisions about strategical topics + - Review and approval of contributions, e.g. Feature Requests, which add or modify features + - Project Management + - Planning and Approval of Releases + - Escalation instance + - `PLCMBRS`_ + - `PLCSPK`_ + - `PLCMM`_ + - `PLCSLC`_ + - `PLCBKL`_ + - n.a. + * - .. _pmp_pm_tlc: + + **TLC** + - **Technical** + - **Lead** + - **Circle** + - **-----------** + - **-----------** + - **-----------------------** + * - - Review and approval of contributions, e.g. Feature Requests, which add or modify S-CORE 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. + - `TLCMBRS`_ + - `TLCSPK`_ + - `TLCMM`_ + - `TLCSLC`_ + - `TLCBKL`_ + - - https://github.com/eclipse-score/score + +.. _pmp_pm_communities: + +Communities +^^^^^^^^^^^ +*Communities* are installed to work on cross functional topics, such as program level architectural decisions, +commonly used development & testing infrastructure, processes or final integration & release. +Each *Community* has a *Community Lead* to organize the community`s work. + +.. _ARCMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-ARC-team +.. _ARCLD: https://github.com/orgs/eclipse-score/teams/automotive-score-ARC-lead +.. _ARCMM: https://github.com/eclipse-score/score/wiki/ARCM +.. _ARCSLC: https://sdvworkinggroup.slack.com/archives/C08C1HG5AKY +.. _ARCBKL: https://github.com/orgs/eclipse-score/projects/3 + +.. _INFMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-INF-team +.. _INFLD: https://github.com/orgs/eclipse-score/teams/automotive-score-INF-lead +.. _INFMM: https://github.com/eclipse-score/score/wiki/INFM +.. _INFSLC: https://sdvworkinggroup.slack.com/archives/C0894QGRZDM +.. _INFBKL: https://github.com/orgs/eclipse-score/projects/6 + +.. _PRCMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-PRC-team +.. _PRCLD: https://github.com/orgs/eclipse-score/teams/automotive-score-PRC-lead +.. _PRCMM: https://github.com/eclipse-score/score/wiki/PRCM +.. _PRCSLC: https://sdvworkinggroup.slack.com/archives/C0864L05332 +.. _PRCBKL: https://github.com/orgs/eclipse-score/projects/21 +.. _PIMBKL: https://github.com/orgs/eclipse-score/projects/7 + +.. _TSTMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-TST-team +.. _TSTLD: https://github.com/orgs/eclipse-score/teams/automotive-score-TST-lead +.. _TSTMM: https://github.com/eclipse-score/score/wiki/TSTM +.. _TSTSLC: https://sdvworkinggroup.slack.com/archives/TSTC08B6C78EF3 +.. _TSTBKL: https://github.com/orgs/eclipse-score/projects/5 + +.. _INTMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-INT-team +.. _INTLD: https://github.com/orgs/eclipse-score/teams/automotive-score-INT-lead +.. _INTMM: https://github.com/eclipse-score/score/wiki/INTM +.. _INTSLC: https://sdvworkinggroup.slack.com/archives/INT +.. _INTBKL: https://github.com/orgs/eclipse-score/projects/INT + +.. _MCMMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-MCM-team +.. _MCMLD: https://github.com/orgs/eclipse-score/teams/automotive-score-MCM-lead +.. _MCMMM: https://github.com/eclipse-score/score/wiki/MCMM +.. _MCMSLC: https://sdvworkinggroup.slack.com/archives/C032X75QGTT +.. _MCMBKL: https://github.com/orgs/eclipse-score/projects/11 + + +.. list-table:: Community + :header-rows: 1 + :widths: 22,7,7,7,7,7,24 + + * - Purpose + - Members + - Lead + - Meeting Minutes + - Slack Channel + - Backlog + - Owned Repository + * - .. _pmp_pm_arc: + + **ARC** + - **Architecture** + - **Community** + - **-----------** + - **-----------** + - **-----------** + - **-----------------------** + * - - clarification of software architecture topics, e.g. discussion of new features or coding guidelines + - `ARCMBRS`_ + - `ARCLD`_ + - `ARCMM`_ + - `ARCSLC`_ + - `ARCBKL`_ + - https://github.com/eclipse-score/score + * - .. _pmp_pm_prc: + + **PRC** + - **Process** + - **Community** + - **-----------** + - **-----------** + - **-----------** + - **-----------------------** + * - - defining and maintaining the software development process (incl. safety, security and quality) + - defining and maintaining the process implementation (PIM) + - `PRCMBRS`_ + - `PRCLD`_ + - `PRCMM`_ + - `PRCSLC`_ + - `PRCBKL`_ + `PIMBKL`_ + - | https://github.com/eclipse-score/process_description + | https://github.com/eclipse-score/score + * - .. _pmp_pm_inf: + + **INF** + - **Infrastructure** + - **Community** + - **-----------** + - **-----------** + - **-----------** + - **-----------------------** + * - - providing and maintaining the development infrastructure: Compiler, IDE, build toolchains + - `INFMBRS`_ + - `INFLD`_ + - `INFMM`_ + - `INFSLC`_ + - `INFBKL`_ + - | Toolchain Repositories: + + | https://github.com/eclipse-score/bazel_platforms + | https://github.com/eclipse-score/toolchains_gcc + | https://github.com/eclipse-score/toolchains_gcc_packages + | https://github.com/eclipse-score/toolchains_qnx + | https://github.com/eclipse-score/toolchains_rust + + | Tooling Repositories: + + | https://github.com/eclipse-score/devcontainer + | https://github.com/eclipse-score/docs-as-code + | https://github.com/eclipse-score/tooling + + | other Repositories: + + | https://github.com/eclipse-score/apt-install + | https://github.com/eclipse-score/cicd-workflows + | https://github.com/eclipse-score/bazel_registry + | https://github.com/eclipse-score/bazel_registry_ui + | https://github.com/eclipse-score/.eclipsefdn + | https://github.com/eclipse-score/examples + + * - .. _pmp_pm_tst: + + **TST** + - **Testing** + - **Community** + - **-----------** + - **-----------** + - **-----------** + - **-----------------------** + * - defining and maintaining testing strategy and infrastructure + - `TSTMBRS`_ + - `TSTLD`_ + - `TSTMM`_ + - `TSTSLC`_ + - `TSTBKL`_ + - | https://github.com/eclipse-score/itf + | https://github.com/eclipse-score/testing_tools + * - .. _pmp_pm_int: + + **INT** + - **Integration &** + - **Release** + - **Community** + - **-----------** + - **-----------** + - **-----------------------** + * - - integration of available modules to one or several reference integrations + - releasing + + - `INTMBRS`_ + - `INTLD`_ + - `INTMM`_ + - `INTSLC`_ + - `INTBKL`_ + - | https://github.com/eclipse-score/score + * - .. _pmp_pm_mcm: + + **MCM** + - **Integration &** + - **Release** + - **Community** + - **-----------** + - **-----------** + - **-----------------------** + * - - coordination of public relations, e.g. the maintenance of the website & organization of general events + - `MCMMBRS`_ + - `MCMLD`_ + - `MCMMM`_ + - `MCMSLC`_ + - `MCMBKL`_ + - | https://github.com/eclipse-score/eclipse-score.github.io + | https://github.com/eclipse-score/eclipse-score-website + | https://github.com/eclipse-score/eclipse-score-website-preview + | https://github.com/eclipse-score/eclipse-score-website-published + +.. _pmp_pm_feature_teams: + +Feature Teams +^^^^^^^^^^^^^ +*Feature Teams* have end-to-end responsibility for providing specific functionalities. This includes all +development aspects beginning with the architecture definition to the integration test. +One *Team* may work independently of other *Teams* on the team-assigned *GitHub Issues*, +and needs at least one :need:`Committer ` who can approve & merge the Pull Requests +Each *Feature Team* has one *Lead* to organize the Team`s work. + +.. _BASMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-BAS-team +.. _BASLD: https://github.com/orgs/eclipse-score/teams/automotive-score-BAS-lead +.. _BASMM: https://github.com/eclipse-score/score/wiki/BASM +.. _BASSLC: https://sdvworkinggroup.slack.com/archives/C090UKSL5L2 +.. _BASBKL: https://github.com/orgs/eclipse-score/projects/24 + +.. _COMMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-COM-team +.. _COMLD: https://github.com/orgs/eclipse-score/teams/automotive-score-COM-lead +.. _COMMM: https://github.com/eclipse-score/score/wiki/COMM +.. _COMSLC: https://sdvworkinggroup.slack.com/archives/C08C0JATADP +.. _COMBKL: https://github.com/orgs/eclipse-score/projects/19 + +.. _CFGMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-CFG-team +.. _CFGLD: https://github.com/orgs/eclipse-score/teams/automotive-score-CFG-lead +.. _CFGMM: https://github.com/eclipse-score/score/wiki/CFGM +.. _CFGSLC: https://sdvworkinggroup.slack.com/archives/CFG +.. _CFGBKL: https://github.com/orgs/eclipse-score/projects/CFG + +.. _FEOMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-FEO-team +.. _FEOLD: https://github.com/orgs/eclipse-score/teams/automotive-score-FEO-lead +.. _FEOMM: https://github.com/eclipse-score/score/wiki/FEOM +.. _FEOSLC: https://sdvworkinggroup.slack.com/archives/FEO +.. _FEOBKL: https://github.com/orgs/eclipse-score/projects/9 + +.. _KYRMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-KYR-team +.. _KYRLD: https://github.com/orgs/eclipse-score/teams/automotive-score-KYR-lead +.. _KYRMM: https://github.com/eclipse-score/score/wiki/KYRM +.. _KYRSLC: https://sdvworkinggroup.slack.com/archives/KYR +.. _KYRBKL: https://github.com/orgs/eclipse-score/projects/38 + +.. _LCMMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-LCM-team +.. _LCMLD: https://github.com/orgs/eclipse-score/teams/automotive-score-LCM-lead +.. _LCMMM: https://github.com/eclipse-score/score/wiki/LCMM +.. _LCMSLC: https://sdvworkinggroup.slack.com/archives/C094Z3BN1K4 +.. _LCMBKL: https://github.com/orgs/eclipse-score/projects/33 + +.. _LOGMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-LOG-team +.. _LOGLD: https://github.com/orgs/eclipse-score/teams/automotive-score-LOG-lead +.. _LOGMM: https://github.com/eclipse-score/score/wiki/LOGM +.. _LOGSLC: https://sdvworkinggroup.slack.com/archives/C089XP2PGQZ +.. _LOGBKL: https://github.com/orgs/eclipse-score/projects/31 + +.. _ORCMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-ORC-team +.. _ORCLD: https://github.com/orgs/eclipse-score/teams/automotive-score-ORC-lead +.. _ORCMM: https://github.com/eclipse-score/score/wiki/ORCM +.. _ORCSLC: https://sdvworkinggroup.slack.com/archives/C099W80FU2C +.. _ORCBKL: https://github.com/orgs/eclipse-score/projects/29 + +.. _PERMBRS: https://github.com/orgs/eclipse-score/teams/automotive-score-PER-team +.. _PERLD: https://github.com/orgs/eclipse-score/teams/automotive-score-PER-lead +.. _PERMM: https://github.com/eclipse-score/score/wiki/PERM +.. _PERSLC: https://sdvworkinggroup.slack.com/archives/C08B339ETQU +.. _PERBKL: https://github.com/orgs/eclipse-score/projects/20 + +.. list-table:: Feature Teams + :header-rows: 1 + :widths: 22,7,7,7,7,7,24 + + * - Purpose + - Members + - Lead + - Meeting Minutes + - Slack Channel + - Backlog + - Owned Repository + * - .. _pmp_pm_bas: + + **BAS** + - **Baselibs** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of the base libraries + - `BASMBRS`_ + - `BASLD`_ + - `BASMM`_ + - `BASSLC`_ + - `BASBKL`_ + - | https://github.com/eclipse-score/baselibs + | https://github.com/eclipse-score/baselibs_rust + * - .. _pmp_pm_com: + + **COM** + - **Communication** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of the communication and protocols + - `COMMBRS`_ + - `COMLD`_ + - `COMMM`_ + - `COMSLC`_ + - `COMBKL`_ + - | https://github.com/eclipse-score/communication + | https://github.com/eclipse-score/inc_mw_com + | https://github.com/eclipse-score/inc_someip_gateway + * - .. _pmp_pm_cfg: + + **CFG** + - **Configuration** + - **Management** + - **Feature** + - **Team** + - **-----------** + - **-----------------------** + * - - development of configuration management + - `CFGMBRS`_ + - `CFGLD`_ + - `CFGMM`_ + - `CFGSLC`_ + - `CFGBKL`_ + - | https://github.com/eclipse-score/config_management + | https://github.com/eclipse-score/inc_config_management + * - .. _pmp_pm_feo: + + **FEO** + - **Fixed** + - **Execution** + - **Order** + - **Feature** + - **Team** + - **-----------------------** + * - - development of fixed execution order + - `FEOMBRS`_ + - `FEOLD`_ + - `FEOMM`_ + - `FEOSLC`_ + - `FEOBKL`_ + - | https://github.com/eclipse-score/feo + | https://github.com/eclipse-score/inc_feo + * - .. _pmp_pm_kyr: + + **KYR** + - **Kyron** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of Kyron + - `KYRMBRS`_ + - `KYRLD`_ + - `KYRMM`_ + - `KYRSLC`_ + - `KYRBKL`_ + - | https://github.com/eclipse-score/kyron + * - .. _pmp_pm_log: + + **LOG** + - **Logging** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of Logging + - `LOGMBRS`_ + - `LOGLD`_ + - `LOGMM`_ + - `LOGSLC`_ + - `LOGBKL`_ + - | https://github.com/eclipse-score/logging + | https://github.com/eclipse-score/inc_mw_log + + * - .. _pmp_pm_lcm: + + **LCM** + - **Lifecycle** + - **Management &** + - **Health Monitoring** + - **Feature** + - **Team** + - **-----------------------** + * - - development of Lifecycle Management and Health Monitoring + - `LCMMBRS`_ + - `LCMLD`_ + - `LCMMM`_ + - `LCMSLC`_ + - `LCMBKL`_ + - | https://github.com/eclipse-score/lifecycle + + * - .. _pmp_pm_ocr: + + **OCR** + - **Orchestrator** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of Orchestrator + - `ORCMBRS`_ + - `ORCLD`_ + - `ORCMM`_ + - `ORCSLC`_ + - `ORCBKL`_ + - | https://github.com/eclipse-score/orchestrator + + * - .. _pmp_pm_per: + + **PER** + - **Persistency** + - **Feature** + - **Team** + - **-----------** + - **-----------** + - **-----------------------** + * - - development of Persistency + - `PERMBRS`_ + - `PERLD`_ + - `PERMM`_ + - `PERSLC`_ + - `PERBKL`_ + - | https://github.com/eclipse-score/persistency + +Organization Management +^^^^^^^^^^^^^^^^^^^^^^^ +Decision to adapt the *Project Organization* is done in the *Technical Lead Circle* / *Project Management Circle*, documented in the meeting minutes and planned with a *Task*: + +- creating of a new Team (*Community* or *Feature Team*) +- setting an existing Team (*Community* or *Feature Team*) on hold +- deleting an existing Team (*Community* or *Feature Team*) + +Creation of a new Feature Team +"""""""""""""""""""""""""""""" +In case a new Feature Team creation is necessary, the following steps have to be done: + +- `Adding a new Team to GitHub Teams `_ and adding the Core Members by editing + `orgs.newTeam `_. +- Adding a new Repository to GitHub by editing + `orgs.newRepo `_. +- Definition of Repository specific :ref:`CODEOWNERS `. +- `Creation of a Team GitHub Project `_ with a Kanban View and a Task View. +- `Creation of a Team Meeting Wiki `_ for the meeting minutes +- Creation of a Team Label -* **Project lead circle** +.. code:: - Members of *Project lead circle* are the project leads of the *S-CORE* project. The election of project leads is done as described in the `Project Roles chapter `_ of *Eclipse Foundation Project Handbook*. In case of absence, a project lead can nominate a deputy. + committee:, + community: or + ft: - The main tasks of the *Project lead circle* are: +- Creation of a Slack Channel: https://sdvworkinggroup.slack.com +- Adapting the PMP - * Definition, discussion of and decisions about strategical topics (e.g. which associations to approach, confirmation of roadmap, representation in public). - * Decision on which new software modules should be added or removed from the project. The decision is done based on proposal from the *Technical lead circle*. In case of changes to the existing modules and no concordant decision in the *Technical Lead Circle*, the *Project Lead Circle* has to decide about the change. - * Election of Technical Leads. - * Last instance of escalation path. +External Communication +********************** +The external communication is done via GitHub, LinkedIn, etc. Publications by :ref:`Marketing and Communication Community `. - *Project lead circle* proposes and elects a *Project lead circle Assistant* and their deputy with bare majority, who is responsible for scheduling and announcing meetings, preparing and announcing agenda, writing meeting minutes and protocols. *Project lead circle* can reelect *Project lead circle Assistant* at any time. The *Project lead circle Assistant* and their deputy can resign anytime on their own will. -* **Technical lead circle** +Internal Communication +++++++++++++++++++++++ +The project internal communication is ensured with help of: - 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: +- virtual and face-to-face meetings and their minutes +- *GitHub issues* and *GitHub pull requests* +- online communication using Slack - * Review and approval of contributions, e.g. *Feature Requests*, which add or modify S-CORE 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. +Meetings +^^^^^^^^ +All meetings are scheduled in the `Eclipse S-CORE Calendar `_ , are open for everyone +but mentioned team members are mandatory. Meeting minutes are public and stored in the project specific *GitHub Team Wikis*. - *Technical lead circle* proposes and elects a *Technical lead circle Assistant* and their deputy with bare majority during *Technical Lead Circle meeting*, who is responsible for scheduling and announcing meetings, preparing and announcing agenda, writing meeting minutes and protocols. *Technical lead circle* can reelect *Technical lead circle Assistant* at any time. The *Technical lead circle Assistant* and their deputy can resign anytime on their own will. -.. _pmp_pm_technical_committees: +.. _pmp_pm_repository_structure: -Technical committees --------------------- -* **Communities** +Repository structure +++++++++++++++++++++ +The Platform follows a multiple repositories approach. The root repository is - *Communities* allow committers and contributors to exchange their - opinions, take architectural decisions and implement the topics of some special - technical domain, e.g. testing tooling. One of the *Communities*' important activities - is to do a breakdown of platform sagas to the concrete tasks (see `Planning`_) . - Currently following *Communities* are defined in the *S-CORE* project: +.. _pmp_pm_root_repository: - * *Infrastructure*: *community* for all kind of infra topics: - compiler, IDE, build toolchain and etc. See `GitHub Discussions/Infrastructure Community `_ for more. - * *Testing*: *community* to clarify questions and define testing strategy - for the 'S-CORE' project. See `GitHub Discussions/Testing Community `_ for more. - * *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. - * *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. - * *Marketing & Communication (MarCom)*: *community* for coordination of public relations, e.g. the maintenance of the website & organization of general events. - See `GitHub Discussions/MarCom Community `_ for more. +https://github.com/eclipse-score. - 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*. +It contains among others: -* **Feature Teams** +- :ref:`stakeholder requirements ` +- documentation of all :ref:`platform features `, features flags, + feature requirements and architecture +- build system including *S-CORE* specific *macros* and *rules* +- integration rules for software modules. - *Feature Teams* have end-to-end responsibility for specific functionalities. This includes all - aspects beginning with the architecture definition to the integration test. They are usually assigned - to the *S-CORE* main integration project or to one particular software module. *Feature Teams* work - independently of each other on *GitHub Issues* in the assigned software module. - *Feature Teams* consist mainly 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*. +which are stored in the :ref:`Folder Structure of Platform Repository `. - Every *Feature Team* should have at least one committer who can approve and merge the Pull Requests of the Contributors. - Every *Feature Team* should also have a *Feature Team Lead*. The person with this role is responsible for - organizing the meetings, writing meeting protocols and representing the current status of the *Feature Team* - work in various management reporting or planning calls. *Feature Team Lead* is nominated by *Technical Leads* by election. - Normally, this is the owner of the original *Feature Request*. +Every software module has its own repository, that contains among others: +- multiple components +- their requirements +- architecture +- implementation +- tests -Creation of a new Feature Team -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Decision to create a new *Feature Team* is normally done in *Technical Lead Circle* in case a particular, -already *accepted* *Feature Request* can not be assigned to any of already existing *Feature Teams*. +within the following :ref:`Module Folder Structure `. + + +.. _pmp_pm_codeowners: + +Codeowners +^^^^^^^^^^ +While creating a new repository, :ref:`Technical Leads ` nominate initial `CODEOWNERS `_, +whose review is mandatory for merging PRs to the repository and who are at the end allowed to merge PRs to the repository. -As a first step, the decision to create a new Feature Team is recorded in the `Tech Lead Circle meeting minutes `_. -Afterwards a GitHub Issue is created in the `Technical Lead Circle LOP project `_ -using the special *Feature Team Creation* GitHub Issue template and is assigned to one of the Technical Leads. +Possible members are software developers, who -**ToDo**: create such a template. +- understand how the particular feature works or should work +- are the initial authors of the software -Usage of the special GitHub Issue template ensures, that all GitHub issues for creation of new *Feature -Teams* follow the same rules, e.g. that the title always has the same format or -that the description always contains the reasoning for the creation of a new *Feature Team*. +The Codeownership has to be regularly updated and changes have to be documented. -Additionally, the GitHub Issue created from the template includes a *DoD list*, which serves as a checklist -for the Technical Lead to ensure that all necessary activities and steps have been completed to establish a new *Feature Team*. -Its current *DoD list* is always documented in the template. The most important activities are: +Planning & Tracking ++++++++++++++++++++ -* **Creation of labels** +Cadence +^^^^^^^ - Every *Feature Team* should have its own label for filtering of GitHub Issues, PRs or discussions. +Iteration +""""""""" +The Project calendar is devided into iterations. Each iteration is two weeks long. -* **Creation of discussion** +Release Frequence +""""""""""""""""" +After every 3rd iteration, the work is baselined into a Release. - Every *Feature Team* should have its own discussion section in the `Feature Teams section `_ - of the main *S-CORE* project. -* **Adding a new Team to the main S-CORE GitHub project** +Planning & Tracking Infrastructure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The planning and tracking of the work is done inside **GitHub**. +GitHub **Issues** are used to document all necessary work packages. - Every *Feature Team* should be added as a further select option of the "Team" field - in the `main S-CORE project `_, so that *Technical Leads* - can assign tickets to the team and filter for the tickets of the new team. - Additionally, every team is free to create its own GitHub project, but then the team tickets should be still - visible in the main S-CORE project. +Issues +^^^^^^ +To organize the work :ref:`Github Types `, :ref:`GitHub Labels ` and +:ref:`GitHub Projects ` are used. +The Progress of the work is documented with help of the :ref:`Status of an Issue `. + + +.. _pmp_pm_issue_types: -* **Creation of repository** +Issues Types +"""""""""""" - Normally, every *Feature Team* should have a dedicated repository. Creation of new repository is done - be extending the `otterdog configuration file `_ - and creating a new PR, that has to be approved by the *Eclipse Project Security Team*. Creation of the - repository is the responsibility of the *Feature Team Lead*. +.. image:: _assets/score_project_management_issue_types.drawio.svg + :width: 900 + :alt: Issue Types + :align: center -* **Developer GitHub Team** +| - Every *Feature Team* should have a corresponding software developer GitHub team, e.g. *ipc_ft_dev*, that contains all - developers, that are actively participating in this *Feature Team*. This GitHub group can be used e.g. to - send notifications for upcoming meetings or discussions. +.. _pmp_pm_feature_request: -* **Codeowner GitHub Team** +**Feature Request** - Every *Feature Team* should have a corresponding codeowner GitHub team, e.g. *ipc_ft_co*, that contains all - software developers, whose review is mandatory for every PR in the repository and who have rights to merge PRs to the repository. +A *Feature Request* represents an independent work package used to describe and +track a high-level request for the project. *Feature Request* work packages can be linked to +other work packages, but they must not be treated as parent work packages. They are in the responsibility of the +:ref:`Architecture Community ` and are part of the :ref:`Root Repository `. +.. _pmp_pm_product_increment: -Merge rights & code ownership -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -As already stated, every *Feature Team* has normally a dedicated repository. Before the creation of the new repository, -*Feature Team Lead* together with *Technical Leads* should nominate initial codeowners, whose review is mandatory for merging PRs to the repository -and who is at the end allowed to merge PRs to the repository. +**Product Increment** -In the S-CORE project, the configuration whose review is mandatory to merge a PR to the repository is done -using `CODEOWNERS file and branch protection `_ . -Every repository has a CODEOWNERS file, where one or multiple teams are specified, whose review is needed for the PR -to be able to be merged. The teams listed there are normally: +A *Product Increment* represents the highest level in the work package hierarchy and +cannot be linked as a child of another issue. If you need to group multiple *Product Increment* work packages, +labels have to be used. +A *Product Increment* can have multiple *Epic* work packages as children. *Product Increments* areowned by +:ref:`Technical Lead Circle ` and are part of the :ref:`Root Repository `. -* *Codeowner GitHub Team* for this *Feature Team* -* GitHub Team for security managers -* GitHub Team for quality managers -* GitHub Team for safety managers +.. _pmp_pm_epic: -**ToDo**: can we have an 'AND relationship' for teams in CODEOWNERS file? +**Epic** -*Codeowner GitHub Team* for the corresponding *Feature Team* consists of the software developers, that understand how -the particular feature works or should work. The members of this team should be selected and agreed -during the creation of the *Feature Team* by the *Technical Leads* and *Feature Team Lead*. The criteria for the selection should be the -technical competence of the software developers, e.g. in case during the :ref:`Feature Request process ` -it was decided to take over already existing source code, then persons who were actively participating in the -development of that code are always good candidates to be part of *Codeowner GitHub team*. -The decision who should be initially part of the *Codeowner GitHub team* and the reasoning for this -should be recorded in the GitHub Issue, that is used for creation of the *Feature Team*. +An *Epic* is the primary planning work package for development teams. +*Epic* work packages should be scoped in a way that allows them to be completed within +a release cycle of the S-CORE project. +While an *Epic* can be implemented by multiple team members, it is recommended +that one developer takes main responsibility for its completion. Quality assurance activities, +such as code reviews, can be performed by other team members. +*Epics* are typically grouped under an *Product Increment*. However, an *Epic* work package can also exist +as a standalone work package if its outcome represents a complete functional improvement, +making a related *Product Increment* work package unnecessary. +Sometimes support of other teams might be necessary for the completion of the work, therefore an +*Epic* can have team-internal and team-external *Task* child issues. *Epics* are owned by a Team and are part +of the Team`s main repository. -In case further software developers should be added to the *Codeowner GitHub team* in the future, -that decision and its reasoning should be recorded in one of the *Feature Team* GitHub discussions. -Members of the *Codeowner GitHub team* should also be authorized to merge pull requests (PRs) into the corresponding repository. -Therefore, once the *Codeowner GitHub team* has been created, the Technical Lead assigned to the ticket for the *Feature -Team* setup should initiate committer elections for all software developers in the *Codeowner GitHub team*. -All other Technical Leads who are already committers in the S-CORE project are expected to support these -elections by voting positively, provided there are no specific objections. +.. _pmp_pm_task: -Meeting Structure ------------------ +**Task** -* **Project Lead Circle meeting** +A *Task GitHub Issue* represents the smallest unit of planning and typically corresponds +to a concrete piece of work to be completed, such as by a developer. *Task* work packages are usually +grouped under an *Epic* work package. +In certain cases, a *Task* may exist as a standalone *GitHub Issue*. +However, standalone *Task* work packages must not be grouped using labels. +If multiple *Task* work packages are related, a *Epic* work package should be created instead, +with all associated *Task* work packages added as child work packages under that *Epic*. *Tasks* are owned by a Team and are part +of any Team`s repository. - Regular participants of *Project Lead Circle meeting* are the *Project Leads* and *Technical Leads* of the main *S-CORE* project. The main purpose of the meeting is the exchange between *Project Leads* and the reporting of the *Technical Lead Circle* to the *Project Lead Circle* and vice versa. +.. _pmp_pm_bug: - The *Project Lead 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 `Project Lead Circle section `_ and can be read by everyone. Topics for the *Project lead circle meetings* can be proposed only by regular participants and will be prioritized by the *Project lead circle Assistant*. Proposals for agenda topics can be added as comment to the respective *GitHub Discussion* or sent to the *Project lead circle Assistant*. +**Bug** - Open points from the meetings will be handled by *GitHub Issues* in the *S-CORE* main repository and can be filtered via *project_lead_circle* label. +A *Bug GitHub Issue* is used to report any kind of problem or malfunction. It is considered +a special type of *Story* work package and follows the same rules as regular *Epic* work packages, +with the key difference that it focuses on fixing defects in existing functionality +rather than creating or extending functionality. *Tasks* are owned by a Team and are part +of any Team`s repository. - The *Project Lead Circle meeting* takes place usually once a week. +.. _pmp_pm_issue_status_flow: +Issue Status +"""""""""""" +Each *GitHub issue* has a **Status** depending on the :ref:`GitHub Project `, +we use the following Standard Flow for all :ref:`Issue Types `: -* **Technical Lead Circle meeting** +.. image:: _assets/score_project_management_issue_status_flow.drawio.svg + :width: 900 + :alt: Issue Status + :align: center - Regular participants of the *Technical Lead Circle meeting* are the *Technical Leads* of the main *S-CORE* project. The main purpose of the meeting is the exchange between technical leads for fulfilling their responsibilities. +Issue Attributes +"""""""""""""""" +- Standard Attributes + - Assignees + - :ref:`Labels ` + - :ref:`Type ` +- Common Project Attributes + - :ref:`Status ` + - Priority (1 - High, 2 - Middle, 3 - Low) + - Size (S - Day, M - Week, L - Month, XL - Quarter) + - (planned finishing) Iteration - The *Technical Lead 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 `Technical Lead Circle section `_ and can be read by everyone. Topics for the *Technical lead circle meetings* can be proposed only by regular participants and will be prioritized by the *Technical lead circle Assistant*. Proposals for agenda topics can be added as comment to the respective *GitHub Discussion* or sent to the *Technical lead circle Assistant*. - Open points from the meetings will be handled by *GitHub Issues* in the *S-CORE* main repository and can be filtered via label *technical_lead_circle*. - The *Technical Lead Circle meeting* takes place usually once a week. +Issue Templates +""""""""""""""" +Templates defined in *GitHub* ensure the availability of the type relevant information for all issues. -* **Committer Circle Meeting** +- `Bug Template `_ +- `Feature Request Template `_ +- `Product Increment Template `_ +- `Epic Template `_ +- `Task Template `_ - Regular participants of the *Committer Circle meeting* are the *Committers* of the main *S-CORE* 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. +Hierarchies +""""""""""" +Hierarchies are realized as parent-child relations with the `GitHub Sub-Issue Feature `_. - 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*. +Dependencies +"""""""""""" +Dependencies are realized with blocked by or blocking relations described in thè `GitHub Issue Dependency Feature `_. - The *Committer Circle meeting* takes place on demand. The decision for the scheduling of the *Committer Circle Meeting* is taken by the *Technical Lead Circle*. +.. _pmp_pm_milestone: -Platform structure -================== -Platform consists of multiple repositories. The main repository, *S-CORE*, -is the integration repository, where everything comes together. It contains: +Milestone +^^^^^^^^^ +A milestone is indicating an important dedicated point in the schedule like +a Release or a Quality (ASPICE, ASIL) Assessment. +`GitHub Milestones `_ offer to connect *Issues* and *Pull Requests* to the `S-CORE-defined Milestones `_ + +.. _pmp_pm_release: + +Releases +^^^^^^^^ +*Releases* are special milestones and used for baselining of the development activities. + + +.. _pmp_pm_gh_labels: -* :ref:`stakeholder requirements ` -* documentation of all :ref:`platform features ` and features flags, - feature requirements and architecture -* build system including *S-CORE* specific *macros* and *rules* -* integration rules for software modules. - -The main repository references multiple other repositories, mostly repositories, where -software modules or toolchains are defined. This results in the following :ref:`Folder Structure of Platform Repository `. Every software module has its own repository, that contains multiple components, their requirements, architecture, implementation and tests. -A software module and its repository can be part of the main S-CORE *Eclipse Project* and corresponding *GitHub organization* or can be moved to a standalone *Eclipse child project*, if necessary. - - .. image:: _assets/project_organization.svg - :width: 900 - :alt: Infrastructure overview - :align: center - -Platform organization -======================= -Also in case the software module repositories are not placed -in standalone *Eclipse child projects*, we still consider all software modules -to be standalone *Eclipse child projects*, having their own *Committers* and *Project Leads* -as defined by the *Eclipse Foundation Project Handbook*. Software module committers -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 *S-CORE* project mailing list, *score-dev@eclipse.org*. 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 *S-CORE* project respectively. The elected project leads or committers of the software modules are not automatically project leads and committers of the main integration *S-CORE* project. Typically, before becoming a project lead or a committer of the main integration *S-CORE* project, you need to build up a good reputation by contributing to the main integration *S-CORE* project and being project lead or committer for one of the software modules. - -Before introducing a new *Eclipse child project* for a software module, it should first reside as a repository in the main *S-CORE* 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 *S-CORE* 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 *S-CORE* project, the configuration and the control -of who is committer and project lead is done using -`CODEOWNER files `_ -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 S-CORE 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 *S-CORE* 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 *S-CORE* project as the central project is, as already -described, to ensure proper integration of multiple software modules, provide common -integration guidelines and mechanisms, e.g. build toolchain. Additionally *S-CORE* 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 -meetings, where such topics are discussed and decided, see `Steering committees`_ for further details. - -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 *S-CORE* 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 *S-CORE* 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 work packages and structure ------------------------------------- -For better structuring of the tickets following *GitHub Issue* types are introduced -in the main *S-CORE* repository. In order to create a consistent overview of all work packages (WPs), -the WPs need to be maintained in one single project within the main *S-CORE* repository. -Having separate WP backlogs within separate repositories will increase the complexity -and reduce the transparency too much. - -All *child projects* are only allowed to have their separate list of issues. All other WP types -shall not be available for them. The planning WPs of the main *S-CORE* repository therefore are used -to link WPs to *GitHub issues* of *child projects*. -For example a *Bug* WP within the main repository is linked to a *GitHub Issue* of the *communication* -repository but no *Bug* WP shall be created in the *child project* repository. - -.. image:: _assets/issue_types.png - :width: 600 - :alt: Issue types overview - :align: center +`GitHub Labels `_ are used to organize Issues, Pull Requests etc. having same context. Although +Labels are powerful, the definition of new Labels shall be wisely done and organization wide used. +Therefore their management is limited to Organization owners. -* A *Task* *GitHub Issue* represents the smallest unit of planning and typically corresponds - to a concrete piece of work to be completed, such as by a developer. *Task* work packages are usually - grouped under a *Story* work package. - In certain cases, a *Task* may exist as a standalone *GitHub Issue*. - However, standalone *Task* work packages must not be grouped using labels. - If multiple *Task* work packages are related, a *Story* work package should be created instead, - with all associated *Task* work packages added as child work packages under that *Story*. - -* A *Story* *GitHub Issue* is the primary planning work package for development teams. - *Story* work packages should be scoped in a way that allows them to be completed within - the release cycle of the S-CORE project. - While a *Story* work package can be implemented by multiple team members, it is recommended - that one developer takes main responsibility for its completion. Quality assurance activities, - such as code reviews, should be performed by other team members. - *Story* work packages are typically grouped under an *Product Increment* work package. - However, a *Story* work package can also exist as a standalone work package if its outcome represents - a complete functional improvement, making a related *Product Increment* work package unnecessary. - -* A *Product Increment* *GitHub Issue* represents the highest level in the work package hierarchy and - cannot be linked as a child of another issue. If you need to group multiple *Product Increment* work packages, - this must be done using labels. - A *Product Increment* work package can have multiple *Story* work packages as child work packages. - In exceptional cases, a *Story* work package may also be linked as a child of a *Product Increment* work package - if its outcome represents a complete functional improvement. - -* A *Feature Request* *GitHub Issues* represents an independent work package used to describe and - track a high-level request for the project. *Feature Request* work packages can be linked to - other work packages, but they must not be treated as parent work packages. - -* A *Bug* *GitHub Issue* is used to report any kind of problem or malfunction. It is considered - a special type of *Story* work package and follows the same rules as regular *Story* work packages, - with the key difference that it focuses on fixing defects in existing functionality - rather than creating or extending functionality. - -Main *S-CORE* 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 +The following `Labels `_ are defined. -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 +.. _pmp_pm_gh_projects: 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 *S-CORE* 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 *S-CORE* repository defines project wide milestones & releases, - that are visible in the roadmap as well. - -.. image:: _assets/roadmap_example.png - :width: 600 - :alt: Roadmap example +The `GitHub Project Feature `_ +helps to plan the work and monitor its progress. + +Multiple *GitHub Projects* are defined at https://github.com/orgs/eclipse-score/projects/. + +Beside one for each (committee, community, feature) Team, there is one for `Feature Requests `_ +and one for the complete `S-CORE Roadmap `_. Inside a GitHub Project, there is the possibility to generate different views +for Table, Board and Roadmap supporting Backlogs, Open Point or Task Lists and other useful perspectives. + +.. image:: _assets/score_project_management_planning_overview.drawio.svg + :width: 900 + :alt: Planning Overview :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 *S-CORE* 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 *S-CORE* will be provided here later. +Kanban View +""""""""""" +The `GitHub Board `_ is supporting the Kanban View, enabling to set the Work In Progress Limits. -You can find "up to date" overview of the release plan and milestones in the following section `S-CORE Releases `_. +.. image:: _assets/score_project_management_kanban.drawio.svg + :width: 900 + :alt: Kanban View + :align: center -The users of the S-CORE platform need to adapt their planning to the milestones defined in the S-CORE project, -but they have always the possibility to takeover the development of a new feature, modifications and bugfixes -in their own development branch / fork and merge these improvements in the next or later releases -back into the S-CORE "main" line. -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 `_ . +Task List View +"""""""""""""" +The `GitHub Table `_ is supporting the List View, enabling to adapt the priority by reordering the rows. -Contribution to the project is described in more details in `Contribution 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. +Roadmap View +"""""""""""" +The `GitHub Roadmap `_ is supporting the Road View, provididing a high-level visualization of your project across a configurable timespan. -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. +Traceability +^^^^^^^^^^^^ +To achieve traceability all *Pull Requests* have to be `linked `_ +to the corresponding *GitHub Issues*. -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. +Planning of Work +^^^^^^^^^^^^^^^^ -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". +Generally, every team is responsible for planning its work within its own plan with the help of its :ref:`GitHub Project ` filled with :ref:`Epics `, :ref:`Tasks ` and :ref:`Bugs `. -.. image:: _assets/saga_status_workflow.svg - :width: 900 - :alt: Planning workflow - :align: center +The planning of :ref:`Feature Requests ` is in the responsibility of the :ref:`Architects `, +whereas the overall top-down plan is in the responsibility of the :ref:`Technical Lead Circle ` with the help of :ref:`Product Increments `, +:ref:`Milestones ` and :ref:`Releases `. + +Tracking Progress +^^^^^^^^^^^^^^^^^ +The :ref:`Technical Lead Circle ` regularly monitors the status of the work for upcoming Milestones and Releases in https://github.com/orgs/eclipse-score/projects/17/ based on +:ref:`Product Increments `. + + +Dashboards +"""""""""" + +GitHub offers mechanism in form of charts to track issues: -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 feature 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 S-CORE 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 *S-CORE* 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". +- `Product Increments Open last 3 months `_