Skip to content

Commit 9e26193

Browse files
whoisjdzier
andauthored
feat: Triton Enhancement Proposals (#8517)
This change adds the concept of Triton Enhancement Proposals (TEP) to the server repository. This is derived from the Dynamo Enhancement Proposal (DEP) concept. Co-authored-by: David Zier <42390249+dzier@users.noreply.github.com>
1 parent 865432f commit 9e26193

4 files changed

Lines changed: 672 additions & 0 deletions

File tree

Lines changed: 229 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,229 @@
1+
<!--
2+
# Copyright (c) 2025-2026, NVIDIA CORPORATION. All rights reserved.
3+
#
4+
# Redistribution and use in source and binary forms, with or without
5+
# modification, are permitted provided that the following conditions
6+
# are met:
7+
# * Redistributions of source code must retain the above copyright
8+
# notice, this list of conditions and the following disclaimer.
9+
# * Redistributions in binary form must reproduce the above copyright
10+
# notice, this list of conditions and the following disclaimer in the
11+
# documentation and/or other materials provided with the distribution.
12+
# * Neither the name of NVIDIA CORPORATION nor the names of its
13+
# contributors may be used to endorse or promote products derived
14+
# from this software without specific prior written permission.
15+
#
16+
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY
17+
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18+
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
19+
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
20+
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
21+
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
22+
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
23+
# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
24+
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
25+
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
26+
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
27+
-->
28+
# \<Title\>
29+
30+
**Status**: \[Draft | Under Review | Approved | Replaced | Deferred | Rejected\]
31+
32+
**Authors**: \[Name/Team\]
33+
34+
**Category**: \[Architecture | Process | Guidelines\]
35+
36+
**Replaces**: \[Link of previous proposal if applicable\]
37+
38+
**Replaced By**: \[Link of previous proposal if applicable\]
39+
40+
**Sponsor**: \[Name of code owner or maintainer to shepherd process\]
41+
42+
**Required Reviewers**: \[Names of technical leads that are required for acceptance\]
43+
44+
**Review Date**: \[Date for review\]
45+
46+
**Pull Request**: \[Link to Pull Request of the Proposal itself\]
47+
48+
**Implementation PR / Tracking Issue**: \[Link to Pull Request or Tracking Issue for Implementation\]
49+
50+
## Summary
51+
52+
**\[Required\]**
53+
54+
## Motivation
55+
56+
**\[Required\]**
57+
58+
Describe the problem that needs to be addressed with enough detail for someone familiar with the project to understand.
59+
Generally one to two short paragraphs.
60+
Additional details can be placed in the background section as needed.
61+
Cover **what** the issue is and **why** it needs to be addressed.
62+
Link to github issues if relevant.
63+
64+
### Goals
65+
66+
**\[Optional \- if not applicable omit\]**
67+
68+
List out any additional goals in bullet points.
69+
Goals may be aspirational / difficult to measure but guide the proposal.
70+
71+
* Goal
72+
73+
* Goal
74+
75+
* Goal
76+
77+
### Non Goals
78+
79+
**\[Optional \- if not applicable omit\]**
80+
81+
List out any items which are out of scope / specifically not required in bullet points.
82+
Indicates the scope of the proposal and issue being resolved.
83+
84+
### Requirements
85+
86+
**\[Optional \- if not applicable omit\]**
87+
88+
List out any additional requirements in numbered subheadings.
89+
90+
**\<numbered subheadings\>**
91+
92+
#### REQ \<\#\> \<Title\>
93+
94+
Describe the requirement in as much detail as necessary for others to understand it and how it applies to the TEP.
95+
Keep in mind that requirements should be measurable and will be used to determine if a TEP has been successfully implemented or not.
96+
97+
Requirement names should be prefixed using a monotonically increasing number such as “REQ 1 \<Title\>” followed by “REQ 2 \<Title\>” and so on.
98+
Use title casing when naming requirements. Requirement names should be as descriptive as possible while remaining as terse as possible.
99+
100+
Use all-caps, bolded terms like **MUST** and **SHOULD** when describing each requirement.
101+
See \[RFC-2119\](https://datatracker.ietf.org/doc/html/rfc2119) for additional information.
102+
103+
## Proposal
104+
105+
**\[Required\]**
106+
107+
Describe the high level design / proposal.
108+
Use sub sections as needed, but start with an overview and then dig into the details.
109+
Try to provide images and diagrams to facilitate understanding.
110+
111+
## Implementation Details
112+
113+
**\[Optional \- if not applicable omit\]**
114+
115+
Add additional detailed items here including interface signatures, etc.
116+
Add anything that is relevant but seems more of a detail than central to the proposal.
117+
Use sub sections / bullet points as needed.
118+
Try to provide images and diagrams to facilitate understanding.
119+
If applicable link to PR.
120+
121+
### Deferred to Implementation
122+
123+
**\[Optional \- if not applicable omit\]**
124+
125+
List out items that are under discussion but that will be resolved only during implementation / code review.
126+
127+
## Implementation Phases
128+
129+
**\[Optional \- if not applicable omit\]**
130+
131+
List out phases of implementation (can be single phase).
132+
Give each phase a monotonically increasing number; example “Phase 0” followed by “Phase 1” and so on.
133+
Give phases titles if it makes sense.
134+
135+
### Phase \<\#\> \<Optional Title\>
136+
137+
**Release Target**: Date
138+
139+
**Effort Estimate**: \<estimate of time and number of engineers to complete the phase\>
140+
141+
**Work Item(s):** \<one or more links to github issues\>
142+
143+
**Supported API / Behavior:**
144+
145+
* \<name and concise description of the API / behavior\>
146+
147+
**Not Supported:**
148+
149+
* \<name and concise description of the API / behavior\>
150+
151+
## Related Proposals
152+
153+
**\[Optional \- if not applicable omit\]**
154+
155+
* File
156+
157+
* File
158+
159+
* File
160+
161+
* File
162+
163+
* File
164+
165+
## Alternate Solutions
166+
167+
**\[Required, if not applicable write N/A\]**
168+
169+
List out solutions that were considered but ultimately rejected.
170+
Consider free form `-`, but a possible format shown below.
171+
172+
### Alt \<\#\> \<Title\>
173+
174+
**Pros:**
175+
176+
\<bulleted list or pros describing the positive aspects of this solution\>
177+
178+
**Cons:**
179+
180+
\<bulleted list or pros describing the negative aspects of this solution\>
181+
182+
**Reason Rejected:**
183+
184+
\<bulleted list or pros describing why this option was not used\>
185+
186+
**Notes:**
187+
188+
\<optional: additional comments about this solution\>
189+
190+
## Background
191+
192+
**\[Optional \- if not applicable omit\]**
193+
194+
Add additional context and references as needed to help reviewers and authors understand the context of the problem and solution being proposed.
195+
196+
## References
197+
198+
**\[Optional \- if not applicable omit\]**
199+
200+
Add additional references as needed to help reviewers and authors understand the context of the problem and solution being proposed.
201+
202+
* \<hyper-linked title of an external reference resource\>
203+
204+
## Terminology & Definitions
205+
206+
**\[Optional \- if not applicable omit\]**
207+
208+
List out additional terms / definitions (lexicon).
209+
Try to keep definitions as concise as possible and use links to external resources when additional information would be useful to the reader.
210+
211+
Keep the list of terms sorted alphabetically to ease looking up definitions by readers.
212+
213+
| \<Term\> | \<Definition\> |
214+
| :---- | :---- |
215+
| **\<Term\>** | \<Definition\> |
216+
217+
## Acronyms & Abbreviations
218+
219+
**\[Optional \- if not applicable omit\]**
220+
221+
Provide a list of frequently used acronyms and abbreviations which are uncommon or unlikely to be known by the reader.
222+
Do not include acronyms or abbreviations which the reader is likely to be familiar with.
223+
224+
Keep the list of acronyms and abbreviations sorted alphabetically to ease looking up definitions by readers.
225+
226+
Do not include the full definition in the expanded meaning of an abbreviation or acronym.
227+
If the reader needs the definition, please include it in the \[Terminology & Definitions\](#terminology--definitions) section.
228+
229+
**\<Acronym/Abbreviation\>:** \<Expanded Meaning\>
Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
<!--
2+
# Copyright (c) 2025-2026, NVIDIA CORPORATION. All rights reserved.
3+
#
4+
# Redistribution and use in source and binary forms, with or without
5+
# modification, are permitted provided that the following conditions
6+
# are met:
7+
# * Redistributions of source code must retain the above copyright
8+
# notice, this list of conditions and the following disclaimer.
9+
# * Redistributions in binary form must reproduce the above copyright
10+
# notice, this list of conditions and the following disclaimer in the
11+
# documentation and/or other materials provided with the distribution.
12+
# * Neither the name of NVIDIA CORPORATION nor the names of its
13+
# contributors may be used to endorse or promote products derived
14+
# from this software without specific prior written permission.
15+
#
16+
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY
17+
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18+
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
19+
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
20+
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
21+
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
22+
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
23+
# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
24+
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
25+
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
26+
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
27+
-->
28+
# \<Title\>
29+
30+
**Status**: \[Draft | Under Review | Approved | Replaced | Deferred | Rejected\]
31+
32+
**Authors**: \[Name/Team\]
33+
34+
**Category**: \[Architecture | Process | Guidelines\]
35+
36+
**Replaces**: \[Link of previous proposal if applicable\]
37+
38+
**Replaced By**: \[Link of previous proposal if applicable\]
39+
40+
**Sponsor**: \[Name of code owner or maintainer to shepherd process\]
41+
42+
**Required Reviewers**: \[Names of technical leads that are required for acceptance\]
43+
44+
**Review Date**: \[Date for review\]
45+
46+
**Pull Request**: \[Link to Pull Request of the Proposal itself\]
47+
48+
**Implementation PR / Tracking Issue**: \[Link to Pull Request or Tracking Issue for Implementation\]
49+
50+
## Summary
51+
52+
**\[Required\]**
53+
54+
## Motivation
55+
56+
**\[Required\]**
57+
58+
Describe the problem that needs to be addressed with enough detail for someone familiar with the project to understand.
59+
Generally one to two short paragraphs.
60+
Additional details can be placed in the background section as needed. Cover **what** the issue is and **why** it needs to be addressed.
61+
Link to github issues if relevant.
62+
63+
### Goals
64+
65+
**\[Optional \- if not applicable omit\]**
66+
67+
List out any additional goals in bullet points.
68+
Goals may be aspirational / difficult to measure but guide the proposal.
69+
70+
* Goal
71+
72+
* Goal
73+
74+
* Goal
75+
76+
#### Non Goals
77+
78+
**\[Optional \- if not applicable omit\]**
79+
80+
List out any items which are out of scope / specifically not required in bullet points.
81+
Indicates the scope of the proposal and issue being resolved.
82+
83+
### Requirements
84+
85+
**\[Optional \- if not applicable omit\]**
86+
87+
List out any additional requirements in numbered subheadings.
88+
89+
**\<numbered subheadings\>**
90+
91+
#### REQ \<\#\> \<Title\>
92+
93+
Describe the requirement in as much detail as necessary for others to understand it and how it applies to the TEP.
94+
Keep in mind that requirements should be measurable and will be used to determine if a TEP has been successfully implemented or not.
95+
96+
Requirement names should be prefixed using a monotonically increasing number such as “REQ 1 \<Title\>” followed by “REQ 2 \<Title\>” and so on.
97+
Use title casing when naming requirements.
98+
Requirement names should be as descriptive as possible while remaining as terse as possible.
99+
100+
Use all-caps, bolded terms like **MUST** and **SHOULD** when describing each requirement.
101+
See \[RFC-2119\](https://datatracker.ietf.org/doc/html/rfc2119) for additional information.
102+
103+
## Proposal
104+
105+
**\[Required\]**
106+
107+
Describe the high level design / proposal.
108+
Use sub sections as needed, but start with an overview and then dig into the details.
109+
Try to provide images and diagrams to facilitate understanding.
110+
111+
## Alternate Solutions
112+
113+
**\[Required, if not applicable write N/A\]**
114+
115+
List out solutions that were considered but ultimately rejected.
116+
Consider free form `-`, but a possible format shown below.
117+
118+
## Alt \<\#\> \<Title\>
119+
120+
**Pros:**
121+
122+
\<bulleted list or pros describing the positive aspects of this solution\>
123+
124+
**Cons:**
125+
126+
\<bulleted list or pros describing the negative aspects of this solution\>
127+
128+
**Reason Rejected:**
129+
130+
\<bulleted list or pros describing why this option was not used\>
131+
132+
**Notes:**
133+
134+
\<optional: additional comments about this solution\>

0 commit comments

Comments
 (0)