|
| 1 | +name: Enhancement Proposal |
| 2 | +description: This is a template for submitting an enhancement proposal. |
| 3 | +title: "[Proposal]: " |
| 4 | +labels: ["enhancement-proposal"] |
| 5 | +body: |
| 6 | + - type: textarea |
| 7 | + id: summary |
| 8 | + attributes: |
| 9 | + label: Summary |
| 10 | + description: | |
| 11 | + A 1-2 paragraph "elevator pitch" of the enhancement. It should be understandable to someone familiar with UCP but not necessarily the deep technical details of this specific proposal. |
| 12 | + validations: |
| 13 | + required: true |
| 14 | + - type: textarea |
| 15 | + id: motivation |
| 16 | + attributes: |
| 17 | + label: Motivation |
| 18 | + description: | |
| 19 | + Explain the problem this proposal solves. Why is this significant change necessary now? What use cases does it enable? Who is the target user or beneficiary of this change? |
| 20 | + validations: |
| 21 | + required: true |
| 22 | + - type: textarea |
| 23 | + id: goals |
| 24 | + attributes: |
| 25 | + label: Goals |
| 26 | + description: | |
| 27 | + List the specific, measurable outcomes of this enhancement. |
| 28 | + placeholder: | |
| 29 | + * |
| 30 | + * |
| 31 | + validations: |
| 32 | + required: true |
| 33 | + - type: textarea |
| 34 | + id: non-goals |
| 35 | + attributes: |
| 36 | + label: Non-Goals |
| 37 | + description: | |
| 38 | + Explicitly state what is out of scope for this proposal. This helps focus the discussion and prevents scope creep. |
| 39 | + placeholder: | |
| 40 | + * |
| 41 | + * |
| 42 | + - type: textarea |
| 43 | + id: detailed-design |
| 44 | + attributes: |
| 45 | + label: Detailed Design |
| 46 | + description: | |
| 47 | + This is the core of the proposal. Describe the architecture and implementation details with enough clarity that another contributor could write the code based on this description. Include sub-sections as needed, such as: |
| 48 | +
|
| 49 | + * **API Changes:** Detail any new API endpoints, changes to existing ones, or modifications to request/response schemas. |
| 50 | + * **Data Structures:** Describe any changes to core data structures or JSON schemas. |
| 51 | + * **Behavioral Changes:** Explain how the system's fundamental behavior will change. |
| 52 | + validations: |
| 53 | + required: true |
| 54 | + - type: textarea |
| 55 | + id: risks-mitigations |
| 56 | + attributes: |
| 57 | + label: Risks and Mitigations |
| 58 | + description: | |
| 59 | + This is a mandatory section. Discuss the potential downsides and risks of this proposal. For every risk identified, list a mitigation strategy. |
| 60 | +
|
| 61 | + * **Security:** Does this introduce new attack vectors or data exposure risks? |
| 62 | + * **Performance:** Will this negatively impact latency or throughput? |
| 63 | + * **Backward Compatibility:** Will this break existing clients or workflows? If so, what is the migration plan? |
| 64 | + * **Complexity:** Does this add significant maintenance burden to the protocol? |
| 65 | + validations: |
| 66 | + required: true |
| 67 | + - type: textarea |
| 68 | + id: test-plan |
| 69 | + attributes: |
| 70 | + label: Test Plan |
| 71 | + description: | |
| 72 | + Describe how this feature will be tested. A test plan is required for a proposal to be moved to the "Provisional" stage. |
| 73 | +
|
| 74 | + * **Unit Tests:** Which core logic requires unit coverage? |
| 75 | + * **Integration Tests:** How will interactions between different components be verified? |
| 76 | + * **End-to-End Tests:** What user scenarios will be automated to validate the full workflow? |
| 77 | + validations: |
| 78 | + required: true |
| 79 | + - type: textarea |
| 80 | + id: graduation-criteria |
| 81 | + attributes: |
| 82 | + label: Graduation Criteria |
| 83 | + description: | |
| 84 | + Define the specific, objective criteria required to move this capability through the maturity levels. See CONTRIBUTING.md for full definitions of each level. |
| 85 | + value: | |
| 86 | + **Working Draft → Candidate:** |
| 87 | + * [ ] Schema merged and documented (with Working Draft disclaimer). |
| 88 | + * [ ] Unit and integration tests are passing. |
| 89 | + * [ ] Initial documentation is written. |
| 90 | + * [ ] TC majority vote to advance. |
| 91 | +
|
| 92 | + **Candidate → Stable:** |
| 93 | + * [ ] Adoption feedback has been collected and addressed. |
| 94 | + * [ ] Full documentation and migration guides are published. |
| 95 | + * [ ] TC majority vote to advance. |
| 96 | + - type: textarea |
| 97 | + id: implementation-history |
| 98 | + attributes: |
| 99 | + label: Implementation History |
| 100 | + description: | |
| 101 | + This section will be updated by the maintainers as the proposal moves through its lifecycle. |
| 102 | + value: | |
| 103 | + * [YYYY-MM-DD]: Proposal submitted. |
| 104 | + * [YYYY-MM-DD]: TC approved "Provisional"; capability enters "Working Draft". |
| 105 | + * [YYYY-MM-DD]: TC approved advancement to "Candidate". |
| 106 | + * [YYYY-MM-DD]: TC approved "Implemented"; capability enters "Stable". |
| 107 | + - type: checkboxes |
| 108 | + id: terms |
| 109 | + attributes: |
| 110 | + label: Code of Conduct |
| 111 | + description: By submitting this issue, you agree to follow our Code of Conduct |
| 112 | + options: |
| 113 | + - label: I agree to follow this project's Code of Conduct |
| 114 | + required: true |
0 commit comments