Skip to content

update component request template to consider new FEP proposal #112

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.

Sign up for GitHub

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

Open
masc2023 wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −77
Open

update component request template to consider new FEP proposal #112

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 1 addition & 77 deletions score/component_example/docs/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,76 +52,12 @@ Abstract
[A short (~200 word) description of the component.]


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
=============

[Describe the requirements, architecture of any component.] or


Backwards Compatibility
=======================

[Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.]


Security Impact
===============

[How could a malicious user take advantage of this new/modified component?]

.. 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 component enable new threat scenarios?
Could the new/modified component enable new attack paths?
Could the new/modified component impact functional safety?
If applicable, which additional security measures must be implemented to mitigate the risk?

.. note::
Use Security Software Critically Analysis, Vulnerability Analysis.
[Methods will be defined later in Process area Security Analysis]


Safety Impact
=============

[How could the safety be impacted by the new/modified component?]

.. 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.

Which safety requirements are affected or has to be changed?
Could the new/modified component 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]

For new feature/component contributions:

[What is the expected ASIL level?]
[What is the expected classification of the contribution?]

.. note::
Use the component classification method here to classify your component, if it shall to be used in a safety context: :need:`gd_temp__component_classification`.

License Impact
==============

[How could the copyright impacted by the license of the new contribution?]


How to Teach This
=================

Expand All @@ -130,6 +66,7 @@ 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
==============

Expand All @@ -142,19 +79,6 @@ Rejected Ideas
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
=========

Expand Down
Loading