Updated Contributing Documentation for sig/cli by rei-arifi · Pull Request #9167 · kubernetes/community

rei-arifi · 2026-09-16T18:25:57Z

No description provided.

linux-foundation-easycla · 2026-09-16T18:26:04Z

The committers listed above are authorized under a signed CLA.

✅ login: rei-arifi / name: Rei Arifi (95293de)

kubernetes-prow · 2026-09-16T18:26:07Z

Welcome @rei-arifi!

It looks like this is your first PR to kubernetes/community 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/community has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

kubernetes-prow · 2026-09-16T18:26:08Z

Hi @rei-arifi. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

stmcginnis · 2026-09-16T18:36:05Z

/ok-to-test

soltysh · 2026-09-16T18:41:12Z

/assign

Replace feature section with KEP link and contact details

kubernetes-prow · 2026-09-16T19:00:12Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rei-arifi
Once this PR has been reviewed and has the lgtm label, please ask for approval from soltysh. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

sig-cli/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

ardaguclu · 2026-09-17T07:12:40Z

 ### Adopt an issue

 Pick up an [issue] from the backlog by commenting on the issue that you would like to work on it.
-Be sure to mention the author of the issue as well as the SIG cli members `@mpuckett159` and `@ardaguclu`.


This version would be better in my opinion. Maybe you can remove the names and instead mentioning leads.

Yeah, I'd probably suggest asking for the possitiblity to work on a issue, rather than just announcing taking something over. Only when you don't hear for ~2 weeks, I'd say it's ok for you to pick it up. So bring back the previous wording with adjustments as Arda proposed.

ardaguclu · 2026-09-17T07:13:03Z


 **Note:** Don't do this unless you will start work on the issue within a few days of being assigned.

-**Note:** GitHub only allows issues to be assigned to GitHub accounts that are part


I think, this is still correct. We shouldn't remove this.

Yup, bring back.

According to github documentation anyone who has commented on the issue or PR is able to be assigned.

Maybe it's a kubernetes org policy so I'm adding it back, but FYI.

ardaguclu · 2026-09-17T07:13:52Z

 **Summary**:

 - Don't pick up an issue until you are ready to start working on it
- When you want to pick up an issue, be sure to comment `@mpuckett159` and `@ardaguclu`.


This version is better.

I'm confused. Above it looks like you suggested to drop the names. What is the suggested change here?

ardaguclu · 2026-09-17T07:15:20Z

-6. Implement the code per discussion in [bug lifecycle][bug].
-7. Update [kubectl docs].
+6. Implement the code per discussion in [bug lifecycle][bug]. // XXX -> BROKEN_LINK Maybe outdated process?
+7. Update [kubectl docs]. // XXX -> ENRICH Maybe need to add a link to the process on how to update the docs? It's not clear how to properly link PRs between the 2 repos.


This can be used https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

Sorry again. Can you please clarify?
You pointed to a page that hosts generated kubectl commands documentation, but in this context wouldn't it be better to point to some documentation (or implementation) of how this document is generated?

ardaguclu · 2026-09-17T07:18:02Z


 If an issue isn't getting any attention and is unresolved, mention
-`@kubernetes/sig-cli-feature-requests`.
+`@kubernetes/sig-cli-feature-requests`. // XXX -> DECISION_WHO_TO_MENTION


This PR does not have to fully update the file. We can focus on what we have and merge it. We can leave the rest as is, if we are not sure what we should add.

In my opinion, we can remove all these TODOs.

Agreed, especially that we have processes in place to handle incoming volume of issues and PRs. The only escalation path I'd consider is pinging folks on slack, if we don't have that we can mention that.

soltysh

Overall, I'd say try to not repeat information that is linked from this doc already. It's easier when this document will focus ONLY on the sig-cli specific elements, rather than overall PR/KEP/etc processes.

soltysh · 2026-09-17T14:25:53Z

Throughout the doc you can fix to always refer as SIG CLI

soltysh · 2026-09-17T14:27:06Z

Drop this note.

soltysh · 2026-09-17T14:28:31Z

 ### Adopt an issue

 Pick up an [issue] from the backlog by commenting on the issue that you would like to work on it.
