[zh] Sync contribution changes (1)
There have been some significant changes to the contribution guide. This PR is one of the series that sync the changes to Chinese localization.
This commit is contained in:
@@ -0,0 +1,225 @@
|
||||
---
|
||||
title: 参与 SIG Docs
|
||||
content_type: concept
|
||||
weight: 60
|
||||
card:
|
||||
name: contribute
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
title: Participating in SIG Docs
|
||||
content_type: concept
|
||||
weight: 60
|
||||
card:
|
||||
name: contribute
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
SIG Docs is one of the
|
||||
[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
|
||||
within the Kubernetes project, focused on writing, updating, and maintaining
|
||||
the documentation for Kubernetes as a whole. See
|
||||
[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
|
||||
for more information about the SIG.
|
||||
-->
|
||||
SIG Docs 是 Kubernetes 项目
|
||||
[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md)
|
||||
中的一个,负责编写、更新和维护 Kubernetes 的总体文档。
|
||||
参见[社区 GitHub 仓库中 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
|
||||
以进一步了解该 SIG。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
SIG Docs 欢迎所有贡献者提供内容和审阅。任何人可以提交拉取请求(PR)。
|
||||
欢迎所有人对文档内容创建 Issue 和对正在处理中的 PR 进行评论。
|
||||
|
||||
<!--
|
||||
You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
|
||||
[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater
|
||||
access and entail certain responsibilities for approving and committing changes.
|
||||
See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
|
||||
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.
|
||||
-->
|
||||
你也可以成为[成员(member)](/docs/contribute/participating/roles-and-responsibilities/#members)、
|
||||
[评阅人(reviewer)](/docs/contribute/participating/roles-and-responsibilities/#reviewers) 或者
|
||||
[批准人(approver)](/docs/contribute/participating/roles-and-responsibilities/#approvers)。
|
||||
这些角色拥有更高的权限,且需要承担批准和提交变更的责任。
|
||||
有关 Kubernetes 社区中的成员如何工作的更多信息,请参见
|
||||
[社区成员身份](https://github.com/kubernetes/community/blob/master/community-membership.md)。
|
||||
|
||||
本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。
|
||||
SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
#### SIG Docs chairperson
|
||||
|
||||
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](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
|
||||
for the current list of chairpersons.
|
||||
-->
|
||||
## SIG Docs 主席
|
||||
|
||||
每个 SIG,包括 SIG Docs,都会选出一位或多位成员作为主席。
|
||||
主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。
|
||||
他们需要了解整个 Kubernetes 项目的架构,并明白 SIG Docs 如何在其中运作。
|
||||
如需查询当前的主席名单,请查阅
|
||||
[领导人员](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。
|
||||
|
||||
<!--
|
||||
## SIG Docs teams and automation
|
||||
|
||||
Automation in SIG Docs relies on two different mechanisms for automation:
|
||||
GitHub groups and OWNERS files.
|
||||
-->
|
||||
## SIG Docs 团队和自动化 {#sig-docs-teams-and-automation}
|
||||
|
||||
SIG 文档中的自动化服务依赖于两种不同的自动化机制:
|
||||
GitHub 组和 OWNERS 文件。
|
||||
|
||||
<!--
|
||||
### GitHub teams
|
||||
|
||||
There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub:
|
||||
|
||||
- `@sig-docs-{language}-owners` 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.
|
||||
-->
|
||||
### GitHub 团队 {#github-teams}
|
||||
|
||||
GitHub 上有两类 SIG Docs 团队:
|
||||
|
||||
- `@sig-docs-{language}-owners` 包含批准人和牵头人
|
||||
- `@sig-docs-{language}-reviewers` 包含评阅人
|
||||
|
||||
可以在 GitHub 的评论中使用团队的名称 `@name` 来与团队成员沟通。
|
||||
|
||||
有时候 Prow 所定义的团队和 GitHub 团队有所重叠,并不完全一致。
|
||||
对于指派 Issue、PR 和批准 PR,自动化工具使用来自 `OWNERS` 文件的信息。
|
||||
|
||||
<!--
|
||||
### OWNERS files and front-matter
|
||||
|
||||
The Kubernetes project uses an automation tool called prow for automation
|
||||
related to GitHub issues and pull requests. The
|
||||
[Kubernetes website repository](https://github.com/kubernetes/website) uses
|
||||
two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins):
|
||||
-->
|
||||
### OWNERS 文件和扉页
|
||||
|
||||
Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。
|
||||
[Kubernetes website 仓库](https://github.com/kubernetes/website) 使用了两个
|
||||
[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins):
|
||||
|
||||
- blunderbuss
|
||||
- approve
|
||||
|
||||
<!--
|
||||
These two plugins use the
|
||||
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
|
||||
files in the top level of the `kubernetes/website` GitHub repository to control
|
||||
how prow works within the repository.
|
||||
-->
|
||||
这两个插件使用位于 `kubernetes/website` 仓库顶层的
|
||||
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) 文件和
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
|
||||
文件来控制 prow 在仓库范围的工作方式。
|
||||
|
||||
<!--
|
||||
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
|
||||
descendents. For more information about OWNERS files in general, see
|
||||
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
|
||||
-->
|
||||
OWNERS 文件包含 SIG Docs 评阅人和批准人的列表。
|
||||
OWNERS 文件也可以存在于子目录中,可以在子目录层级重新设置哪些人可以作为评阅人和
|
||||
批准人,并将这一设定传递到下层子目录。
|
||||
关于 OWNERS 的更多信息,请参考
|
||||
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
|
||||
文档。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
此外,每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人,
|
||||
每一项可以是 GitHub 用户名,也可以是 GitHub 组名。
|
||||
|
||||
结合 OWNERS 文件及 Markdown 文件的前言信息,自动化系统可以给 PR 作者可以就应该
|
||||
向谁请求技术和文字评阅给出建议。
|
||||
|
||||
<!--
|
||||
## How merging works
|
||||
|
||||
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 `/hold` 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 `/approve` comment. Some approvers also perform additional
|
||||
specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
|
||||
[SIG Docs chairperson](#sig-docs-chairperson).
|
||||
-->
|
||||
## PR 是怎样被合并的 {#how-merging-works}
|
||||
|
||||
当某个拉取请求(PR)被合并到用来发布内容的分支,对应的内容就会被发布到 http://kubernetes.io。
|
||||
为了确保我们所发布的内容的质量足够好,合并 PR 的权限仅限于
|
||||
SIG Docs 批准人。下面是合并的工作机制:
|
||||
|
||||
- 当某个 PR 同时具有 `lgtm` 和 `approve` 标签,没有 `hold` 标签且通过所有测试时,
|
||||
该 PR 会被自动合并。
|
||||
- Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并,
|
||||
即通过 `/hold` 评论或者收回某个 `/lgtm` 评论实现这点。
|
||||
- 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。
|
||||
- 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。
|
||||
某些批准人还会执行一些其他角色,例如
|
||||
[PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 或
|
||||
[SIG Docs 主席](#sig-docs-chairperson)等。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
- [Contributing new content](/docs/contribute/overview/)
|
||||
- [Reviewing content](/docs/contribute/review/reviewing-prs)
|
||||
- [Documentation style guide](/docs/contribute/style/)
|
||||
-->
|
||||
关于贡献 Kubernetes 文档的更多信息,请参考:
|
||||
|
||||
- [贡献新内容](/docs/contribute/overview/)
|
||||
- [评阅内容](/docs/contribute/review/reviewing-prs)
|
||||
- [文档样式指南](/docs/contribute/style/)
|
||||
@@ -0,0 +1,409 @@
|
||||
---
|
||||
title: 角色与责任
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
|
||||
These roles allow you to take on more responsibility within the community.
|
||||
Each role requires more time and commitment. The roles are:
|
||||
|
||||
- Anyone: regular contributors to the Kubernetes documentation
|
||||
- Members: can assign and triage issues and provide non-binding review on pull requests
|
||||
- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
|
||||
- Approvers: can lead reviews on documentation and merge changes
|
||||
-->
|
||||
任何人都可以为 Kubernetes 作出贡献。随着你对 SIG Docs 的贡献增多,你可以申请
|
||||
社区内不同级别的成员资格。
|
||||
这些角色使得你可以在社区中承担更多的责任。
|
||||
每个角色都需要更多的时间和投入。具体包括:
|
||||
|
||||
- 任何人(Anyone):为 Kubernetes 文档作出贡献的普通贡献者。
|
||||
- 成员(Members):可以对 Issue 进行分派和判别,对 PR 提出无约束性的评审意见。
|
||||
- 评审人(Reviewers):可以领导对文档 PR 的评审,可以对变更的质量进行判别。
|
||||
- 批准人(Approvers):可以领导对文档的评审并合并变更。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Anyone
|
||||
|
||||
Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
|
||||
|
||||
Anyone can:
|
||||
|
||||
- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
|
||||
- Give non-binding feedback on a pull request
|
||||
- Contribute to a localization
|
||||
- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
|
||||
|
||||
After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
|
||||
|
||||
- Open a pull request to improve existing content, add new content, or write a blog post or case study
|
||||
- Create diagrams, graphics assets, and embeddable screencasts and videos
|
||||
|
||||
For more information, see [contributing new content](/docs/contribute/new-content/).
|
||||
-->
|
||||
## 任何人(Anyone) {#anyone}
|
||||
|
||||
任何拥有 GitHub 账号的人都可以对 Kubernetes 作出贡献。SIG Docs
|
||||
欢迎所有新的贡献者。
|
||||
|
||||
任何人都可以:
|
||||
|
||||
- 在任何 [Kubernetes](https://github.com/kubernetes/) 仓库,包括
|
||||
[`kubernetes/website`](https://github.com/kubernetes/website) 上报告 Issue。
|
||||
- 对某 PR 给出无约束力的反馈信息
|
||||
- 为本地化提供帮助
|
||||
- 在 [Slack](http://slack.k8s.io/) 或
|
||||
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
上提出改进建议。
|
||||
|
||||
在[签署了 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 之后,任何人还可以:
|
||||
|
||||
- 发起拉取请求(PR),改进现有内容、添加新内容、撰写博客或者案例分析
|
||||
- 创建示意图、图形资产或者嵌入式的截屏和视频内容
|
||||
|
||||
进一步的详细信息,可参见[贡献新内容](/zh/docs/contribute/new-content/)。
|
||||
|
||||
<!--
|
||||
## Members
|
||||
|
||||
A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
|
||||
|
||||
Members can:
|
||||
|
||||
- Do everything listed under [Anyone](#anyone)
|
||||
- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
|
||||
|
||||
{{< note >}}
|
||||
Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
|
||||
{{< /note >}}
|
||||
- Use the `/hold` comment to block merging for a pull request
|
||||
- Use the `/assign` comment to assign a reviewer to a pull request
|
||||
- Provide non-binding review on pull requests
|
||||
- Use automation to triage and categorize issues
|
||||
- Document new features
|
||||
-->
|
||||
## 成员(Members) {#members}
|
||||
|
||||
成员是指那些对 `kubernetes/website` 提交很多拉取请求(PR)的人。
|
||||
成员都要加入 [Kubernetes GitHub 组织](https://github.com/kubernetes)。
|
||||
|
||||
成员可以:
|
||||
|
||||
- 执行[任何人](#anyone)节区所列举操作
|
||||
- 使用 `/lgtm` 评论添加 LGTM (looks good to me(我觉得可以)) 标签到某个 PR
|
||||
|
||||
{{< note >}}
|
||||
使用 `/lgtm` 会触发自动化机制。如果你希望提供不拘约束力的批准意见,
|
||||
直接回复 "LGTM" 也是可以的。
|
||||
{{< /note >}}
|
||||
- 利用 `/hold` 评论来阻止某个 PR 被合并
|
||||
- 使用 `/assign` 评论为某个 PR 指定评审人
|
||||
- 对 PR 提供非约束性的评审意见
|
||||
- 使用自动化机制来对 Issue 进行判别和分类
|
||||
- 为新功能特性撰写文档
|
||||
|
||||
<!--
|
||||
### Becoming a member
|
||||
|
||||
After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
|
||||
-->
|
||||
### 成为一个成员 {#becoming-a-member}
|
||||
|
||||
在你成功地提交至少 5 个 PR 并满足
|
||||
[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
|
||||
之后:
|
||||
|
||||
<!--
|
||||
1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
|
||||
|
||||
Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
|
||||
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
|
||||
|
||||
{{< note >}}
|
||||
Don't send a direct email or Slack direct message to an individual
|
||||
SIG Docs member. You must request sponsorship before submitting your application.
|
||||
{{< /note >}}
|
||||
|
||||
2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
|
||||
-->
|
||||
1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供
|
||||
[担保](/docs/contribute/advanced#sponsor-a-new-contributor)。
|
||||
|
||||
通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者
|
||||
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
来寻找为你担保的人。
|
||||
|
||||
{{< note >}}
|
||||
不要单独发送邮件给某个 SIG Docs 成员或在 Slack 中与其私聊。
|
||||
在提交申请之前,一定要先确定担保人。
|
||||
{{< /note >}}
|
||||
|
||||
2. 在 [`kubernetes/org`](https://github.com/kubernetes/org/) 仓库
|
||||
使用 **Organization Membership Request** Issue 模版登记一个 Issue。
|
||||
|
||||
<!--
|
||||
3. Let your sponsors know about the GitHub issue. You can either:
|
||||
- Mention their GitHub username in an issue (`@<GitHub-username>`)
|
||||
- Send them the issue link using Slack or email.
|
||||
|
||||
Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
|
||||
|
||||
If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
|
||||
|
||||
4. Accept the invitation to the Kubernetes GitHub organization in your email account.
|
||||
|
||||
{{< note >}}
|
||||
GitHub sends the invitation to the default email address in your account.
|
||||
{{< /note >}}
|
||||
-->
|
||||
3. 告知你的担保人你所创建的 Issue,你可以:
|
||||
|
||||
- 在 Issue 中 `@<GitHub-username>` 提及他们的 GitHub 用户名
|
||||
- 通过 Slack 或 email 直接发送给他们 Issue 链接
|
||||
|
||||
担保人会通过 `+1` 投票来批准你的请求。一旦你的担保人批准了该请求,
|
||||
某个 Kubernetes GitHub 管理员会将你添加为组织成员。恭喜!
|
||||
|
||||
如果你的成员请求未被接受,你会收到一些反馈。
|
||||
当处理完反馈意见之后,可以再次发起申请。
|
||||
|
||||
4. 在你的邮件账户中接受来自 Kubernetes GitHub 组织发出的成员邀请。
|
||||
|
||||
{{< note >}}
|
||||
GitHub 会将邀请发送到你的账户中所设置的默认邮件地址。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Reviewers
|
||||
|
||||
Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
|
||||
|
||||
Reviewers can:
|
||||
|
||||
- Do everything listed under [Anyone](#anyone) and [Members](#members)
|
||||
- Review pull requests and provide binding feedback
|
||||
|
||||
{{< note >}}
|
||||
To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
|
||||
{{< /note >}}
|
||||
|
||||
- Edit user-facing strings in code
|
||||
- Improve code comments
|
||||
|
||||
You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
|
||||
-->
|
||||
## 评审人(Reviewers) {#reviewers}
|
||||
|
||||
评审人负责评审悬决的 PR。
|
||||
与成员所给的反馈不同,你必须处理评审人的反馈。
|
||||
评审人是 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 团队的成员。
|
||||
|
||||
评审人可以:
|
||||
|
||||
- 执行[任何人](#anyone)和[成员](#members)节所列举的操作
|
||||
- 评审 PR 并提供具约束性的反馈信息
|
||||
|
||||
{{< note >}}
|
||||
要提供非约束性的反馈,可以在你的评语之前添加 "Optionally: " 这样的说法。
|
||||
{{< /note >}}
|
||||
|
||||
- 编辑代码中用户可见的字符串
|
||||
- 改进代码注释
|
||||
|
||||
你可以是 SIG Docs 的评审人,也可以是某个主题领域的文档的评审人。
|
||||
|
||||
<!--
|
||||
### Assigning reviewers to pull requests
|
||||
|
||||
Automation assigns reviewers to all pull requests. You can request a
|
||||
review from a specific person by commenting: `/assign
|
||||
[@_github_handle]`.
|
||||
|
||||
If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
|
||||
|
||||
### Using `/lgtm`
|
||||
|
||||
LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
|
||||
|
||||
A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
|
||||
-->
|
||||
### 为 PR 指派评审人 {#assigning-reviewers-to-pull-requests}
|
||||
|
||||
自动化引擎会为每个 PR 自动指派评审人。
|
||||
你可以通过为 PR 添加评论 `/assign [@_github_handle]` 来请求某个特定评审人来评审。
|
||||
|
||||
如果所指派的评审人未能及时评审,其他的评审人也可以参与进来。
|
||||
你可以根据需要指派技术评审人。
|
||||
|
||||
### 使用 `/lgtm`
|
||||
|
||||
LGTM 代表的是 “Looks Good To Me (我觉得可以)”,用来标示某个 PR
|
||||
在技术上是准确的,可以被合并。
|
||||
所有 PR 都需要来自某评审人的 `/lgtm` 评论和来自某批准人的 `/approve`
|
||||
评论。
|
||||
|
||||
来自评审人的 `/lgtm` 评论是具有约束性的,会触发自动化设施添加 `lgtm` 标签。
|
||||
|
||||
<!--
|
||||
### Becoming a reviewer
|
||||
|
||||
When you meet the
|
||||
[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs.
|
||||
|
||||
To apply:
|
||||
-->
|
||||
### 成为评审人 {#becoming-a-reviewer}
|
||||
|
||||
当你满足[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时,
|
||||
你可以成为一个 SIG Docs 评审人。
|
||||
来自其他 SIG 的评审人必须为 SIG Docs 单独申请评审人资格。
|
||||
|
||||
申请过程如下:
|
||||
|
||||
<!--
|
||||
1. Open a pull request that adds your GitHub user name to a section of the
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
|
||||
in the `kubernetes/website` repository.
|
||||
|
||||
{{ note }}
|
||||
If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
|
||||
{{ /note }}
|
||||
|
||||
2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
|
||||
|
||||
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
|
||||
-->
|
||||
1. 发起 PR,将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
|
||||
文件的特定节。
|
||||
|
||||
{{ note }}
|
||||
如果你不确定要添加到哪个位置,可以将自己添加到 `sig-docs-en-reviews`。
|
||||
{{ /note }}
|
||||
|
||||
2. 将 PR 指派给一个或多个 SIG Docs 批准人(`sig-docs-{language}-owners`
|
||||
下列举的用户名)。
|
||||
|
||||
请求被批准之后,SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。
|
||||
一旦添加完成, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
|
||||
会在处理未来的 PR 时,将 PR 指派给你或者建议你来评审某 PR。
|
||||
|
||||
<!--
|
||||
## Approvers
|
||||
|
||||
Approvers review and approve pull requests for merging. Approvers are members of the
|
||||
[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
|
||||
|
||||
-->
|
||||
## 批准人(Approvers) {#approvers}
|
||||
|
||||
批准人负责评审和批准 PR 以将其合并。
|
||||
批准人是 [@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 团队的成员。
|
||||
|
||||
<!--
|
||||
Approvers can do the following:
|
||||
|
||||
- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
|
||||
- Publish contributor content by approving and merging pull requests using the `/approve` comment
|
||||
- Propose improvements to the style guide
|
||||
- Propose improvements to docs tests
|
||||
- Propose improvements to the Kubernetes website or other tooling
|
||||
|
||||
If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review.
|
||||
-->
|
||||
批准人可以执行以下操作:
|
||||
|
||||
- 执行列举在[任何人](#anyone)、[成员](#members)和[评审人](#reviewers)节区的操作
|
||||
- 通过使用 `/approve` 评论来批准、合并 PRs,发布贡献者所贡献的内容。
|
||||
- 就样式指南给出改进建议
|
||||
- 对文档测试给出改进建议
|
||||
- 对 Kubernetes 网站或其他工具给出改进建议
|
||||
|
||||
如果某个 PR 已有 `/lgtm` 标签,或者批准人再回复一个 `/lgtm` ,则这个 PR 会自动合并。
|
||||
SIG Docs 批准人应该只在不需要额外的技术评审的情况下才可以标记 `/lgtm`。
|
||||
|
||||
<!--
|
||||
### Approving pull requests
|
||||
|
||||
Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
|
||||
|
||||
- Approvers can use the `/approve` command, which merges PRs into the repo.
|
||||
|
||||
{{< warning >}}
|
||||
A careless merge can break the site, so be sure that when you merge something, you mean it.
|
||||
{{< /warning >}}
|
||||
|
||||
- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
|
||||
|
||||
If you ever have a question, or you're not sure about something, feel free to call for additional review.
|
||||
-->
|
||||
### 批准 PR {#approving-pull-requests}
|
||||
|
||||
只有批准人和 SIG Docs Leads 可以将 PR 合并到网站仓库。
|
||||
这意味着以下责任:
|
||||
|
||||
- 批准人可以使用 `/approve` 命令将 PR 合并到仓库中。
|
||||
|
||||
{{< warning >}}
|
||||
不小心的合并可能会破坏整个站点。在执行合并操作时,务必小心。
|
||||
{{< /warning >}}
|
||||
|
||||
- 确保所提议的变更满足[贡献指南](/docs/contribute/style/content-guide/#contributing-content)要求
|
||||
|
||||
如果有问题或者疑惑,可以根据需要请他人帮助评审。
|
||||
|
||||
- 在 `/approve` PR 之前,须验证 Netlify 测试是否正常通过。
|
||||
|
||||
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须通过 Netlify 测试" />
|
||||
|
||||
- 在批准之前,请访问 Netlify 的页面预览来确保变更内容可正常显示。
|
||||
|
||||
- 参与 [PR 管理者轮值排班](https://github.com/kubernetes/website/wiki/PR-Wranglers)
|
||||
执行时长为一周的 PR 管理。SIG Docs 期望所有批准人都参与到此轮值工作中。
|
||||
更多细节可参见[做一周的 PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)。
|
||||
|
||||
<!--
|
||||
### Becoming an approver
|
||||
|
||||
When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
|
||||
-->
|
||||
### 成为批准人 {#becoming-an-approver}
|
||||
|
||||
当你满足[一定条件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)时,可以成为一个 SIG Docs 批准人。
|
||||
来自其他 SIGs 的批准人也必须在 SIG Docs 独立申请批准人资格。
|
||||
|
||||
<!--
|
||||
To apply:
|
||||
|
||||
1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
|
||||
|
||||
{{ note }}
|
||||
If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
|
||||
{{ /note }}
|
||||
|
||||
2. Assign the PR to one or more current SIG Docs approvers.
|
||||
|
||||
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
|
||||
-->
|
||||
申请流程如下:
|
||||
|
||||
1. 发起一个 PR,将自己添加到 `kubernetes/website` 仓库中
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
|
||||
文件的对应节区。
|
||||
|
||||
{{ note }}
|
||||
如果你不确定要添加到哪个位置,可以将自己添加到 `sig-docs-en-owners` 中。
|
||||
{{ /note }}
|
||||
|
||||
2. 将 PR 指派给一个或多个 SIG Docs 批准人。
|
||||
|
||||
请求被批准之后,SIG Docs Leads 之一会将你添加到对应的 GitHub 团队。
|
||||
一旦添加完成, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
|
||||
会在处理未来的 PR 时,将 PR 指派给你或者建议你来评审某 PR。
|
||||
|
||||
Reference in New Issue
Block a user