Participating in SIG Docs

    SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to file issues about content or comment on pull requests in progress.

    You can also become a member, , or approver. These roles require greater access and entail certain responsibilities for approving and committing changes. See for more information on how membership works within the Kubernetes community.

    The rest of this document outlines some unique ways these roles function within SIG Docs, which is responsible for maintaining one of the most public-facing aspects of Kubernetes — the Kubernetes website and documentation.

    Each SIG, including SIG Docs, selects one or more SIG members to act as chairpersons. These are points of contact between SIG Docs and other parts of the Kubernetes organization. They require extensive knowledge of the structure of the Kubernetes project as a whole and how SIG Docs works within it. See Leadership for the current list of chairpersons.

    There are two categories of SIG Docs on GitHub:

    • are approvers and leads
    • @sig-docs-{language}-reviewers are reviewers

    Each can be referenced with their @name in GitHub comments to communicate with everyone in that group.

    Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals, the automation uses information from OWNERS files.

    OWNERS files and front-matter

    The Kubernetes project uses an automation tool called prow for automation related to GitHub issues and pull requests. The uses two prow plugins:

    • blunderbuss

    An OWNERS file contains a list of people who are SIG Docs reviewers and approvers. OWNERS files can also exist in subdirectories, and can override who can act as a reviewer or approver of files in that subdirectory and its descendants. For more information about OWNERS files in general, see .

    In addition, an individual Markdown file can list reviewers and approvers in its front-matter, either by listing individual GitHub usernames or GitHub groups.

    The combination of OWNERS files and front-matter in Markdown files determines the advice PR owners get from automated systems about who to ask for technical and editorial review of their PR.

    When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that the quality of our published content is high, we limit merging pull requests to SIG Docs approvers. Here’s how it works.

    • When a pull request has both the lgtm and approve labels, has no hold labels, and all tests are passing, the pull request merges automatically.
    • Kubernetes organization members and SIG Docs approvers can add comments to prevent automatic merging of a given pull request (by adding a comment or withholding a /lgtm comment).
    • Any Kubernetes member can add the lgtm label by adding a /lgtm comment.
    • Only SIG Docs approvers can merge a pull request by adding an comment. Some approvers also perform additional specific roles, such as or SIG Docs chairperson.
    Roles and responsibilities
    PR wranglers