diff --git a/content/zh/docs/contribute/new-content/blogs-case-studies.md b/content/zh/docs/contribute/new-content/blogs-case-studies.md
index 71ebf83930..dbd1b89c16 100644
--- a/content/zh/docs/contribute/new-content/blogs-case-studies.md
+++ b/content/zh/docs/contribute/new-content/blogs-case-studies.md
@@ -34,14 +34,78 @@ Anyone can write a blog post and submit it for review.
-->
## Kubernetes 博客
-Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一些可能对整个社区
-很重要的新闻。
+Kubernetes 博客用于项目发布新功能特性、
+社区报告以及其他一些可能对整个社区很重要的新闻。
其读者包括最终用户和开发人员。
-大多数博客的内容是关于核心项目中正在发生的事情,不过我们也鼓励你提交一些
-关于生态系统中其他地方发生的事情的博客。
+大多数博客的内容是关于核心项目中正在发生的事情,
+不过我们也鼓励你提交一些有关生态系统中其他时事的博客。
任何人都可以撰写博客并提交评阅。
+
+### 提交博文
+
+博文不应该是商业性质的,应该包含广泛适用于 Kubernetes 社区的原创内容。
+合适的博客内容包括:
+
+- Kubernetes 新能力
+- Kubernetes 项目更新信息
+- 来自特别兴趣小组(Special Interest Groups, SIG)的更新信息
+- 教程和演练
+- 有关 Kubernetes 的纲领性理念
+- Kubernetes 合作伙伴 OSS 集成信息
+- **仅限原创内容**
+
+
+
+不合适的博客内容包括:
+
+- 供应商产品推介
+- 不含集成信息和客户故事的合作伙伴更新信息
+- 已发表的博文(可刊登博文译稿)
+
+
+要提交博文,你可以遵从以下步骤:
+
+1. 如果你还未签署 CLA,请先[签署 CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla)。
+2. 查阅[网站仓库](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts)中现有博文的 Markdown 格式。
+3. 在你所选的文本编辑器中撰写你的博文。
+4. 在第 2 步的同一链接上,点击 **Create new file** 按钮。
+ 将你的内容粘贴到编辑器中。为文件命名,使其与提议的博文标题一致,
+ 但不要在文件名中写日期。
+ 博客评阅者将与你一起确定最终的文件名和发表博客的日期。
+5. 保存文件时,GitHub 将引导你完成 PR 流程。
+6. 博客评阅者将评阅你提交的内容,并与你一起处理反馈和最终细节。
+ 当博文被批准后,博客将排期发表。
+
- 博客内容应该对 Kubernetes 用户有用。
- 与参与 Kubernetes SIGs 活动相关,或者与这类活动的结果相关的主题通常是切题的。
@@ -98,6 +163,7 @@ Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一
- 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。
有些时候,某个 CNCF 项目的主要功能特性或者里程碑的变化可能是用户有兴趣在
Kubernetes 博客上阅读的内容。
+ - 关于为 Kubernetes 项目做贡献的博客内容应该放在 [Kubernetes 贡献者站点](https://kubernetes.dev)上。
### 提交博客的技术考虑
-所提交的内容应该是 Markdown 格式的,以便能够被[Hugo](https://gohugo.io/) 生成器来处理。
+所提交的内容应该是 Markdown 格式的,以便能够被 [Hugo](https://gohugo.io/) 生成器来处理。
关于如何使用相关技术,有[很多可用的资源](https://gohugo.io/documentation/)。
我们知道这一需求可能给那些对此过程不熟悉的朋友们带来不便,
@@ -141,7 +207,6 @@ To submit a blog post follow these directions:
SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。
更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
-
要提交博文,你可以遵从以下指南:
-- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
+- [发起一个包含新博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) 目录下。
- 确保你的博文遵从合适的命名规范,并带有下面的引言(元数据)信息:
@@ -198,6 +263,30 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s
- 博客团队会对 PR 内容进行评阅,为你提供一些评语以便修订。
之后,机器人会将你的博文合并并发表。
+
+
+ - 如果博文的内容仅包含预期无需更新就能对读者保持精准的内容,
+ 则可以将这篇博文标记为长期有效(evergreen),
+ 且免除添加博文发表一年后内容过期的自动警告。
+ - 要将一篇博文标记为长期有效,请在引言部分添加以下标记:
+
+ ```yaml
+ evergreen: true
+ ```
+ - 不应标记为长期有效的内容示例:
+ - 仅适用于特定发行版或版本而不是所有未来版本的**教程**
+ - 对非正式发行(Pre-GA)API 或功能特性的引用
+
{{< note >}}
-**代码开发者们**:如果你在为下一个 Kubernetes 发行版本中的某功能特性
-撰写文档,请参考[为新功能撰写文档](/zh/docs/contribute/new-content/new-features/)。
+**代码开发者们**:如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档,
+请参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)。
{{< /note >}}
要贡献新的内容页面或者改进已有内容页面,请发起拉取请求(PR)。
-请确保你满足了[开始之前](/zh/docs/contribute/new-content/overview/#before-you-begin)
-节中所列举的所有要求。
+请确保你满足了[开始之前](/zh/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。
-
+## 使用 GitHub 提交变更 {#changes-using-github}
+如果你在 git 工作流方面欠缺经验,这里有一种发起拉取请求的更为简单的方法。
+下图勾勒了后续的步骤和细节。
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+A([fa:fa-user 新的
贡献者]) --- id1[(K8s/Website
GitHub)]
+subgraph tasks[使用 GitHub 提交变更]
+direction TB
+ 0[ ] -.-
+ 1[1. 编辑此页] --> 2[2. 使用 GitHub markdown
编辑器进行修改]
+ 2 --> 3[3. 填写 Propose file change]
+
+end
+subgraph tasks2[ ]
+direction TB
+4[4. 选择 Propose file change] --> 5[5. 选择 Create pull request] --> 6[6. 填写 Open a pull request]
+6 --> 7[7. 选择 Create pull request]
+end
+
+id1 --> tasks --> tasks2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,1,2,3,4,5,6,7 grey
+class 0 spacewhite
+class tasks,tasks2 white
+class id1 k8s
+{{ mermaid >}}
+
+***插图 - 使用 GitHub 发起一个 PR 的步骤***
+
+
-## 使用 GitHub 提交变更 {#changes-using-github}
-如果你在 git 工作流方面欠缺经验,这里有一种发起拉取请求的更为简单的方法。
-
-1. 在你发现问题的网页,选择右上角的铅笔图标。你也可以滚动到页面底端,选择
- **编辑此页面**。
+1. 在你发现问题的网页,选择右上角的铅笔图标。
+ 你也可以滚动到页面底端,选择**编辑此页**。
2. 在 GitHub 的 Markdown 编辑器中修改内容。
-3. 在编辑器的下方,填写 **建议文件变更** 表单。
+3. 在编辑器的下方,填写 **Propose file change** 表单。
在第一个字段中,为你的提交消息取一个标题。
在第二个字段中,为你的提交写一些描述文字。
-
+
{{< note >}}
- 不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
+ 不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
你可以在后续的 PR 描述中使用这些关键词。
{{< /note >}}
-4. 选择 **Propose File Change**.
-5. 选择 **Create pull request**.
-6. 在 **Open a pull request** 屏幕上填写表单:
+4. 选择 **Propose File Change**。
+5. 选择 **Create pull request**。
+6. 出现 **Open a pull request** 界面。填写表单:
- **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。
- - **Body** 字段包含更为详细的提交消息,如果你之前有填写过的话,以及一些模板文字。
- 填写模板所要求的详细信息,之后删除多余的模板文字。
+ - **Body** 字段包含更为详细的提交消息,如果你之前有填写过的话,
+ 以及一些模板文字。填写模板所要求的详细信息,
+ 之后删除多余的模板文字。
- 确保 **Allow edits from maintainers** 复选框被勾选。
{{< note >}}
PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。
- 更多信息请参考[发起一个 PR](#open-a-pr).
+ 更多信息请参考[发起一个 PR](#open-a-pr)。
{{< /note >}}
-7. 选择 **Create pull request**.
+7. 选择 **Create pull request**。
## 基于本地克隆副本开展工作 {#work-from-a-local-fork}
@@ -168,6 +211,42 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。
你也可以使用 git 的带用户界面的应用。
+下图显示了基于本地克隆副本开展工作的步骤。
+每个步骤的细节如下。
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+1[派生 K8s/website
仓库] --> 2[创建本地克隆副本
并指定 upstream 仓库]
+subgraph changes[你的变更]
+direction TB
+S[ ] -.-
+3[创建一个分支
例如: my_new_branch] --> 3a[使用文本编辑器
进行修改] --> 4["使用 Hugo 在本地
预览你的变更
(localhost:1313)
或构建容器镜像"]
+end
+subgraph changes2[提交 / 推送]
+direction TB
+T[ ] -.-
+5[提交你的变更] --> 6[将提交推送到
origin/my_new_branch]
+end
+
+2 --> changes --> changes2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class 1,2,3,3a,4,5,6 grey
+class S,T spacewhite
+class changes,changes2 white
+{{ mermaid >}}
+
+
+***插图 - 使用本地克隆副本进行修改***
+
### 创建一个本地克隆副本并指定 upstream 仓库
-3. 打开终端窗口,克隆你所派生的副本:
+3. 打开终端窗口,克隆你所派生的副本,并更新 [Docsy Hugo 主题](https://github.com/google/docsy#readme):
```bash
git clone git@github.com//website
+ cd website
+ git submodule update --init --recursive --depth 1
```
{{< note >}}
此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。
@@ -262,12 +345,12 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
1. 决定你要基于哪个分支来开展工作:
- - 针对已有内容的改进,请使用 `upstream/main`;
- - 针对已有功能特性的新文档内容,请使用 `upstream/main`;
+ - 针对已有内容的改进,请使用 `upstream/main`。
+ - 针对已有功能特性的新文档内容,请使用 `upstream/main`。
- 对于本地化内容,请基于本地化的约定。
- 可参考[对 Kubernetes 文档进行本地化](/zh/docs/contribute/localization/)了解详细信息。
+ 可参考[本地化 Kubernetes 文档](/zh/docs/contribute/localization/)了解详细信息。
- 对于在下一个 Kubernetes 版本中新功能特性的文档,使用独立的功能特性分支。
- 参考[为发行版本功能特性撰写文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
+ 参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
- 对于很多 SIG Docs 共同参与的,需较长时间才完成的任务,例如内容的重构,
请使用为该任务创建的特性分支。
@@ -276,7 +359,7 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
-2. 基于第一步中选定的分支,创建新分支。
+2. 基于第 1 步中选定的分支,创建新分支。
下面的例子假定基础分支是 `upstream/main`:
```bash
@@ -285,11 +368,13 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
-3. 使用文本编辑器开始构造变更。
+
+3. 使用文本编辑器进行修改。
+
在任何时候,都可以使用 `git status` 命令查看你所改变了的文件列表。
### 在本地预览你的变更 {#preview-locally}
-在推送变更或者发起 PR 之前在本地查看一下预览是个不错的注意。
+在推送变更或者发起 PR 之前在本地查看一下预览是个不错的主意。
通过预览你可以发现构建错误或者 Markdown 格式问题。
-你可以构造网站的容器镜像或者在本地运行 Hugo。
-构造容器镜像的方式比较慢,不过能够显示 [Hugo 短代码(shortcodes)](/zh/docs/contribute/style/hugo-shortcodes/),
+你可以构建网站的容器镜像或者在本地运行 Hugo。
+构建容器镜像的方式比较慢,不过能够显示 [Hugo 短代码(shortcodes)](/zh/docs/contribute/style/hugo-shortcodes/),
因此对于调试是很有用的。
{{< tabs name="tab_with_hugo" >}}
{{% tab name="在容器内执行 Hugo" %}}
{{< note >}}
下面的命令中使用 Docker 作为默认的容器引擎。
-如果需要重载这一行为,可以设置 `CONTAINER_ENGINE`。
+如果需要重载这一行为,可以设置 `CONTAINER_ENGINE` 环境变量。
{{< /note >}}
-1. 在本地构造镜像;
+1. 在本地构建镜像:
```bash
# 使用 docker (默认)
@@ -441,7 +527,7 @@ You can set up the `CONTAINER_ENGINE` to override this behavior.
-2. 在本地构造了 `kubernetes-hugo` 镜像之后,可以构造并启动网站:
+2. 在本地构建了 `kubernetes-hugo` 镜像之后,可以构建并启动网站:
```bash
# 使用 docker (默认)
@@ -473,24 +559,37 @@ Alternately, install and use the `hugo` command on your computer:
1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)
文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。
-2. 启动一个终端窗口,进入 Kubernetes 网站仓库目录,启动 Hugo 服务器:
+2. 如果你尚未更新你的网站仓库,则 `website/themes/docsy` 目录是空的。
+ 如果本地缺少主题的副本,则该站点无法构建。
+ 要更新网站主题,运行以下命令:
+
+ ```bash
+ git submodule update --init --recursive --depth 1
+ ```
+
+3. 启动一个终端窗口,进入 Kubernetes 网站仓库目录,启动 Hugo 服务器:
```bash
cd /website
hugo server
```
-3. 在浏览器的地址栏输入: `https://localhost:1313`。
-4. 要停止本地 Hugo 实例,返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
+4. 在浏览器的地址栏输入: `https://localhost:1313`。
+ Hugo 会监测文件的变更并根据需要重新构建网站。
+5. 要停止本地 Hugo 实例,返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
+
{{% /tab %}}
{{< /tabs >}}
@@ -499,6 +598,42 @@ Alternately, install and use the `hugo` command on your computer:
-->
### 从你的克隆副本向 kubernetes/website 发起拉取请求(PR) {#open-a-pr}
+
+下图显示了从你的克隆副本向 K8s/website 发起 PR 的步骤。
+详细信息如下。
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+subgraph first[ ]
+direction TB
+1[1. 前往 K8s/website 仓库] --> 2[2. 选择 New Pull Request]
+2 --> 3[3. 选择 compare across forks]
+3 --> 4[4. 从 head repository 下拉菜单
选择你的克隆副本]
+end
+subgraph second [ ]
+direction TB
+5[5. 从 compare 下拉菜单
选择你的分支] --> 6[6. 选择 Create Pull Request]
+6 --> 7[7. 为你的 PR
添加一个描述]
+7 --> 8[8. 选择 Create pull request]
+end
+
+first --> second
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+class 1,2,3,4,5,6,7,8 grey
+class first,second white
+{{ mermaid >}}
+
+***插图 - 从你的克隆副本向 K8s/website 发起一个 PR 的步骤***
+
2. 如果有必要,更新你的提交消息;
-3. 使用 `git push origin ` 来推送你的变更,重新出发 Netlify 测试。
+3. 使用 `git push origin ` 来推送你的变更,重新触发 Netlify 测试。
{{< note >}}
如果你使用 `git commit -m` 而不是增补参数,在 PR 最终合并之前你必须
@@ -626,7 +762,7 @@ For more information, see [Git Branching - Basic Branching and Merging](https://
{{< note >}}
要了解更多信息,可参考
[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、
-[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)、
+[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging),
或者在 `#sig-docs` Slack 频道寻求帮助。
{{< /note >}}
@@ -730,7 +866,9 @@ If another contributor commits changes to the same file in another PR, it can cr
### 压缩(Squashing)提交 {#squashing-commits}
{{< note >}}
要了解更多信息,可参看
@@ -793,7 +931,9 @@ If your PR has multiple commits, you must squash them into a single commit befor
就重设基线操作本身,我们关注 `squash` 和 `pick` 选项。
{{< note >}}
进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。
@@ -866,12 +1006,14 @@ Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
-->
-每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前,记得阅读仓库的
-`README.md`、`CONTRIBUTING.md` 和 `code-of-conduct.md` 文件,如果有的话。
+每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前,
+记得阅读仓库可能存在的 `README.md`、`CONTRIBUTING.md` 和
+`code-of-conduct.md` 文件。
-大多数仓库都有自己的 Issue 和 PR 模版。通过查看一些待解决的 Issues 和
-PR,也可以添加对它们的链接。你可以多少了解该团队的流程。
-在登记 Issue 或提出 PR 时,务必尽量填充所给的模版,多提供详细信息。
+大多数仓库都有自己的 Issue 和 PR 模板。
+通过查看一些待解决的 Issue 和 PR,
+你可以大致了解协作的流程。
+在登记 Issue 或提出 PR 时,务必尽量填充所给的模板,多提供详细信息。
## {{% heading "whatsnext" %}}