Skip to content

Commit c155e9b

Browse files
wry-rywry-ry
authored
Merge branch 'main' into other-stuff
2 parents 8ff297f + 788e944 commit c155e9b

5 files changed

Lines changed: 261 additions & 71 deletions

File tree

‎.github/ISSUE_TEMPLATE/bug_report.md‎

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
---
2+
name: Bug report
3+
about: Create a report to help us improve
4+
title: ''
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
**Describe the bug**
11+
A clear and concise description of what the bug is.
12+
13+
**To Reproduce**
14+
Steps to reproduce the behavior:
15+
16+
1. Go to '...'
17+
2. Click on '....'
18+
3. Scroll down to '....'
19+
4. See error
20+
21+
**Expected behavior**
22+
A clear and concise description of what you expected to happen.
23+
24+
**Screenshots**
25+
If applicable, add screenshots to help explain your problem.
26+
27+
**Desktop (please complete the following information):**
28+
29+
- OS: [e.g. iOS]
30+
- Browser [e.g. chrome, safari]
31+
- Version [e.g. 22]
32+
33+
**Smartphone (please complete the following information):**
34+
35+
- Device: [e.g. iPhone6]
36+
- OS: [e.g. iOS8.1]
37+
- Browser [e.g. stock browser, safari]
38+
- Version [e.g. 22]
39+
40+
**Additional context**
41+
Add any other context about the problem here.

‎.github/ISSUE_TEMPLATE/enhancement-proposal.md‎

Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
---
2+
name: Enhancement Proposal
3+
about: This is a template for submitting an enhancement proposal.
4+
title: Descriptive Title of the Enhancement
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
## Summary
11+
12+
<!--
13+
A 1-2 paragraph "elevator pitch" of the enhancement. It should be understandable
14+
to someone familiar with UCP but not necessarily the deep technical details of
15+
this specific proposal.
16+
-->
17+
18+
## Motivation
19+
20+
<!--
21+
Explain the problem this proposal solves. Why is this significant change
22+
necessary now? What use cases does it enable? Who is the target user or
23+
beneficiary of this change?
24+
-->
25+
26+
### Goals
27+
28+
<!--
29+
List the specific, measurable outcomes of this enhancement.
30+
-->
31+
*
32+
*
33+
34+
### Non-Goals
35+
36+
<!--
37+
Explicitly state what is out of scope for this proposal. This helps focus the
38+
discussion and prevents scope creep.
39+
-->
40+
*
41+
*
42+
43+
## Detailed Design
44+
45+
<!--
46+
This is the core of the proposal. Describe the architecture and implementation
47+
details with enough clarity that another contributor could write the code based
48+
on this description. Include sub-sections as needed, such as:
49+
50+
* **API Changes:** Detail any new API endpoints, changes to existing ones, or
51+
modifications to request/response schemas.
52+
* **Data Structures:** Describe any changes to core data structures or JSON
53+
schemas.
54+
* **Behavioral Changes:** Explain how the system's fundamental behavior will
55+
change.
56+
-->
57+
58+
## Risks and Mitigations
59+
60+
<!--
61+
This is a mandatory section. Discuss the potential downsides and risks of this
62+
proposal. For every risk identified, list a mitigation strategy.
63+
64+
* **Security:** Does this introduce new attack vectors or data exposure risks?
65+
* **Performance:** Will this negatively impact latency or throughput?
66+
* **Backward Compatibility:** Will this break existing clients or workflows? If
67+
so, what is the migration plan?
68+
* **Complexity:** Does this add significant maintenance burden to the protocol?
69+
-->
70+
71+
## Test Plan
72+
73+
<!--
74+
Describe how this feature will be tested. A test plan is required for a proposal
75+
to be moved to the "Implementable" stage.
76+
77+
* **Unit Tests:** Which core logic requires unit coverage?
78+
* **Integration Tests:** How will interactions between different components be
79+
verified?
80+
* **End-to-End Tests:** What user scenarios will be automated to validate the
81+
full workflow?
82+
-->
83+
84+
## Graduation Criteria
85+
86+
<!--
87+
Define the specific, objective criteria required to move this feature through
88+
the stability levels.
89+
90+
**Alpha -> Beta:**
91+
* [ ] Feature is implemented behind a feature flag (if applicable).
92+
* [ ] Unit and integration tests are passing.
93+
* [ ] Initial documentation is written.
94+
* [ ] Deployed and tested in a non-production environment.
95+
96+
**Beta -> General Availability (GA):**
97+
* [ ] At least two independent implementations exist (e.g., from two different
98+
merchants or platforms).
99+
* [ ] User/developer adoption feedback has been collected and addressed.
100+
* [ ] No critical bugs have been reported for a set period (e.g., 4 weeks).
101+
* [ ] Full documentation and migration guides are published.
102+
-->
103+
104+
### Implementation History
105+
106+
<!--
107+
This section will be updated by the maintainers as the proposal moves through
108+
its lifecycle.
109+
110+
* [YYYY-MM-DD]: Proposal submitted as "Provisional".
111+
* [YYYY-MM-DD]: TC approved proposal to move to "Implementable".
112+
* [YYYY-MM-DD]: Code merged, proposal moved to "Implemented".
113+
-->

