From a371ff33cee8567b9216dca77d6d8c9515a263e1 Mon Sep 17 00:00:00 2001 From: kerthcet Date: Fri, 12 May 2023 22:15:52 +0800 Subject: [PATCH 1/3] Add CONTRIBUTING to sig scheduling Signed-off-by: kerthcet --- sig-scheduling/CONTRIBUTING.md | 77 ++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 sig-scheduling/CONTRIBUTING.md diff --git a/sig-scheduling/CONTRIBUTING.md b/sig-scheduling/CONTRIBUTING.md new file mode 100644 index 00000000000..c6f3fbefa80 --- /dev/null +++ b/sig-scheduling/CONTRIBUTING.md @@ -0,0 +1,77 @@ +# Contributing to SIG Scheduling + +Welcome to contributing to SIG Scheduling. We are excited about the prospect of you +joining our [community](https://github.com/kubernetes/community/tree/master/sig-scheduling)! + +SIG Scheduling is responsible for the components that make Pod placement decisions. +You can read the SIG mission outlined in the [charter](https://git.k8s.io/community/sig-cluster-lifecycle/charter.md). + +We have multi areas you can contribute to, PRs, issues, documentations, new ideas, +helping to answer end-user's questions, attending meetings, all kinds of contributions are welcomed. + +## Before you begin + +We strongly recommend you to check out the [Kubernetes Contributor Guide](https://github.com/kubernetes/community/tree/master/contributors/guide) +and [Contributor Cheat Sheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet). + +## Getting Started + +* If you're a newcomer and have no idea where to start, we have a non-stale pool of issues that are +available for you: + * [first-good-issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+label%3Asig%2Fscheduling+) + * [help wanted](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+label%3Asig%2Fscheduling+) + +* If you want to understand the architectural details of scheduler, you can refer to the [design docs](https://github.com/kubernetes/community/tree/master/contributors/devel/sig-scheduling) + or [KEPs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling). + +* If you have any questions, you can find us in the [slack](https://app.slack.com/client/T09NY5SBT/C09TP78DV). + +* If you find a bug, please open an issue under kubernetes/kubernetes with labels `/sig scheduling` and `/kind bug`, +also follow the requirements of `Bug Report`, it will help us a lot when analyzing the errors. + +* If you have a feature request: + * Open an issue under kubernetes/kubernetes with labels `/sig scheduling` and `/kind feature`, please focus on + the user stories + * If there's any debate on the rationalities, you can bring it to the [SIG meeting](https://github.com/kubernetes/community/tree/master/sig-scheduling#meetings). + * If there're multiple implementation options, consider to create a doc with Pros and Cons, and gather some feedbacks. + * If necessary, open an issue in kubernetes/enhancements and write a KEP for it. + +* If you find any out-of-date documentations, please help us to revise that, the readers come latter +will be grateful for your kindness. + +* We also maintain a list of [sub projects](https://github.com/kubernetes/community/tree/master/sig-scheduling#subprojects) here, +if you're interest, you can contribute to them at your wish. + +## Best Practices + +From years contributions to the Kubernetes, we summarized several practices here: + +* In general, PR should be reviewed by the Reviewers firstly, once it got a `/lgtm`, + approvers will get onboard. This helps to reduce the burden on the Approvers. + +* Leave the Reviewers assigned by the bot automatically if possible, unless there is a need +for one specific contributor's expertise. + +* Critical bug fixes can be assigned to approvers directly. + +* Always add a new commit to address review comments, instead of amending, this helps to +review the new changes unless you're asked by the Reviewer or it's ready to merge. + +* Squash the commits when PR is ready to merge, this does a great favor for the git history. + +* Code contributions should be relatively small, simple, well documented and well tested. + +* Whatever discussed offline or at the community meeting should be recorded back +to the issue/PR, which helps to preserve the context. + +* Always open an issue for a TODO or a follow-up just in case you forget it. + +## Use of @mentions + +* @kubernetes/sig-scheduling-api-reviews - API Changes and Reviews +* @kubernetes/sig-scheduling-bugs - Bug Triage and Troubleshooting +* @kubernetes/sig-scheduling-feature-requests - Feature Requests +* @kubernetes/sig-scheduling-misc - General Discussion +* @kubernetes/sig-scheduling-pr-reviews - PR Reviews +* @kubernetes/sig-scheduling-proposals - Design Proposals +* @kubernetes/sig-scheduling-test-failures - Test Failures and Triage From 9f5e89da0078ede885c5924a76c1667b5ab298ae Mon Sep 17 00:00:00 2001 From: kerthcet Date: Mon, 15 May 2023 12:35:07 +0800 Subject: [PATCH 2/3] address comments Signed-off-by: kerthcet --- sig-scheduling/CONTRIBUTING.md | 37 +++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/sig-scheduling/CONTRIBUTING.md b/sig-scheduling/CONTRIBUTING.md index c6f3fbefa80..eba5f01a941 100644 --- a/sig-scheduling/CONTRIBUTING.md +++ b/sig-scheduling/CONTRIBUTING.md @@ -6,13 +6,13 @@ joining our [community](https://github.com/kubernetes/community/tree/master/sig- SIG Scheduling is responsible for the components that make Pod placement decisions. You can read the SIG mission outlined in the [charter](https://git.k8s.io/community/sig-cluster-lifecycle/charter.md). -We have multi areas you can contribute to, PRs, issues, documentations, new ideas, -helping to answer end-user's questions, attending meetings, all kinds of contributions are welcomed. +There are multiple ways you can participate, including PRs, issues, documentation, new proposals, +helping to answer end-user's questions, attending meetings. All kinds of contributions are welcomed. ## Before you begin We strongly recommend you to check out the [Kubernetes Contributor Guide](https://github.com/kubernetes/community/tree/master/contributors/guide) -and [Contributor Cheat Sheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet). +and [Contributor Cheat Sheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) first. ## Getting Started @@ -21,10 +21,12 @@ available for you: * [first-good-issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+label%3Asig%2Fscheduling+) * [help wanted](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+label%3Asig%2Fscheduling+) -* If you want to understand the architectural details of scheduler, you can refer to the [design docs](https://github.com/kubernetes/community/tree/master/contributors/devel/sig-scheduling) +* If you want to know how kube-scheduler generally works, you can read the [scheduling-eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/). + +* If you want to understand the architectural details of kube-scheduler, you can refer to the [design docs](https://github.com/kubernetes/community/tree/master/contributors/devel/sig-scheduling) or [KEPs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling). -* If you have any questions, you can find us in the [slack](https://app.slack.com/client/T09NY5SBT/C09TP78DV). +* If you have any questions, you can find us in the Kubernetes [slack](https://app.slack.com/client/T09NY5SBT/C09TP78DV). * If you find a bug, please open an issue under kubernetes/kubernetes with labels `/sig scheduling` and `/kind bug`, also follow the requirements of `Bug Report`, it will help us a lot when analyzing the errors. @@ -33,33 +35,36 @@ also follow the requirements of `Bug Report`, it will help us a lot when analyzi * Open an issue under kubernetes/kubernetes with labels `/sig scheduling` and `/kind feature`, please focus on the user stories * If there's any debate on the rationalities, you can bring it to the [SIG meeting](https://github.com/kubernetes/community/tree/master/sig-scheduling#meetings). - * If there're multiple implementation options, consider to create a doc with Pros and Cons, and gather some feedbacks. - * If necessary, open an issue in kubernetes/enhancements and write a KEP for it. + * If there're multiple implementation options, consider to create a doc with Pros and Cons, and gather some feedback. + * If necessary, open an issue in kubernetes/enhancements and write a [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling) for it. -* If you find any out-of-date documentations, please help us to revise that, the readers come latter +* If you find any out-of-date documentation, please help us to revise that. Future readers will be grateful for your kindness. + * For website documentation, you can open issues at [kubernetes/website](https://github.com/kubernetes/website). + * For developer documentation, you can open issues at [kubernetes/community](https://github.com/kubernetes/community). -* We also maintain a list of [sub projects](https://github.com/kubernetes/community/tree/master/sig-scheduling#subprojects) here, -if you're interest, you can contribute to them at your wish. +* We also maintain a list of [sub projects](https://github.com/kubernetes/community/tree/master/sig-scheduling#subprojects) here. +If you're interested, you can contribute to them as well. ## Best Practices -From years contributions to the Kubernetes, we summarized several practices here: +From years of contributions to the Kubernetes, we have summarized the following practices: -* In general, PR should be reviewed by the Reviewers firstly, once it got a `/lgtm`, - approvers will get onboard. This helps to reduce the burden on the Approvers. +* In general, PR should be reviewed by the [Reviewers](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer) first. Once the PR gets a `/lgtm` from Reviewers, + [Approvers](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) will get onboard. This helps to reduce the burden on the Approvers. * Leave the Reviewers assigned by the bot automatically if possible, unless there is a need for one specific contributor's expertise. * Critical bug fixes can be assigned to approvers directly. -* Always add a new commit to address review comments, instead of amending, this helps to -review the new changes unless you're asked by the Reviewer or it's ready to merge. +* Always add a new commit to address review comments, instead of amending. This helps to +review the new changes. You might be asked by the Reviewer to squash at a certain point. * Squash the commits when PR is ready to merge, this does a great favor for the git history. * Code contributions should be relatively small, simple, well documented and well tested. +Try to split your changes into incremental PRs if the feature is big. * Whatever discussed offline or at the community meeting should be recorded back to the issue/PR, which helps to preserve the context. @@ -71,7 +76,7 @@ to the issue/PR, which helps to preserve the context. * @kubernetes/sig-scheduling-api-reviews - API Changes and Reviews * @kubernetes/sig-scheduling-bugs - Bug Triage and Troubleshooting * @kubernetes/sig-scheduling-feature-requests - Feature Requests -* @kubernetes/sig-scheduling-misc - General Discussion +* @kubernetes/sig-scheduling-misc - General Discussion from Approvers and Reviewers * @kubernetes/sig-scheduling-pr-reviews - PR Reviews * @kubernetes/sig-scheduling-proposals - Design Proposals * @kubernetes/sig-scheduling-test-failures - Test Failures and Triage From 68966e51a1b1df83921d7e4b9d663e59995a4100 Mon Sep 17 00:00:00 2001 From: kerthcet Date: Tue, 16 May 2023 11:18:13 +0800 Subject: [PATCH 3/3] address comments Signed-off-by: kerthcet --- sig-scheduling/CONTRIBUTING.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/sig-scheduling/CONTRIBUTING.md b/sig-scheduling/CONTRIBUTING.md index eba5f01a941..e9b3b38e3ce 100644 --- a/sig-scheduling/CONTRIBUTING.md +++ b/sig-scheduling/CONTRIBUTING.md @@ -35,11 +35,12 @@ also follow the requirements of `Bug Report`, it will help us a lot when analyzi * Open an issue under kubernetes/kubernetes with labels `/sig scheduling` and `/kind feature`, please focus on the user stories * If there's any debate on the rationalities, you can bring it to the [SIG meeting](https://github.com/kubernetes/community/tree/master/sig-scheduling#meetings). - * If there're multiple implementation options, consider to create a doc with Pros and Cons, and gather some feedback. + * If there are multiple implementation options, consider creating a doc with Pros and Cons, and gather some feedback. + You can do this by sharing the doc with the SIG's [mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-scheduling). * If necessary, open an issue in kubernetes/enhancements and write a [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling) for it. -* If you find any out-of-date documentation, please help us to revise that. Future readers -will be grateful for your kindness. +* If you find any out-of-date documentation, please help the community correct that by either sending a PR to +update the docs or open an issue if you are not sure about how to fix it. * For website documentation, you can open issues at [kubernetes/website](https://github.com/kubernetes/website). * For developer documentation, you can open issues at [kubernetes/community](https://github.com/kubernetes/community). @@ -48,20 +49,20 @@ If you're interested, you can contribute to them as well. ## Best Practices -From years of contributions to the Kubernetes, we have summarized the following practices: +The community has been following some practices to help ensure maintainable and quality code: -* In general, PR should be reviewed by the [Reviewers](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer) first. Once the PR gets a `/lgtm` from Reviewers, - [Approvers](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) will get onboard. This helps to reduce the burden on the Approvers. +* It is best if a PR is first reviewed by the [Reviewers](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer). Once the PR gets a `/lgtm` from a Reviewer, + [Approvers](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) will review the PR to approve it. * Leave the Reviewers assigned by the bot automatically if possible, unless there is a need -for one specific contributor's expertise. +for a specific contributor's expertise. * Critical bug fixes can be assigned to approvers directly. -* Always add a new commit to address review comments, instead of amending. This helps to +* Always add a new commit to address review comments instead of amending. This helps to review the new changes. You might be asked by the Reviewer to squash at a certain point. -* Squash the commits when PR is ready to merge, this does a great favor for the git history. +* Squash the commits when the PR is ready to merge, this does a great favor for the git history. * Code contributions should be relatively small, simple, well documented and well tested. Try to split your changes into incremental PRs if the feature is big.