Misty Linville
5ae0d0dd8d
* Reorganize docs contrib guide * Address first round of feedback from Brad, Jared * Standardize on 'SIG Docs' * Address more feedback * Rewrites to participating.md * Tweak navigation titles * Document PR Wrangler * Document SIG Docs chairperson * Fix codeblock that shows how to use <codenew> It was being interpreted as a Hugo shortcode.
3.9 KiB
title, slug, content_template, weight
| title | slug | content_template | weight |
|---|---|---|---|
| Advanced contributing | advanced | templates/concept | 30 |
{{% capture overview %}}
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.
{{% /capture %}}
{{% capture body %}}
Be the PR Wrangler for a week
SIG Docs approvers are added to the PR Wrangler rotation scheduler for weekly rotations. The PR wrangler's duties include:
- Review incoming pull requests daily.
- Help new contributors sign the CLA, and 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.
- Provide feedback on proposed changes, including helping facilitate technical review from members of other SIGs.
- Merge PRs when they are ready, or close PRs that shouldn't be accepted.
- Triage and tag incoming issues daily. See Intermediate contributing for guidelines about how SIG Docs uses metadata.
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
kubernetes.slack.com
After 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.
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:
- Monitor the feature-tracking spreadsheet for new or changed features with an impact on documentation. If documentation for a given feature won't be ready for the release, the feature may not be allowed to go into the release.
- Attend sig-release meetings regularly and give updates on the status of the docs for the release.
- Review and copyedit feature documentation drafted by the sig responsible for implementing the feature.
- Merge release-related pull requests and maintain the Git feature branch for the release.
- Mentor other SIG Docs contributors who want to learn how to do this role in the future. This is known as "shadowing".
- Publish the documentation changes related to the release when the release artifacts are published.
Coordinating a release is typically a 3-4 month commitment, and the duty is rotated among SIG Docs approvers.
{{% /capture %}}