‎.github/ISSUE_TEMPLATE/feature_request.md‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
---
2+
name: Feature request
3+
about: Suggest an idea for this project
4+
title: ''
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
**Is your feature request related to a problem? Please describe.**
11+
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
12+
13+
**Describe the solution you'd like**
14+
A clear and concise description of what you want to happen.
15+
16+
**Describe alternatives you've considered**
17+
A clear and concise description of any alternative solutions or features you've considered.
18+
19+
**Additional context**
20+
Add any other context or screenshots about the feature request here.

‎CONTRIBUTING.md‎

Lines changed: 87 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -54,6 +54,81 @@ to use GitHub Discussions.
5454

5555
## Contribution Process
5656

57+
### Significant Changes
58+
59+
Any significant change to the protocol requires a formal
60+
[Enhancement Proposal](../../issues/new?template=enhancement-proposal.md)
61+
and will require Technical Committee approval. Because a change to the protocol
62+
requires the entire adopting ecosystem to implement the change, we consider
63+
significant changes to include:
64+
65+
* Core Schema Modifications: Any change to JSON schemas, including
66+
adding/updating fields or field descriptions
67+
* Protocol Changes: Alterations to communication flows or expected behaviors of
68+
operations
69+
* New API Endpoints: Introduction of entirely new capabilities or services.
70+
* Backwards Incompatibility: Any "breaking" change that requires a major version
71+
increment.
72+
73+
An [Enhancement Proposal](../../issues/new?template=enhancement-proposal.md)
74+
is a living artifact that tracks a proposal through its lifecycle:
75+
76+
* Provisional: The initial stage where the idea is proposed and debated within
77+
the community. In order to move to the next stage, the enhancement proposal
78+
will need to be approved by a simple majority of the TC.
79+
* Implementable: The stage after the design has been finalized and has received
80+
formal approval from at least one maintainer and one member of the TC.
81+
* Implemented: The final stage, reached when the code for the feature is
82+
complete, tested, documented, and merged.
83+
84+
Every [Enhancement Proposal](../../issues/new?template=enhancement-proposal.md)
85+
must follow a standard template requiring sections for a Summary, Motivation,
86+
Detailed Design, Risks, a Test Plan, and Graduation Criteria (defining the path
87+
from Alpha to Beta to General Availability). This creates a permanent, public
88+
design record for the project's evolution.
89+
90+
### Voting and decision making
91+
92+
The path below should be followed for resolving issues that are technical in
93+
nature.
94+
95+
* L1: routine changes (bug fixes, documentation, minor improvements) require
96+
approval from at least 2 Maintainers.
97+
* L2: Any technical issues that span across topics and/or cannot be resolved
98+
amongst maintainers and DWGs will be escalated to the TC. Significant changes
99+
affecting core protocol architecture must follow the Enhancement Proposal
100+
process, requiring TC approval before implementation.
101+
* L3: Any changes made to the Governance process (e.g updating the
102+
[GOVERNANCE.md](GOVERNANCE.md) file) or any changes that impact the core
103+
protocol’s scope or adoption, must be approved by Governance Council (GC).
104+
105+
The TC reserves the right to stop any discussions deemed non-critical to the
106+
protocol.
107+
108+
### Versioning
109+
110+
The base protocol uses date based versioning. Major version increments (breaking
111+
changes) require a majority Governing Council approval due to the high cost to
112+
the ecosystem. A quorum requires all Governing Council members (or appropriate
113+
representatives) to be present for decision-making. New features should
114+
typically be attempted through the extensions framework first. If an extension
115+
achieves significant usage, it can be considered for adoption into the next
116+
minor version of the core.
117+
118+
### Adding new extensions and capabilities to the core protocol
119+
120+
UCP is designed to be very extensible while keeping the core protocol light. A
121+
core principle of UCP is to ensure that the set of extensions and capabilities
122+
defined in UCP have broad ecosystem support. Vendors should first create
123+
capabilities & extensions in vendor-specific namespace pattern
124+
(e.g. com.{vendor}.*) for new use cases. Requests to add new capabilities and
125+
extensions should only be submitted when there is proven widespread adoption of
126+
vendor-specific capabilities and extensions. See
127+
[Spec URL Binding](https://ucp.dev/specification/overview/#spec-url-binding)
128+
and [Governance Model](https://ucp.dev/specification/overview/#governance-model)
129+
for more details on using namespace pattern for creating vendor-specific
130+
capabilities and extensions.
131+
57132
### Code Reviews
58133

59134
All submissions, including submissions by project members, require review. We
@@ -69,21 +144,21 @@ add `!` before the colon: `type!: description`.
69144

70145
**Common Types:**
71146

72-
- `feat`: A new feature
73-
- `fix`: A bug fix
74-
- `docs`: Documentation only changes
75-
- `style`: Changes that do not affect the meaning of the code
76-
- `refactor`: A code change that neither fixes a bug nor adds a feature
77-
- `perf`: A code change that improves performance
78-
- `test`: Adding missing tests or correcting existing tests
79-
- `chore`: Changes to the build process or auxiliary tools and libraries
147+
* `feat`: A new feature
148+
* `fix`: A bug fix
149+
* `docs`: Documentation only changes
150+
* `style`: Changes that do not affect the meaning of the code
151+
* `refactor`: A code change that neither fixes a bug nor adds a feature
152+
* `perf`: A code change that improves performance
153+
* `test`: Adding missing tests or correcting existing tests
154+
* `chore`: Changes to the build process or auxiliary tools and libraries
80155

81156
**Examples:**
82157

83-
- `feat: add new payment gateway`
84-
- `fix: resolve crash on checkout`
85-
- `docs: update setup guide`
86-
- `feat!: remove deprecated buyer field from checkout`
158+
* `feat: add new payment gateway`
159+
* `fix: resolve crash on checkout`
160+
* `docs: update setup guide`
161+
* `feat!: remove deprecated buyer field from checkout`
87162

88163
### Linting and Automated Checks
89164

‎GOVERNANCE.md‎

Lines changed: 0 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -82,65 +82,6 @@
8282
* May choose to review and veto TC decision or recommendation.
8383
* Decisions are made with a majority vote.
8484

85-
## Operational Rules and Process
86-
87-
### Enhancement proposals
88-
89-
For any significant change to the protocol, such as adding a new capability,
90-
altering a core construct, or changing a fundamental behavior, a written
91-
enhancement proposal must be submitted to the TC.
92-
93-
An enhancement proposal is a living artifact that tracks a proposal through its
94-
lifecycle:
95-
96-
* **Provisional:** The initial stage where the idea is proposed and debated
97-
within the community. In order to move to the next stage, the enhancement
98-
proposal will need to be approved by a simple majority of the TC.
99-
* **Implementable:** The stage after the design has been finalized and has
100-
received formal approval from at least one maintainer and one member of the
101-
TC.
102-
* **Implemented:** The final stage, reached when the code for the feature is
103-
complete, tested, documented, and merged.
104-
105-
Every enhancement proposal must follow a standard template requiring sections
106-
for a Summary, Motivation, Detailed Design, Risks, a Test Plan, and Graduation
107-
Criteria (defining the path from Alpha to Beta to General Availability). This
108-
creates a permanent, public design record for the project's evolution.
109-
110-
### Voting and decision making
111-
112-
The path below should be followed for resolving issues that are technical in
113-
nature.
114-
115-
* **L1:** routine changes (bug fixes, documentation, minor improvements) are
116-
auto-approved after 1 business day if no blocks are raised (silence =
117-
consent).
118-
* **L2:** For non-major version increments and standard changes, proposals are
119-
auto-approved after 5 business days if no objections are raised and there is
120-
at least one +1 from a maintainer. If objections are raised, contributors
121-
have 3 business days to reach a resolution.
122-
* **L3:** If unresolved after 5 business days, the relevant maintainer makes a
123-
binding decision based on technical merit and speed.
124-
* **L4:** Any technical issues that span across topics and cannot be resolved
125-
amongst maintainers and DWGs will be escalated to the TC. Significant
126-
changes affecting core protocol architecture must follow the Enhancement
127-
Proposal process, requiring TC approval before implementation.
128-
* **L5:** If a conflict impacts the core protocol’s scope or business
129-
strategy, it escalates to the Governing Council.
130-
131-
The TC reserves the right to stop any discussions deemed non-critical to the
132-
protocol.
133-
134-
### Versioning
135-
136-
The base protocol uses date based versioning. Major version increments (breaking
137-
changes) require a majority Governing Council approval due to the high cost
138-
to the ecosystem. A quorum requires all Governing Council members (or
139-
appropriate representatives) to be present for decision-making. New features
140-
should typically be attempted through the extensions framework first. If an
141-
extension achieves significant usage, it can be considered for adoption into the
142-
next minor version of the core.
143-
14485
## Communication
14586

14687
To ensure the protocol remains open and agnostic, all governance activities must

0 commit comments

Comments
 (0)