-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
contributing KEPs in SIG Node: best practices #8005
base: master
Are you sure you want to change the base?
contributing KEPs in SIG Node: best practices #8005
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SergeyKanzhelev The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/assign @mrunalp |
I left nits but this looks great overall. Thanks! |
c6f3b48
to
c982337
Compare
cool, applied suggestions. I plan to write about code contributions processes after this one is merged |
The diversity of workloads, environments, and the scale SIG Node needs to support makes every code change risky as all the side effects need to be evaluated. | ||
And the contribution can realistically only be evaluated by a small set of maintainers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a huge fan of this clause and sentence
as all the side effects need to be evaluated.
And the contribution can realistically only be evaluated by a small set of maintainers.
I think the broader point you're trying to make is the bar is very high for a contributor and maintainers have low bandwidth to fully work through all the possible reprocussions of a contribution. I think that's true and it can be spelled out, but I think it's tricky to word it without fully discouraging contributions you know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
plus the first clause
The diversity of workloads, environments, and the scale SIG Node needs to support makes every code change risky
captures that intent
|
||
Read the [Kubernetes Contributor Guide](https://github.com/kubernetes/community/tree/master/contributors/guide#contributor-guide). | ||
|
||
If you aspire to grow scope in the SIG, please review the [SIG Node contributor ladder](./sig-node-contributor-ladder.md) for SIG specific guidance. | ||
|
||
### For Enhancements | ||
|
||
SIG Node enhancements are available in the <https://github.com/kubernetes/enhancements/tree/master/keps/sig-node>. | ||
Find out if [your thing is an enhancement a.k.a KEP](https://github.com/kubernetes/enhancements/?tab=readme-ov-file#is-my-thing-an-enhancement). | ||
A good way to do that is to open and issue and get feedback from node reviewers and approvers. You can even come present your idea at a weekly sig-node meeting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SIG Node* ?
A good way to do that is to open and issue and get feedback from node reviewers and approvers. You can even come present your idea at a weekly sig-node meeting. | ||
|
||
If you plan to contribute an enhancement, please prepare yourself for at least 1 year of engagement. | ||
A KEP takes at least 3 kubernetes releases to move from alpha to beta to GA. If there are API / kubelet skew considerations, it may take even longer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is now 4, as beta is commonly 2 stages now
|
||
If you plan to contribute an enhancement, please prepare yourself for at least 1 year of engagement. | ||
A KEP takes at least 3 kubernetes releases to move from alpha to beta to GA. If there are API / kubelet skew considerations, it may take even longer. | ||
SIG Node expects contributors to commit to land a KEP to GA stage to avoid [permanent betas](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/#avoiding-permanent-beta). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT of
SIG Node expects that contributors commit to taking a KEP to GA stage to avoid
If you plan to contribute an enhancement, please prepare yourself for at least 1 year of engagement. | ||
A KEP takes at least 3 kubernetes releases to move from alpha to beta to GA. If there are API / kubelet skew considerations, it may take even longer. | ||
SIG Node expects contributors to commit to land a KEP to GA stage to avoid [permanent betas](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/#avoiding-permanent-beta). | ||
It is always surprising how much work is needed to productize the feature after it seems complete. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by productize here?
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/sig node
This is in response to https://docs.google.com/document/d/1AavM205LRi-RNB2xQRduzDo_ChTZ8clacKYtgsbfSAQ/edit
Related to #6611