-Be sure to mention the author of the issue as well as the SIG cli members `@mpuckett159` and `@ardaguclu`.


Yeah, I'd probably suggest asking for the possitiblity to work on a issue, rather than just announcing taking something over. Only when you don't hear for ~2 weeks, I'd say it's ok for you to pick it up. So bring back the previous wording with adjustments as Arda proposed.

soltysh · 2026-09-17T14:38:16Z

 any PRs are sent for code review.

-1. Identify a problem by filing an [issue] (mention `@kubernetes/sig-cli-feature-requests`).
-2. Submit a [design proposal] and get it approved by a lead.


I liked this version more, what would be more beneficial is changing the order. Such that:

identify problem

bring this to sig-cli call

get approval from leads

start working on KEP

soltysh · 2026-09-17T14:42:16Z

- mention the issue of the associated design proposal,
- mention `@kubernetes/sig-cli-pr-reviews`,
+- mention the issue of the associated [KEP][KEP README],
+- mention `@kubernetes/sig-cli-pr-reviews`, // XXX -> GROUP_REPLACE_WITH_LABEL


No need for label, we triage issues regularly.

soltysh · 2026-09-17T14:43:03Z


 If an issue isn't getting any attention and is unresolved, mention
-`@kubernetes/sig-cli-feature-requests`.
+`@kubernetes/sig-cli-feature-requests`. // XXX -> DECISION_WHO_TO_MENTION


Agreed, especially that we have processes in place to handle incoming volume of issues and PRs. The only escalation path I'd consider is pinging folks on slack, if we don't have that we can mention that.

soltysh · 2026-09-17T14:43:44Z

-[feature]: https://github.com/kubernetes/features
 [group]: https://groups.google.com/a/kubernetes.io/g/sig-cli
-[issue]: https://github.com/kubernetes/kubectl/issues?q=is%3Aissue%20state%3Aopen%20label%3Apriority%2Fbacklog
+[issue]: https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue%20state%3Aopen%20label%3Asig%2Fcli


That was correct, we want all issues be reported against https://github.com/kubernetes/kubectl not k/k.

Co-authored-by: Maciej Szulik <soltysh@gmail.com>

Kubernetes Contributor Guide link change revert Change wording on suggested process of how to get assigned to an issue. Drop issue size section Wording changes related to KEPs Remove all markers Update feature lifecycle section Issue link change revert

update documentation

95293de

kubernetes-prow Bot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 16, 2026

kubernetes-prow Bot requested review from ardaguclu and mpuckett159 September 16, 2026 18:26

kubernetes-prow Bot added sig/cli Categorizes an issue or PR as relevant to SIG CLI. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Sep 16, 2026

Add back the PR sizing label

ae699db

kubernetes-prow Bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 16, 2026

kubernetes-prow Bot assigned soltysh Sep 16, 2026

Direct users to sig-cli calls for finding their first issue

0b26d55

Replace feature section with KEP link and contact details

rei-arifi added 2 commits September 16, 2026 22:14

Update contributor guide link

767e63b

remove unused links

09ec26a

ardaguclu reviewed Sep 17, 2026

View reviewed changes

soltysh reviewed Sep 17, 2026

View reviewed changes

rei-arifi and others added 3 commits September 18, 2026 15:21

Apply suggestion from @soltysh

b9f88a9

Co-authored-by: Maciej Szulik <soltysh@gmail.com>

add removed note

0328cae


		Note: Don't do this unless you will start work on the issue within a few days of being assigned.

		Note: GitHub only allows issues to be assigned to GitHub accounts that are part

Conversation

rei-arifi commented Sep 16, 2026

Uh oh!

linux-foundation-easycla Bot commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kubernetes-prow Bot commented Sep 16, 2026

Uh oh!

kubernetes-prow Bot commented Sep 16, 2026

Uh oh!

stmcginnis commented Sep 16, 2026

Uh oh!

soltysh commented Sep 16, 2026

Uh oh!

kubernetes-prow Bot commented Sep 16, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

soltysh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

linux-foundation-easycla Bot commented Sep 16, 2026 •

edited

Loading