-
Notifications
You must be signed in to change notification settings - Fork 22
update of change management to consider new FEP proposal #748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
02ee2bc
f1042b7
5984b2b
9c26b5e
85b9428
1b515a0
8410d82
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,7 +22,7 @@ | |
| .. document:: [Your Feature Name] | ||
| :id: doc__feature_name | ||
| :status: draft | ||
| :version: 1 | ||
| :version: 2 | ||
| :safety: ASIL_B | ||
| :security: YES | ||
| :realizes: wp__feat_request[version==1] | ||
|
|
@@ -77,16 +77,6 @@ Motivation | |
| Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc. | ||
| CRs submissions without sufficient motivation may be rejected. | ||
|
|
||
| Rationale | ||
| ========= | ||
|
|
||
| [Describe why particular design decisions were made.] | ||
|
|
||
| .. note:: | ||
| The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. | ||
| For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used. | ||
|
|
||
|
|
||
| Specification | ||
| ============= | ||
|
|
||
|
|
@@ -97,61 +87,6 @@ Specification | |
| A CR shall specify the stakeholder requirements as part of our platform/project. | ||
| Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR). | ||
|
|
||
| Backwards Compatibility | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we consider this somewhere?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is part now of Impact Analysis Template |
||
| ======================= | ||
|
|
||
| [Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.] | ||
|
|
||
|
|
||
| Security Impact | ||
| =============== | ||
|
|
||
| [How could a malicious user take advantage of this new/modified feature?] | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this content moved somewhere or do we not need it any more? Maybe in the Impact Analysis Template?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is part now of Impact Analysis Template |
||
|
|
||
| .. note:: | ||
| If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. | ||
|
|
||
| Which security requirements are affected or has to be changed? | ||
| Could the new/modified feature enable new threat scenarios? | ||
| Could the new/modified feature enable new attack paths? | ||
| Could the new/modified feature impact functional safety? | ||
| If applicable, which additional security measures must be implemented to mitigate the risk? | ||
|
|
||
| .. note:: | ||
| Use Trust Boundary, Defense in Depth Analysis and/or Security Software Critically Analysis, | ||
| Vulnerability Analysis. | ||
| [Methods will be defined later in Process area Security Analysis] | ||
| These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively. | ||
|
|
||
| Safety Impact | ||
| ============= | ||
|
|
||
| [How could the safety be impacted by the new/modified feature?] | ||
|
|
||
| .. note:: | ||
| If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. | ||
| Link here to the filled out :need:`Impact Analysis Template <gd_temp__change_impact_analysis>` or copy the template in this chapter. | ||
|
|
||
| Which safety requirements are affected or has to be changed? | ||
| Could the new/modified feature be a potential common cause or cascading failure initiator? | ||
| If applicable, which additional safety measures must be implemented to mitigate the risk? | ||
|
|
||
| .. note:: | ||
| Use Dependency Failure Analysis and/or Safety Software Critically Analysis. | ||
| [Methods will be defined later in Process area Safety Analysis] | ||
| These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively. | ||
|
|
||
| For new feature contributions: | ||
|
|
||
| [What is the expected ASIL level?] | ||
|
|
||
|
|
||
| License Impact | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we consider this somewhere?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is part now of Impact Analysis Template |
||
| ============== | ||
|
|
||
| [How could the copyright impacted by the license of the new contribution?] | ||
|
|
||
|
|
||
| How to Teach This | ||
| ================= | ||
|
|
||
|
|
@@ -160,28 +95,6 @@ How to Teach This | |
| .. note:: | ||
| For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. | ||
|
|
||
|
|
||
| Rejected Ideas | ||
| ============== | ||
|
|
||
| [Why certain ideas that were brought while discussing this CR were not ultimately pursued.] | ||
|
|
||
| .. note:: | ||
| Throughout the discussion of a CR, various ideas will be proposed which are not accepted. | ||
| Those rejected ideas should be recorded along with the reasoning as to why they were rejected. | ||
| This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions. | ||
| In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued. | ||
|
|
||
| Open Issues | ||
| =========== | ||
|
|
||
| [Any points that are still being decided/discussed.] | ||
|
|
||
| .. note:: | ||
| While a CR is in draft, ideas can come up which warrant further discussion. | ||
| Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. | ||
| This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion. | ||
|
|
||
| Footnotes | ||
| ========= | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,7 +18,7 @@ Concept Description | |
| .. doc_concept:: Concept Description | ||
| :id: doc_concept__change_process | ||
| :status: valid | ||
| :version: 1 | ||
| :version: 2 | ||
| :tags: change_management | ||
|
|
||
| In this section a concept for the Change Management will be discussed. Inputs for this concepts | ||
|
|
@@ -33,6 +33,10 @@ As features are built-up by components a Change Request is also needed to add ne | |
| components or to modify the scope of existing components. | ||
| All statements here for components are also valid for *SW Modules*. | ||
|
|
||
| As a rule of thumb, a Change Request is needed, if feature or component requirements | ||
| are changed in a way that also will cause version update | ||
| (compare :ref:`significant_requirement_changes`). | ||
|
|
||
| Inputs | ||
| ****** | ||
|
|
||
|
|
@@ -95,12 +99,15 @@ Activities for a Change Request | |
|
|
||
| Creation of the Change Request | ||
| ============================== | ||
| Use the content :ref:`Feature Request Template <chm_feature_templates>` or | ||
| :ref:`Component Request Template <chm_component_templates>` to create a Change Request. | ||
|
|
||
| Use the content :ref:`Decision Record Template <decision_record_template>` to create a | ||
| Change Request. | ||
|
Comment on lines
+103
to
+104
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not every change should/must end up in a decision record. I tried to also document this in the CMP in score. The DR/FEP path should be only for "bigger"/"major" changes - because this path also takes a lot more time to find agreement. We should still have a shorter path for smaller changes that don't need that level of alignment. Can we somehow separate the information that has to be available in a change request from the format? That way we could then define in the CMP in score that major changes persist this information in a DR via the FEP and that smaller changes can still move forward if this information is only available in a issue without needing a prior DR?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently https://github.com/eclipse-score/.github/blob/24c3501a931460f1d89123a3ea21750c414e7f22/.github/ISSUE_TEMPLATE/1a_FeatureRequest.yml defines which work products are affected by Change Request, "Scope" changes, otherwise, just fill out a normal taks, w/o Change Management, using https://github.com/eclipse-score/.github/blob/24c3501a931460f1d89123a3ea21750c414e7f22/.github/ISSUE_TEMPLATE/4_Task.yml |
||
|
|
||
| In case safety or security is affected, in addition the impact analysis template | ||
| : :ref:`Impact Analysis Template <chm_impact_analysis_templates>` can be used to detail | ||
| out the impact on safety/security. | ||
| out the impact on platform, or any other aspect including especially safety/security. | ||
| The template can be referenced in the decision record or copied into the decision record | ||
| and filled out there. | ||
|
|
||
| The impact analysis tool (:need:`gd_req__change_tool_impact_analysis`) can support to | ||
| here to identify the affected work products. | ||
|
|
@@ -131,6 +138,12 @@ monitored. | |
|
|
||
| The Change Request implementation must be tracked until it is closed. | ||
|
|
||
| Use the content :ref:`Feature Request Template <chm_feature_templates>` or | ||
| :ref:`Component Request Template <chm_component_templates>` to document the creation | ||
| of a new feature or component. In case of modification of an existing feature or | ||
| component, the same templates (which should be already existing) can be used to | ||
| document the modification. | ||
|
|
||
| The status of the Change Request must be communicated by the | ||
| :need:`Project Lead <rl__project_lead>` (for feature requests) and the lead of the | ||
| :need:`Delivery Team <rl__delivery_team>` (for component requests) until | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.