Skip to content

Commit 41d7085

Browse files
nnshah1nnshah1
authored
Dynamo Enhancement Process (#1)
Signed-off-by: Neelay Shah <[email protected]>
1 parent f27a1ca commit 41d7085

File tree

4 files changed

+618
-0
lines changed

4 files changed

+618
-0
lines changed

‎NNNN-complete-template.md‎

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
# <Title>
2+
3+
**Status**: Draft | Under Review | Approved | Replaced | Deferred | Rejected
4+
5+
**Authors**: [Name/Team]
6+
7+
**Category**: Architecture | Process | Guidelines
8+
9+
**Replaces**: [Link of previous proposal if applicable]
10+
11+
**Replaced By**: [Link of previous proposal if applicable]
12+
13+
**Sponsor**: [Name of code owner or maintainer to shepard process]
14+
15+
**Required Reviewers**: [Names of technical leads that are required for acceptance]
16+
17+
**Review Date**: [Date for review]
18+
19+
**Pull Request**: [Link to Pull Request of the Proposal itself]
20+
21+
**Implementation PR / Tracking Issue**: [Link to Pull Request or Tracking Issue for Implementation]
22+
23+
# Summary
24+
25+
**\[Required\]**
26+
27+
# Motivation
28+
29+
**\[Required\]**
30+
31+
Describe the problem that needs to be addressed with enough detail for
32+
someone familiar with the project to understand. Generally one to two
33+
short paragraphs. Additional details can be placed in the background
34+
section as needed. Cover **what** the issue is and **why** it needs to
35+
be addressed. Link to github issues if relevant.
36+
37+
## Goals
38+
39+
**\[Optional \- if not applicable omit\]**
40+
41+
List out any additional goals in bullet points. Goals may be aspirational / difficult to measure but guide the proposal.
42+
43+
* Goal
44+
45+
* Goal
46+
47+
* Goal
48+
49+
### Non Goals
50+
51+
**\[Optional \- if not applicable omit\]**
52+
53+
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.
54+
55+
## Requirements
56+
57+
**\[Optional \- if not applicable omit\]**
58+
59+
List out any additional requirements in numbered subheadings.
60+
61+
**\<numbered subheadings\>**
62+
63+
### REQ \<\#\> \<Title\>
64+
65+
Describe the requirement in as much detail as necessary for others to understand it and how it applies to the DEP. Keep in mind that requirements should be measurable and will be used to determine if a DEP has been successfully implemented or not.
66+
67+
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.
68+
69+
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.
70+
71+
72+
# Proposal
73+
74+
**\[Required\]**
75+
76+
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.
77+
78+
# Implementation Details
79+
80+
**\[Optional \- if not applicable omit\]**
81+
82+
Add additional detailed items here including interface signatures, etc. Add anything that is relevant but seems more of a detail than central to the proposal. Use sub sections / bullet points as needed. Try to provide images and diagrams to facilitate understanding. If applicable link to PR.
83+
84+
## Deferred to Implementation
85+
86+
**\[Optional \- if not applicable omit\]**
87+
88+
List out items that are under discussion but that will be resolved only during implementation / code review.
89+
90+
# Implementation Phases
91+
92+
**\[Optional \- if not applicable omit\]**
93+
94+
List out phases of implementation (can be single phase). Give each phase a monotonically increasing number; example “Phase 0” followed by “Phase 1” and so on. Give phases titles if it makes sense.
95+
96+
## Phase \<\#\> \<Optional Title\>
97+
98+
**Release Target**: Date
99+
100+
**Effort Estimate**: \<estimate of time and number of engineers to complete the phase\>
101+
102+
**Work Item(s):** \<one or more links to github issues\>
103+
104+
**Supported API / Behavior:**
105+
106+
* \<name and concise description of the API / behavior\>
107+
108+
**Not Supported:**
109+
110+
* \<name and concise description of the API / behavior\>
111+
112+
# Related Proposals
113+
114+
**\[Optional \- if not applicable omit\]**
115+
116+
* File
117+
118+
* File
119+
120+
* File
121+
122+
* File
123+
124+
* File
125+
126+
# Alternate Solutions
127+
128+
**\[Required, if not applicable write N/A\]**
129+
130+
List out solutions that were considered but ultimately rejected. Consider free form \- but a possible format shown below.
131+
132+
## Alt \<\#\> \<Title\>
133+
134+
**Pros:**
135+
136+
\<bulleted list or pros describing the positive aspects of this solution\>
137+
138+
**Cons:**
139+
140+
\<bulleted list or pros describing the negative aspects of this solution\>
141+
142+
**Reason Rejected:**
143+
144+
\<bulleted list or pros describing why this option was not used\>
145+
146+
**Notes:**
147+
148+
\<optional: additional comments about this solution\>
149+
150+
# Background
151+
152+
**\[Optional \- if not applicable omit\]**
153+
154+
Add additional context and references as needed to help reviewers and authors understand the context of the problem and solution being proposed.
155+
156+
## References
157+
158+
**\[Optional \- if not applicable omit\]**
159+
160+
Add additional references as needed to help reviewers and authors understand the context of the problem and solution being proposed.
161+
162+
* \<hyper-linked title of an external reference resource\>
163+
164+
## Terminology & Definitions
165+
166+
**\[Optional \- if not applicable omit\]**
167+
168+
List out additional terms / definitions (lexicon). Try to keep definitions as concise as possible and use links to external resources when additional information would be useful to the reader.
169+
170+
Keep the list of terms sorted alphabetically to ease looking up definitions by readers.
171+
172+
| \<Term\> | \<Definition\> |
173+
| :---- | :---- |
174+
| **\<Term\>** | \<Definition\> |
175+
176+
## Acronyms & Abbreviations
177+
178+
**\[Optional \- if not applicable omit\]**
179+
180+
Provide a list of frequently used acronyms and abbreviations which are uncommon or unlikely to be known by the reader. Do not include acronyms or abbreviations which the reader is likely to be familiar with.
181+
182+
Keep the list of acronyms and abbreviations sorted alphabetically to ease looking up definitions by readers.
183+
184+
Do not include the full definition in the expanded meaning of an abbreviation or acronym. If the reader needs the definition, please include it in the [Terminology & Definitions](#terminology--definitions) section.
185+
186+
**\<Acronym/Abbreviation\>:** \<Expanded Meaning\>
187+

‎NNNN-limited-template.md‎

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# <Title>
2+
3+
**Status**: Draft | Under Review | Approved | Replaced | Deferred | Rejected
4+
5+
**Authors**: [Name/Team]
6+
7+
**Category**: Architecture | Process | Guidelines
8+
9+
**Replaces**: [Link of previous proposal if applicable]
10+
11+
**Replaced By**: [Link of previous proposal if applicable]
12+
13+
**Sponsor**: [Name of code owner or maintainer to shepard process]
14+
15+
**Required Reviewers**: [Names of technical leads that are required for acceptance]
16+
17+
**Review Date**: [Date for review]
18+
19+
**Pull Request**: [Link to Pull Request of the Proposal itself]
20+
21+
**Implementation PR / Tracking Issue**: [Link to Pull Request or Tracking Issue for Implementation]
22+
23+
# Summary
24+
25+
**\[Required\]**
26+
27+
# Motivation
28+
29+
**\[Required\]**
30+
31+
Describe the problem that needs to be addressed with enough detail for
32+
someone familiar with the project to understand. Generally one to two
33+
short paragraphs. Additional details can be placed in the background
34+
section as needed. Cover **what** the issue is and **why** it needs to
35+
be addressed. Link to github issues if relevant.
36+
37+
## Goals
38+
39+
**\[Optional \- if not applicable omit\]**
40+
41+
List out any additional goals in bullet points. Goals may be aspirational / difficult to measure but guide the proposal.
42+
43+
* Goal
44+
45+
* Goal
46+
47+
* Goal
48+
49+
### Non Goals
50+
51+
**\[Optional \- if not applicable omit\]**
52+
53+
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.
54+
55+
## Requirements
56+
57+
**\[Optional \- if not applicable omit\]**
58+
59+
List out any additional requirements in numbered subheadings.
60+
61+
**\<numbered subheadings\>**
62+
63+
### REQ \<\#\> \<Title\>
64+
65+
Describe the requirement in as much detail as necessary for others to understand it and how it applies to the DEP. Keep in mind that requirements should be measurable and will be used to determine if a DEP has been successfully implemented or not.
66+
67+
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.
68+
69+
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.
70+
71+
72+
# Proposal
73+
74+
**\[Required\]**
75+
76+
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.
77+
78+
# Alternate Solutions
79+
80+
**\[Required, if not applicable write N/A\]**
81+
82+
List out solutions that were considered but ultimately rejected. Consider free form \- but a possible format shown below.
83+
84+
## Alt \<\#\> \<Title\>
85+
86+
**Pros:**
87+
88+
\<bulleted list or pros describing the positive aspects of this solution\>
89+
90+
**Cons:**
91+
92+
\<bulleted list or pros describing the negative aspects of this solution\>
93+
94+
**Reason Rejected:**
95+
96+
\<bulleted list or pros describing why this option was not used\>
97+
98+
**Notes:**
99+
100+
\<optional: additional comments about this solution\>
101+

‎README.md‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,23 @@
11
# Dynamo Enhancement Proposals
2+
23
Enhancement Proposals and Architecture Decisions
4+
5+
6+
Please see [0000-dep-process](deps/0000-dep-process.md) for full
7+
explanation and details.
8+
9+
## Authoring Guidelines
10+
11+
1. Start with either the
12+
[NNNN-complete-template.md](NNNN-complete-template.md) and remove
13+
unneeded sections or the
14+
[NNNN-limited-template.md](NNNN-limited-template.md) and then add
15+
selectively from the complete template based on need.
16+
17+
2. Identify a `code-owner` or `maintainer` of the DEP repository to
18+
shepard the process.
19+
20+
3. Create a draft PR and iterate with co-authors, Sponser
21+
22+
4. When ready for review, mark as ready and work with Sponser to set a
23+
review date.

0 commit comments

Comments
 (0)