Skip to content

Commit 7775834

Browse files
chengjingtaochengjingtao
committed
📚 Sync docs from alaudadevops/connectors-operator on c4e63e243babd2feb9f950ed73ebebda22b7c100
Source: add proposal template (#224) Author: chengjingtao Ref: refs/heads/main Commit: c4e63e243babd2feb9f950ed73ebebda22b7c100 This commit automatically syncs documentation changes from the source-docs repository. 🔗 View source commit: AlaudaDevops/connectors-operator@c4e63e2 🤖 Synced on 2025-09-24 03:20:54 UTC
1 parent 7f5b241 commit 7775834

File tree

2 files changed

+190
-3
lines changed

2 files changed

+190
-3
lines changed

‎.github/SYNC_INFO.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
# Documentation Sync Information
22

3-
- **Last synced**: 2025-09-16 03:29:26 UTC
3+
- **Last synced**: 2025-09-24 03:20:54 UTC
44
- **Source repository**: alaudadevops/connectors-operator
5-
- **Source commit**: [9e14c5db684d82d2a45436df62ec61a8234aea9d](https://github.com/alaudadevops/connectors-operator/commit/9e14c5db684d82d2a45436df62ec61a8234aea9d)
5+
- **Source commit**: [c4e63e243babd2feb9f950ed73ebebda22b7c100](https://github.com/alaudadevops/connectors-operator/commit/c4e63e243babd2feb9f950ed73ebebda22b7c100)
66
- **Triggered by**: chengjingtao
7-
- **Workflow run**: [#34](https://github.com/alaudadevops/connectors-operator/actions/runs/17753586099)
7+
- **Workflow run**: [#35](https://github.com/alaudadevops/connectors-operator/actions/runs/17965310900)
88

99
## Files synced:
1010
- docs/

‎docs/en/teps/template.md‎

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
- [Summary](#summary)
2+
- [Motivation](#motivation)
3+
- [Goals](#goals)
4+
- [Non-Goals](#non-goals)
5+
- [Use Cases](#use-cases)
6+
- [Requirements](#requirements)
7+
- [Proposal](#proposal)
8+
- [Notes and Warnings](#notes-and-warnings)
9+
- [Design Details](#design-details)
10+
- [Design Evaluation](#design-evaluation)
11+
- [Reusability](#reusability)
12+
- [Simplicity](#simplicity)
13+
- [Flexibility](#flexibility)
14+
- [Conformance](#conformance)
15+
- [User Experience](#user-experience)
16+
- [Performance](#performance)
17+
- [Risks and Mitigations](#risks-and-mitigations)
18+
- [Drawbacks](#drawbacks)
19+
- [Alternatives](#alternatives)
20+
- [Implementation Plan](#implementation-plan)
21+
- [Test Plan](#test-plan)
22+
- [Infrastructure Needed](#infrastructure-needed)
23+
- [Upgrade and Migration Strategy](#upgrade-and-migration-strategy)
24+
- [Implementation Pull Requests](#implementation-pull-requests)
25+
- [References](#references)
26+
27+
## Summary
28+
29+
This section is crucial for generating high-quality user documentation (e.g., release notes or development roadmaps). This information should be collected before implementation begins to avoid distracting the implementers while writing release notes and implementing features.
30+
31+
A good summary may be at least one paragraph long.
32+
33+
In this section and the following ones, please follow the [documentation style guide] guidelines. In particular, wrap lines to a reasonable length to allow reviewers to reference specific parts and reduce diffs when updating.
34+
35+
[Documentation Style Guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
36+
37+
## Motivation
38+
39+
This section explicitly lists the motivation, goals, and non-goals of this KEP. It describes the significance of the change and its benefits to users. The motivation section may optionally provide links to [experience reports] to demonstrate broader interest from the Tekton community in the KEP.
40+
41+
[Experience Reports]: https://github.com/golang/go/wiki/ExperienceReports
42+
43+
### Goals
44+
45+
- List the specific goals of the KEP.
46+
- What is it trying to achieve?
47+
- How will we know if it is successful?
48+
49+
### Non-Goals
50+
51+
- Listing non-goals helps to focus the discussion and make progress.
52+
- What does this KEP not encompass?
53+
54+
### Use Cases
55+
56+
Describe the specific improvements that will be seen by specific user groups if the motivations in this document lead to fixes or features.
57+
58+
Consider the users’:
59+
- [Roles] - Are they task authors? Catalog task users? Cluster administrators? Etc.
60+
- Experiences - If the problem is resolved, which workflows or operations will be enhanced?
61+
62+
[Roles]: https://github.com/tektoncd/community/blob/main/user-profiles.md
63+
64+
### Requirements
65+
66+
Describe the constraints that the solution must satisfy, such as:
67+
- What performance characteristics must be met?
68+
- What specific edge cases must be handled?
69+
- Which user scenarios will be impacted and must be accommodated?
70+
71+
## Proposal
72+
73+
This is where we specifically discuss the details of the proposal. There should be enough detail for reviewers to accurately understand your suggestion, but it should not include aspects like API design or implementation. The "Design Details" section below is for genuine detailed discussions.
74+
75+
### Notes and Warnings
76+
77+
(Optional)
78+
79+
Detail the necessary nuances here.
80+
- What are the warnings regarding the proposal?
81+
- What are some important details not mentioned above?
82+
- What are the core concepts, and how are they related?
83+
84+
## Design Details
85+
86+
This section should contain enough information to make the specific details of your changes easy to understand. This might include API specifications (though not always required) or even code snippets. If there are any ambiguities about how to implement your proposal, this is the place to discuss them.
87+
88+
Add workflow diagrams or any relevant images if helpful, placing them under "/KEPs/images/". The file names should be chosen by the KEP authors, but a general guideline is that they should include at least the KEP number, e.g., "/KEPs/images/NNNN-workflow.jpg".
89+
90+
## Design Evaluation
91+
92+
How does this proposal impact Tekton's API conventions, reusability, simplicity, flexibility, and consistency, as discussed in the [design principles](https://github.com/tektoncd/community/blob/master/design-principles.md)?
93+
94+
### Reusability
95+
96+
- Are there existing functionalities related to the proposed feature? Is there reuse of existing functionalities?
97+
- Is the problem addressed related to authoring time or runtime? Is the proposed feature at the appropriate level (authoring time or runtime)?
98+
99+
### Simplicity
100+
101+
- How does this proposal impact user experience?
102+
- What is the current user experience without this feature? How challenging is it?
103+
- How is the user experience after implementing the feature? What changes will occur?
104+
- Does this proposal include the minimum changes needed to address the use case?
105+
- Does the proposal have any implied behaviors? Will users expect these implied behaviors or be surprised by them? Are there any security risks?
106+
107+
### Flexibility
108+
109+
- What dependencies does this proposal require to function? What support or maintenance do these dependencies need?
110+
- Are we coupling two or more Tekton projects in this proposal (e.g., coupling Pipelines with Chains)?
111+
- Are we coupling Tekton with other projects (e.g., Knative, Sigstore)?
112+
- What is the impact of this coupling on operators, such as maintenance and end-to-end testing?
113+
- Are there opinionated choices in this proposal? If so, are they necessary? Can users extend it with their choices?
114+
115+
### Conformance
116+
117+
- Does this proposal require users to understand how the Tekton API is implemented?
118+
- Does this proposal introduce additional Kubernetes concepts into the API? If so, is it necessary?
119+
- If this proposal leads to changes in the API, what updates are needed for the [API specifications](https://github.com/tektoncd/pipeline/blob/main/docs/api-spec.md)?
120+
121+
### User Experience
122+
123+
(Optional)
124+
125+
Consider the impact on user experience. Depending on the area of change, users may be the authors of tasks and pipelines, those who may trigger TaskRuns and PipelineRuns, or those responsible for monitoring the execution through CLI, dashboards, or monitoring systems.
126+
127+
Consider including those working on CLI and dashboards.
128+
129+
### Performance
130+
131+
(Optional)
132+
133+
Consider the use cases affected by this change and their performance requirements.
134+
- How does this change affect the startup and execution times of TaskRuns and PipelineRuns?
135+
- What impact does it have on the Tekton controller and the resource usage of TaskRuns and PipelineRuns?
136+
137+
### Risks and Mitigations
138+
139+
What risks does this proposal present, and how can we mitigate them? Think broadly. For instance, consider security and how this will affect the larger Tekton ecosystem. Include considerations for those working outside of working groups or subprojects.
140+
- How will security be reviewed, and by whom?
141+
- How will user experience be reviewed, and by whom?
142+
143+
### Drawbacks
144+
145+
Why should this KEP not be implemented?
146+
147+
## Alternatives
148+
149+
What other approaches did you consider, and why were they excluded? These do not need to be as detailed as the proposal but should include enough information to convey the ideas and why they are unacceptable.
150+
151+
## Implementation Plan
152+
153+
What are the implementation phases or milestones? Taking an incremental approach makes it easier to review and merge implementation pull requests.
154+
155+
### Test Plan
156+
157+
When planning tests for this enhancement, consider the following:
158+
- Will there be end-to-end and integration tests in addition to unit tests?
159+
- How will it be tested in isolation versus being tested with other components?
160+
161+
There is no need to list all test cases; just outline the general strategy. Any aspects considered tricky about the implementation, as well as anything that may be particularly difficult to test, should be mentioned.
162+
163+
All code should have sufficient tests (with expected coverage eventually).
164+
165+
### Infrastructure Needed
166+
167+
(Optional)
168+
169+
Use this section if you need resources from the project or working group. Examples include new subprojects, requested repositories, or GitHub details. Listing these allows the working group to start the process for these resources immediately.
170+
171+
### Upgrade and Migration Strategy
172+
173+
(Optional)
174+
175+
Use this section to detail whether this feature requires upgrade or migration strategies. This is especially useful when we are modifying behaviors or adding features that may replace and deprecate current functionalities.
176+
177+
### Implementation Pull Requests
178+
179+
Once the KEP is ready to be marked as implemented, list all merged GitHub pull requests.
180+
181+
Note: This section is specifically for merged pull requests for this KEP. It will serve as a quick reference for those looking for the implementation of this KEP.
182+
183+
## References
184+
185+
(Optional)
186+
187+
Use this section to add links to GitHub issues, other KEPs, design documents in the Tekton shared drive, examples, etc. This is helpful for reviewing any other relevant links for more details.

0 commit comments

Comments
 (0)