This page assumes that you’ve read and mastered the Start contributing and Intermediate contributing topics and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks.
The PR wrangler’s duties include:
size/XS) first, then iterate towards the largest (
reviewers:block in the file’s front matter.
Tech Reviewlabels to indicate the PR’s review status.
Needs Doc Reviewor
Needs Tech Reviewfor PRs that haven’t yet been reviewed.
Doc Review: Open Issuesor
Tech Review: Open Issuesfor PRs that have been reviewed and require further input or action before merging.
/approvelabels to PRs that can be merged.
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
reviewed is usually small. These queries specifically exclude localization PRs, and only include the
master branch (except for the last one).
dev-branch, it’s for an upcoming release. Make sure the release meister knows about it by adding a comment with
/assign @<meister's_github-username>. If it’s against an old branch, help the PR author figure out whether it’s targeted against the best branch.
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
Close any PR where the CLA hasn’t been signed for two weeks. PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
Don’t be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
To close a pull request, leave a
/close comment on the PR.
Note: An automated service,
fejta-botautomatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
SIG Docs members can propose improvements.
After you’ve been contributing to the Kubernetes documentation for a while, you
may have ideas for improvement to the style guide, the toolchain used to build
the documentation, the website style, the processes for reviewing and merging
pull requests, or other aspects of the documentation. For maximum transparency,
these types of proposals need to be discussed in a SIG Docs meeting or on the
kubernetes-sig-docs mailing list.
In addition, it can really help to have some context about the way things
currently work and why past decisions have been made before proposing sweeping
changes. The quickest way to get answers to questions about how the documentation
currently works is to ask in the
#sig-docs Slack channel on
After the discussion has taken place and the SIG is in agreement about the desired outcome, you can work on the proposed changes in the way that is the most appropriate. For instance, an update to the style guide or the website’s functionality might involve opening a pull request, while a change related to documentation testing might involve working with sig-testing.
SIG Docs approvers can coordinate docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the sig-release Special Interest Group (SIG). Others on the release team for a given release include an overall release lead, as well as representatives from sig-pm, sig-testing, and others. To find out more about Kubernetes release processes, refer to https://github.com/kubernetes/sig-release.
The SIG Docs representative for a given release coordinates the following tasks:
Coordinating a release is typically a 3-4 month commitment, and the duty is rotated among SIG Docs approvers.
SIG Docs approvers can serve as New Contributor Ambassadors.
New Contributor Ambassadors work together to welcome new contributors to SIG-Docs, suggest PRs to new contributors, and mentor new contributors through their first few PR submissions.
Responsibilities for New Contributor Ambassadors include:
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the Kubernetes #sig-docs channel.
SIG Docs reviewers can sponsor new contributors.
After a new contributor has successfully submitted 5 substantive pull requests to one or more Kubernetes repositories, they are eligible to apply for membership in the Kubernetes organization. The contributor’s membership needs to be backed by two sponsors who are already reviewers.
New docs contributors can request sponsors by asking in the #sig-docs channel on the Kubernetes Slack instance or on the SIG Docs mailing list. If you feel confident about the applicant’s work, you volunteer to sponsor them. When they submit their membership application, reply to the application with a “+1” and include details about why you think the applicant is a good fit for membership in the Kubernetes organization.
SIG Docs approvers can serve a term as a co-chair of SIG Docs.
Approvers must meet the following requirements to be a co-chair:
The role of co-chair is primarily one of service: co-chairs handle process and policy, schedule and run meetings, schedule PR wranglers, and generally do the things that no one else wants to do in order to build contributor capacity.
To schedule and run effective meetings, these guidelines show what to do, how to do it, and why.
Uphold the community code of conduct:
Set a clear agenda:
For weekly meetings, copypaste the previous week’s notes into the “Past meetings” section of the notes
Collaborate on accurate notes:
Assign action items clearly and accurately:
Moderate as needed:
Honor folks’ time:
Use Zoom effectively:
When you’re ready to start the recording, click Record to Cloud.
When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.