You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -59,30 +59,130 @@ Kustomize follows the [Kubernetes Community Membership] contributor ladder. Role
59
59
60
60
The kyaml module within the Kustomize repo has additional owners following the same ladder.
61
61
62
+
For the kustomize project, we have defined some specific guidelines on each step of the ladder:
63
+
64
+
To reach reviewer status, you must:
65
+
- Have been actively involved in kustomize for 3+ months
66
+
- Review at least 8 PRs that have been driven through to completion (see the reviewer guide below)
67
+
- Author at least 5 PRs that have been approved and merged
68
+
- Be a member of the kubernetes-sigs org. This should not be a blocker though, as once you meet the requirements for reviewer here,
69
+
the existing kustomize maintainers will be happy to sponsor your request to join the kubernetes-sigs org.
70
+
- Once you have met the above requirements, you may submit a PR adding yourself to the kustomize reviewers list, with links to your
71
+
contributions in the description.
72
+
73
+
To reach approver status, you must:
74
+
- Meet all the requirements of a reviewer
75
+
- Have been actively involved in kustomize for 6+ months
76
+
- Review at least 15 PRs that have been driven through to completion (see the reviewer guide below)
77
+
- Authored PRs meeting *either* of the following requirements:
78
+
- 15 PRs that have been approved and merged
79
+
-*OR* 10 PRs that have been approved and merged where some were more difficult, required greater thought/design,
80
+
or built up to larger features/long-term goals.
81
+
- File 3 issues. This can be any number of things, including but not limited to:
82
+
- Bugs with kustomize usage that you've found
83
+
- CI or release improvements
84
+
- Creating subtasks of a larger feature or project that you are in charge of.
85
+
- Long term improvements for the health of the project
86
+
- Triage at least 10 untriaged issues, including at least 1 feature request. The kustomize bug scrub is a great place to get practice with doing this, but you can
87
+
also follow the triage guide below to get started on your own.
88
+
- Demonstrate deeper understanding of kustomize goals. This can take many forms and is a bit subjective, but here are a few examples:
89
+
- saying no to an eschewed feature, instead recommending an alternative solution that is more aligned with the declarative configuration model
90
+
- active participation in discussion on a feature request issue
91
+
- filing an issue describing a long term problem and solution aligned with kustomize goals, for example: https://github.com/kubernetes-sigs/kustomize/issues/5140
92
+
- writing up KEPs for features that will improve the kustomize workflow while being aligned with kustomize goals, for example: https://github.com/kubernetes-sigs/kustomize/pull/4558
93
+
- Regularly interact with the existing kustomize maintainers, with clear communication about what you are working on or planning to work on. The kustomize
94
+
maintainers should know who you are and be familiar with your contributions.
95
+
- If you meet *most* of the above requirements while going above and beyond in a few areas, we will still consider your request to become an approver even
96
+
if you are missing one or two of the requirements. Please contact the maintainers directly to ask about getting approver status if you fall into this category.
97
+
- Otherwise, once you meet all the above requirements, you may:
98
+
- request to be added to the kustomize maintainer meeting that occurs each week with the kustomize PMs.
99
+
- submit a PR adding yourself to the kustomize approvers list, with links to your contributions in the description.
100
+
101
+
To reach owner status, you must:
102
+
- Meet all the requirements of an approver
103
+
- Have been actively involved with kustomize for 1+ year
104
+
- Assisted the current owner in driving the roadmap. This can be explicit or implicit help, such as:
105
+
- Editing the roadmap directly
106
+
- Reviewing the roadmap
107
+
- Providing suggestions for issues or prioritization in meetings that indirectly influence the roadmap
108
+
- Regularly triage issues and attend the kustomize bug scrub
109
+
- Regularly review PRs (1-2 a week)
110
+
- Periodically lead the kustomize bug scrub
111
+
- Periodically release kustomize (ensuring that there are no release blockers and that release notes are clean)
112
+
- Be the primary owner or point of contact for a particular project or area of code
113
+
- Ideally, there should be 2-3 owners at a time. Reach out to the current owners if you are interested in ownership. These
114
+
requirements are not strict and evaluation is somewhat subjective.
115
+
116
+
## Reviewer guide
117
+
Please watch this talk on how to review code from Tim Hockin: https://www.youtube.com/watch?v=OZVv7-o8i40
118
+
119
+
For reviewing PRs in kustomize, we have some specific guidelines:
120
+
- If the PR is introducing a new feature:
121
+
-*It must be implementing an issue that has already been triage/accepted or
122
+
a KEP that has been approved.* If it is not, then request the PR author to first file an issue.
123
+
- The PR must include thorough tests for the new feature, including unit and integration tests
124
+
- The code must be clean and readable, with thought given to how we will maintain the code in the future
125
+
- If the feature requires being broken up into multiple PRs to ease review, the feature should not be exposed to users
126
+
until the feature is completed in the last PR. For example, while we were building `kustomize localize`, we
127
+
built the feature almost entirely under the `api` module as a library with all the needed tests. There was no way
128
+
for users to invoke the localize code until the last PR that actually exposed the `kustomize localize` command in the
129
+
kustomize binary. This allowed us to continue development of `kustomize localize` without blocking kustomize releases.
130
+
If this type of development is not possible, then new features requiring multiple PRs should be
131
+
developed in their own feature branch.
132
+
- If the PR is introducing a bug fix:
133
+
- If the PR is not fixing an issue that has already been triage/accepted, follow the triage guide below on bug
134
+
fixes to decide if this is a PR we want to accept.
135
+
- The PR should have two distinct commits:
136
+
- The first commit should add a test demonstrating incorrect behavior
- The regression test is absolutely required, and we cannot accept bug fixes without tests.
142
+
- If the PR is introducing a performance improvement:
143
+
- The PR description should give an indication of how much the performance is being improved and how we
144
+
can measure it - benchmark tests are fantastic.
145
+
- Other PRs (documentation, CI improvements, etc.) should be reviewed based on your best judgment.
146
+
147
+
## Triage guide
148
+
The possible triage labels are listed here: https://github.com/kubernetes-sigs/kustomize/labels?q=triage.
149
+
150
+
Triaging a feature request means:
151
+
- Understand what the user is asking for, and their use case.
152
+
- Verify that it is not an [eschewed feature](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/#build-time-side-effects-from-cli-args-or-env-variables)
153
+
- Verify that it is not a duplicate issue.
154
+
- Look into workarounds. Is there another way that the user can achieve their use case with existing features?
155
+
- If you are new to this role, prior to leaving a comment on the issue, please bring it to weekly standup
156
+
for group discussion to make sure that we are all on the same page.
157
+
- Once you feel ready, you can label it with a triage label. Here's an [example](https://github.com/kubernetes-sigs/kustomize/issues/5049). You can also
158
+
look at other feature request issues to see how they were triaged and resolved. There are a few different triage labels that you can use, you can see the
159
+
full list [here](https://github.com/kubernetes-sigs/kustomize/labels?q=triage).
160
+
161
+
Triaging a bug means:
162
+
- First, verify that you can reproduce the issue. If you cannot reproduce the issue or need more information to give
163
+
it a go, triage it accordingly.
164
+
- Try to understand if this is really a bug or if this is intended behavior from kustomize. If it seems like intended
165
+
behavior, do your best to explain to the user why this is the case.
166
+
- If it seems to be a genuine bug, you can /triage accept the issue. In addition, investigate if there are workarounds or
167
+
alternative solutions for the user that they can try until the issue gets resolved.
168
+
62
169
Administrative notes:
63
170
64
171
- The [OWNERS file spec] is a useful resources in making changes.
65
172
- Maintainers and admins must be added to the appropriate lists in both [Kustomize OWNERS_ALIASES] and [SIG-CLI Teams]. If this isn't done, the individual in question will lack either PR approval rights (Kustomize list) or the appropriate Github repository permissions (community list).
66
173
67
174
## Project/Product Managers
68
175
69
-
Kustomize will have opportunities to join in a project/product manager role. You can
70
-
typically start working on this role as part of a kustomize training cohort, so please
71
-
keep an eye out for that or reach out to the leads if you are interested in this type of
72
-
work. Expectations for this role are:
176
+
Kustomize will have opportunities to join in a project/product manager role. You can reach out to
177
+
the existing kustomize maintainers if you are interested in this type of role. Project management work
178
+
can greatly help supplement your contributions as you climb from reviewer to approver
179
+
to owner.
180
+
181
+
Expectations for this role are:
73
182
74
183
- Triage 1 feature request each week, and bring it to weekly stand-up for discussion. Feature
75
184
requests are issues labeled kind/feature, and you can find them [here](https://github.com/kubernetes-sigs/kustomize/issues?q=is%3Aissue+is%3Aopen+kind+feature+label%3Akind%2Ffeature).
76
-
Triaging a feature request means:
77
-
- Understand what the user is asking for, and their use case.
78
-
- Verify that it is not an [eschewed feature](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/#build-time-side-effects-from-cli-args-or-env-variables)
79
-
- Verify that it is not a duplicate issue.
80
-
- Look into workarounds. Is there another way that the user can achieve their use case with existing features?
81
-
- If you are new to this role, prior to leaving a comment on the issue, please bring it to weekly standup
82
-
for group discussion to make sure that we are all on the same page.
83
-
- Once you feel ready, you can label it with a triage label. Here's an [example](https://github.com/kubernetes-sigs/kustomize/issues/5049). You can also
84
-
look at other feature request issues to see how they were triaged and resolved. There are a few different triage labels that you can use, you can see the
85
-
full list [here](https://github.com/kubernetes-sigs/kustomize/labels?q=triage).
185
+
Please view the above triage guide for details on how to approach feature request triage.
86
186
- Monitor the kustomize Slack channel and try to help users if you can. It is a pretty
87
187
active channel, so responding to 4-5 users per week is sufficient even if some
88
188
questions go unanswered. If there is an interesting topic or a recurring problem that many
0 commit comments