From d4f8aeed2d6a71ba2ae7f7bca65f90d620538ead Mon Sep 17 00:00:00 2001 From: Anton Krivoborodov Date: Tue, 10 Dec 2024 09:44:06 +0100 Subject: [PATCH] process: fix further review findings Issue-ref: resolves #21 --- .../project_management.rst | 10 +++---- docs/process/guidelines/general/index.rst | 30 +++++++++---------- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/platform_management_plan/project_management.rst b/docs/platform_management_plan/project_management.rst index b453053..6109a0d 100644 --- a/docs/platform_management_plan/project_management.rst +++ b/docs/platform_management_plan/project_management.rst @@ -96,7 +96,7 @@ Technical committees *Cross functional teams* are responsible for some piece 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. + (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. @@ -120,17 +120,17 @@ Meeting Structure Regular participants of the *Technical Lead Circle meeting* are the *Technical Leads* of the main *SCORE* project. The main purpose of the meeting is the exchange between technical leads for fulfilling their responsibilities. - 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*. + 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 *SCORE* main repository and can be filtered via label *technical_lead_circle*. + Open points from the meetings will be handled by *GitHub Issues* in the *SCORE* main repository and can be filtered via label *technical_lead_circle*. The *Technical Lead Circle meeting* takes place usually once a week. * **Committer Circle Meeting** - Regular participants of the *Committer Circle meeting* are the *Committers* of the main *SCORE* project and of all software modules/child projects. The *Committer Circle Meeting* is lead by the *Technical Leads*. The main purpose of the meeting are in-depth technical discussions and evaluation of the *Contribution Requests*. + Regular participants of the *Committer Circle meeting* are the *Committers* of the main *SCORE* project and of all software modules/child projects. The *Committer Circle Meeting* is lead by the *Technical Leads*. The main purpose of the meeting are in-depth technical discussions and evaluation of the *Contribution Requests*, that could not be approved in the *Technical Lead Circle meeting* and demand more technical discussions. - The *Committer Circle meetings* are announced via *score-dev@eclipse.org* mailing list and are open for everyone who is registered to this mailing list. All meetings are documented as GitHub Discussions in `Committer Circle section `_ and can be read by everyone. Topics for the *Committer circle meetings* can be proposed only by regular participants and will be prioritized by the *Technical lead circle*. Proposals for agenda topics can be added as comment to the respective GitHub discussion or sent to the *Technical lead circle Assistant*. + 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*. 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*. diff --git a/docs/process/guidelines/general/index.rst b/docs/process/guidelines/general/index.rst index 41a5dd2..6e9abbf 100644 --- a/docs/process/guidelines/general/index.rst +++ b/docs/process/guidelines/general/index.rst @@ -57,8 +57,8 @@ can be in a different order. software_development.rst -> ... Development [WP_SW_DEV_PLAN]. software_verification.rst -> ... Verification [WP_VERIFICATION_PLAN]. documentation_management.rst -> ... Documentation Management. - release/ -> [WP_PLATFORM SW_RELEASE_NOTE] - safety/ -> safety documentation on platform level (SEooC): [WP_SW_FEATURE_DFA], [WP_PLATFORM_SW_SAFETY_MANUAL], [WP_PLATFORM_SAFETY_CASE], [WP_CMR_REPORTS], [WP_ASSESSMENT_REPORT] + release/ -> [WP_PLATFORM_SW_RELEASE_NOTE] + safety/ -> safety documentation on platform level (SEooC): [WP_FEATURE_DFA], [WP_PLATFORM_SW_SAFETY_MANUAL], [WP_PLATFORM_SAFETY_CASE], [WP_CMR_REPORTS], [WP_ASSESSMENT_REPORT] stakeholder_requirements/ -> Stakeholder requirements of the platform [WP_STAKEHOLDER_REQ]. examples/ -> examples how a C++, Rust, Python module can be set up @@ -68,41 +68,41 @@ can be in a different order. docs/ -> Documentation of the feature consisting of ... architecture/ -> ... Feature architecture [WP_FEATURE_ARCHITECTURE]. requirements/ -> ... Feature requirements [WP_FEATURE_REQ]. - safety_analysis/ -> ... Safety analysis on feature level [WP_SW_FEAT_SAFETY_ANALYSES] + safety_analysis/ -> ... Safety analysis on feature level [WP_FEATURE_SAFETY_ANALYSES] safety_planning/ -> ... the feature specific safety workproducts planning - verification/ -> ... Feature verification report (reporting all feature verifications) [WP_SW_VERIFICATION_REPORT] + verification/ -> ... Feature verification report (reporting all feature verifications) [WP_PLATFORM_SW_VERIFICATION_REPORT] tests/ -> Feature tests, consisting of ... - integration-tests/ -> ... integration tests [WP_SW_INTEGRATION_TEST]. + integration-tests/ -> ... integration tests [WP_FEATURE_INTEGRATION_TEST]. toolchain/ -> Definition of toolchain incl. their requirements [WP_TOOL_REQ] modules/ -> Modules of the SW platform. / -> Folder containing all artifacts corresponding to one module. docs/ -> Documentation of the module consisting of ... - manual/ -> ... Module manual, e.g. integration manual, assumptions of use and safety manual [WP_SW_AOU], [WP_SW_SAFTEY_MANUAL]. - release/ -> ... Module release note [WP_PLATFORM SW_RELEASE_NOTE] plus safety assessment [WP_ASSESSMENT_REPORT] - safety_plan/ -> ... Module safety plan [WP_PLATFORM_SAFETY_PLAN], module safety case [WP_PLATFORM_SAFETY_CASE] and their conformance reviews [WP_CMR_REPORTS] - safety_analysis/ -> ... Safety analysis on module level [WP_SW_COMP_DFA] - verification/ -> ... Module verification report (reporting all module's components verifications) [WP_SW_VERIFICATION_REPORT] plus safety analysis conformance reviews [WP_CMR_REPORTS] + manual/ -> ... Module manual, e.g. integration manual, assumptions of use and safety manual [WP_SW_COMPONENT_AOU], [WP_MODULE_SW_SAFETY_MANUAL]. + release/ -> ... Module release note [WP_MODULE_SW_RELEASE_NOTE] plus safety assessment [WP_ASSESSMENT_REPORT] + safety_plan/ -> ... Module safety plan [WP_MODULE_SAFETY_PLAN], module safety case [WP_MODULE_SAFETY_CASE] and their conformance reviews [WP_CMR_REPORTS] + safety_analysis/ -> ... Safety analysis on module level [WP_SW_COMPONENT_DFA] + verification/ -> ... Module verification report (reporting all module's components verifications) [WP_MODULE_SW_VERIFICATION_REPORT] plus safety analysis conformance reviews [WP_CMR_REPORTS] components/ -> Components of the module. / -> Folder containing all artifacts corresponding to one component. docs/ -> Documentation of the component consisting of ... - architecture/ -> ... Component architecture (only if sub-components exist) [WP_SW_COMPONENTS_ARCHITECTURE]. - requirements/ -> ... Component requirements [WP_SW_COMP_REQ] and HSI (if relevant) [WP_HSI]. - safety_analysis/ -> ... Safety analysis on component level [WP_SW_COMP_SAFETY_ANALYSES] + architecture/ -> ... Component architecture (only if sub-components exist) [WP_SW_COMPONENT_ARCHITECTURE]. + requirements/ -> ... Component requirements [WP_SW_COMPONENT_REQ] and HSI (if relevant) [WP_HSI]. + safety_analysis/ -> ... Safety analysis on component level [WP_SW_COMPONENT_SAFETY_ANALYSES] verification/ -> ... Architecture review [WP_SW_ARCH_VERIFICATION], code inspection [WP_SW_CODE_INSPECT] src/ -> Source files of the component (incl. detailed design) [WP_SW_IMPLEMENTATION]. include/ -> Include files of the component tests/ -> Component tests, consisting of ... unit_tests/ -> ... unit tests [WP_SW_UNIT_TEST] (for lowest level of components). - integration_tests/ -> ... integration tests [WP_SW_INTEGRATION_TEST]. + integration_tests/ -> ... integration tests [WP_SW_COMPONENT_INTEGRATION_TEST]. verification-tests/ -> ... verification tests [WP_SW_COMPONENT_TEST]. / -> Sub-Component of the Component. copy the relevant folders below if applicable (example: no code inspection needed for sub-components from the Open Source) platform-integration-tests/ -> Integration tests on reference hardware. - process/ -> process definition including workflows, workproducts, roles, guidance [WP_PROCESS_DEFINITION] + process -> process definition including workflows, workproducts, roles, guidance [WP_PROCESS_DEFINITION] registry/ -> infrastructure configuration