[Your Feature Name]

Note

Document header

[Your Feature Name]		status: draft security: YES safety: ASIL_B
tags: template, feature_name version: 2 realizes: wp__feat_request
doc__feature_name		Generic Document

Attention

The above directive must be updated according to your Feature.

• Modify document 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 safety, security and tags according to your needs

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

[Provide the feature and a brief summary of the feature]

.. feat:: Feature Name
   :id: feat__feature_name
   :security: YES
   :safety: ASIL_B
   :status: invalid
   :version: 1
   :includes: logic_arc_int__feature_name__interface_name1

   General Feature Description

[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 CR solves.]

Note

The motivation is critical for CRs 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 CR solves. Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc. CRs submissions without sufficient motivation may be rejected.

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 CR shall specify the stakeholder requirements as part of our platform/project. Thereby the Project Lead will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR).

How to Teach This

[How to teach users, new and experienced, how to apply the CR to their work.]

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.

Footnotes

[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]