Hugo: Fix participating page (#8565)
The page was wrongly formatted: * Two lists were shown as paragraphs, add empty lines so that they are parsed as lists. * The list of members, reviewers was not intended properly, so that the single items are intended but not their description. Indent everything. * Fix URL to owners.md file, the old one gives a 404.
This commit is contained in:
Andreas Jaeger
k8s-ci-robot
parent
396819221b
commit
3f403d5dc3
|
|
@ -25,48 +25,48 @@ Kubernetes org members, and reviewers and approvers for SIG Docs can add comment
|
|||
|
||||
- Members
|
||||
|
||||
Any member of the [Kubernetes organization](https://github.com/kubernetes) can review a pull request, and SIG Docs team members frequently request reviews from members of other SIGs for technical accuracy.
|
||||
SIG Docs also welcomes reviews and feedback regardless of Kubernetes org membership.
|
||||
You can indicate your approval by adding a comment of `/lgtm` to a pull request.
|
||||
Any member of the [Kubernetes organization](https://github.com/kubernetes) can review a pull request, and SIG Docs team members frequently request reviews from members of other SIGs for technical accuracy.
|
||||
SIG Docs also welcomes reviews and feedback regardless of Kubernetes org membership.
|
||||
You can indicate your approval by adding a comment of `/lgtm` to a pull request.
|
||||
|
||||
- Reviewers
|
||||
|
||||
Reviewers are individuals who review documentation pull requests.
|
||||
Reviewers are individuals who review documentation pull requests.
|
||||
|
||||
Automation assigns reviewers to pull requests, and contributors can request a review with a comment on the pull request: `/assign [@_github_handle]`.
|
||||
To indicate that a pull request requires no further changes, a reviewer should add comment to the pull request `/lgtm`.
|
||||
A reviewer indicates technical accuracy with a `/lgtm` comment.
|
||||
Automation assigns reviewers to pull requests, and contributors can request a review with a comment on the pull request: `/assign [@_github_handle]`.
|
||||
To indicate that a pull request requires no further changes, a reviewer should add comment to the pull request `/lgtm`.
|
||||
A reviewer indicates technical accuracy with a `/lgtm` comment.
|
||||
|
||||
Reviewers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
Reviewers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
|
||||
When a reviewer is assigned a pull request to review it is not a sole responsibility, and any other reviewer may also offer their opinions on the pull request.
|
||||
If a reviewer is requested, it is generally expected that the PR will be left to that reviewer to do their editorial pass on the content.
|
||||
If a PR author or SIG Docs maintainer requests a review, refrain from merging or closing the PR until the requested reviewer completes their review.
|
||||
When a reviewer is assigned a pull request to review it is not a sole responsibility, and any other reviewer may also offer their opinions on the pull request.
|
||||
If a reviewer is requested, it is generally expected that the PR will be left to that reviewer to do their editorial pass on the content.
|
||||
If a PR author or SIG Docs maintainer requests a review, refrain from merging or closing the PR until the requested reviewer completes their review.
|
||||
|
||||
- Approvers
|
||||
|
||||
Approvers have the ability to merge a PR.
|
||||
Approvers have the ability to merge a PR.
|
||||
|
||||
Approvers can indicate their approval with a comment to the pull request: `/approve`.
|
||||
An approver is indicating editorial approval with the an `/approve` comment.
|
||||
Approvers can indicate their approval with a comment to the pull request: `/approve`.
|
||||
An approver is indicating editorial approval with the an `/approve` comment.
|
||||
|
||||
Approvers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
Approvers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
|
||||
Approvers may skip further reviews for small pull requests if the proposed changes appear trivial and/or well-understood.
|
||||
An approver can indicate `/lgtm` or `/approve` in a PR comment to have a pull request merged, and all pull requests require at least one approver to provide their vote in order for the PR to be merged.
|
||||
Approvers may skip further reviews for small pull requests if the proposed changes appear trivial and/or well-understood.
|
||||
An approver can indicate `/lgtm` or `/approve` in a PR comment to have a pull request merged, and all pull requests require at least one approver to provide their vote in order for the PR to be merged.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** There is a special case when an approver uses the comment: `/lgtm`. In these cases, the automation will add both `lgtm` and `approve` tags, skipping any further review.
|
||||
{{< /note >}}
|
||||
{{< note >}}**Note:** There is a special case when an approver uses the comment: `/lgtm`. In these cases, the automation will add both `lgtm` and `approve` tags, skipping any further review.
|
||||
{{< /note >}}
|
||||
|
||||
For PRs that require no review (typos or otherwise trivial changes), approvers can enter an `lgtm` comment, indicating no need for further review and flagging the PR with approval to merge.
|
||||
For PRs that require no review (typos or otherwise trivial changes), approvers can enter an `lgtm` comment, indicating no need for further review and flagging the PR with approval to merge.
|
||||
|
||||
### Teams and groups within SIG Docs
|
||||
|
||||
You can get an overview of [SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs).
|
||||
The SIG Docs group defines two teams on Github:
|
||||
|
||||
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
|
||||
|
|
@ -76,16 +76,18 @@ Both can be referenced with their `@name` in github comments to communicate with
|
|||
These teams overlap, but do not exactly match, the groups used by the automation tooling.
|
||||
For assignment of issues, pull requests, and to support PR approvals, the automation uses information from the OWNERS file.
|
||||
|
||||
To volunteer as a reviewer or approver, make a pull request and add your Github handle to the relevant section in the [OWNERS file](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md).
|
||||
To volunteer as a reviewer or approver, make a pull request and add your Github handle to the relevant section in the [OWNERS file](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Reviewers and approvers must meet requirements for participation.
|
||||
For more information, see the [Kubernetes community](https://github.com/kubernetes/community/blob/master/community-membership.md#membership) repository.
|
||||
{{< /note >}}
|
||||
|
||||
Documentation for the [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md) explains how to maintain OWNERS for each repository that enables it.
|
||||
Documentation for the [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
|
||||
explains how to maintain OWNERS for each repository that enables it.
|
||||
|
||||
The [Kubernetes website repository](https://github.com/kubernetes/website) has two automation (prow) [plugins enabled](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
|
||||
|
||||
- blunderbuss
|
||||
- approve
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue