enhancements/NNNN-template-limited.md
Status: [Draft | Under Review | Approved | Replaced | Deferred | Rejected]
Authors: [Name/Team]
Category: [Architecture | Process | Guidelines]
Replaces: [Link of previous proposal if applicable]
Replaced By: [Link of previous proposal if applicable]
Sponsor: [Name of code owner or maintainer to shepherd process]
Required Reviewers: [Names of technical leads that are required for acceptance]
Review Date: [Date for review]
Pull Request: [Link to Pull Request of the Proposal itself]
Implementation PR / Tracking Issue: [Link to Pull Request or Tracking Issue for Implementation]
[Required]
[Required]
Describe the problem that needs to be addressed with enough detail for someone familiar with the project to understand. Generally one to two short paragraphs. Additional details can be placed in the background section as needed. Cover what the issue is and why it needs to be addressed. Link to github issues if relevant.
[Optional - if not applicable omit]
List out any additional goals in bullet points. Goals may be aspirational / difficult to measure but guide the proposal.
Goal
Goal
Goal
[Optional - if not applicable omit]
List out any items which are out of scope / specifically not required in bullet points. Indicates the scope of the proposal and issue being resolved.
[Optional - if not applicable omit]
List out any additional requirements in numbered subheadings.
<numbered subheadings>
Describe the requirement in as much detail as necessary for others to understand it and how it applies to the TEP. Keep in mind that requirements should be measurable and will be used to determine if a TEP has been successfully implemented or not.
Requirement names should be prefixed using a monotonically increasing number such as “REQ 1 <Title>” followed by “REQ 2 <Title>” and so on. Use title casing when naming requirements. Requirement names should be as descriptive as possible while remaining as terse as possible.
Use all-caps, bolded terms like MUST and SHOULD when describing each requirement. See [RFC-2119](https://datatracker.ietf.org/doc/html/rfc2119) for additional information.
[Required]
Describe the high level design / proposal. Use sub sections as needed, but start with an overview and then dig into the details. Try to provide images and diagrams to facilitate understanding.
[Required, if not applicable write N/A]
List out solutions that were considered but ultimately rejected.
Consider free form -, but a possible format shown below.
Pros:
<bulleted list or pros describing the positive aspects of this solution>
Cons:
<bulleted list or pros describing the negative aspects of this solution>
Reason Rejected:
<bulleted list or pros describing why this option was not used>
Notes:
<optional: additional comments about this solution>