Reorganize docs contrib guide (#9510)

* 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.

content/en/docs/contribute/advanced.md

@@ -0,0 +1,87 @@
+---
+title: Advanced contributing
+slug: advanced
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+This page assumes that you've read and mastered the
+[Start contributing](/docs/contribute/start/) and
+[Intermediate contributing](/docs/contribute/intermediate/) 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](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+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](/docs/contribute/intermediate/) 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](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+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](https://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](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 %}}
+