Feature Request Template#

Feature Request Template		status: valid security: safety:
status: valid tags: contribution_request

GD_TEMP__Feat_Request_Template		Process Template

Attention

Remove everything above when copying and filling the template.

[Your Feature Name]#

[Your Feature Name]		status: draft security: safety: ASIL_D
status: draft tags: contribution_request, feature_request safety: ASIL_D

DOC__Your_Feature_Name		Document

Attention

The above directive must be updated according to your Feature.

Modify name to be your Feature Name
Modify id to be your Feature Name in upper snake case preceded by DOC_
Adjust status to be valid
Adjust asil according to your needs
Extend tags according to your needs, but please keep two default tags there

Feature flag#

To activate this feature, use the following feature flag:

experimental_[your_feature_name]

Note

The feature flag must reflect the feature name in snake_case. Further, it is prepended with experimental_, as long as the feature is not yet stable.

Abstract#

[A short (~200 word) description of the contribution being addressed.]

Motivation#

[Clearly explain why the existing platform/project solution is inadequate to address the topic that the Feature Request solves.]

Note

The motivation is critical for Feature Requests that want to change the existing features or infrastructure. It should clearly explain why the existing solution is inadequate to address the topic that the Feature Request solves. Feature Request 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.

Specification#

[Describe the requirements, architecture of any new feature.] or [Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]

Note

A Feature Request shall specify the stakeholder requirements as part of our platform/project. Thereby the Technical Lead (RL_technical_lead) will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request).

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 feature?]

Note

If there are security concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.

Safety Impact#

[How could the safety be impacted by the new feature?]

Note

If there are safety concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them. ToDo - Link to the Safety Impact Method

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

Note

Use the component classification method here to classfiy your component, if it shall to be used in a safety context: (TODO: add link to component classification).

License Impact#

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