You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/zh/docs/contribute/advanced.md
-126Lines changed: 0 additions & 126 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,132 +27,6 @@ client and other tools for some of these tasks.
27
27
28
28
<!-- body -->
29
29
30
-
<!--
31
-
## Be the PR Wrangler for a week
32
-
-->
33
-
## 做一周的 PR 管理者
34
-
35
-
<!--
36
-
SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
37
-
38
-
The PR wrangler’s duties include:
39
-
-->
40
-
SIG Docs 的[批准人(Approvers)](/zh/docs/contribute/participating/#approvers)们每周轮流负责
- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [style guide](/docs/contribute/style/style-guide/).
47
-
- Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`).
48
-
- Review as many PRs as you can.
49
-
- Ensure that the CLA is signed by each contributor.
50
-
- Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
51
-
- Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA.
52
-
- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs.
53
-
- Provide inline suggestions on the PR for the proposed content changes.
54
-
- If you need to verify content, comment on the PR and request more details.
55
-
- Assign relevant `sig/` label(s).
56
-
- If needed, assign reviewers from the `reviewers:` block in the file's front matter.
57
-
- Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status.
58
-
- Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed.
59
-
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
60
-
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
61
-
- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
62
-
- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata.
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
87
-
reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
88
-
-->
89
-
### 对于管理人有用的 GitHub 查询
90
-
91
-
执行管理操作时,以下查询很有用。完成以下三个查询后,剩余的要审阅的 PR 列表通常很小。
92
-
这些查询都排除了本地化的 PR,并仅包含 `master` 分支上的 PR(除了最后一个查询)。
93
-
94
-
<!--
95
-
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
96
-
Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close
97
-
the PR and remind them that they can open it after signing the CLA.
98
-
**Do not review PRs whose authors have not signed the CLA!**
Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
104
-
- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
122
-
-->
123
-
### 什么时候关闭 PR
124
-
125
-
审查和批准是缩短和更新我们的 PR 队列的一种方式;另一种方式是关闭 PR。
126
-
127
-
<!--
128
-
- Close any PR where the CLA hasn’t been signed for two weeks.
129
-
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.
130
-
131
-
- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
132
-
133
-
Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
134
-
135
-
To close a pull request, leave a `/close` comment on the PR.
An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
0 commit comments