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
@@ -22,63 +22,181 @@ Case studies require extensive review before they're approved.
22
22
案例分析则在被批准之前需要更多的评阅。
23
23
24
24
<!-- body -->
25
+
25
26
<!--
26
-
## Write a blog post
27
+
## The Kubernetes Blog
28
+
29
+
The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community.
30
+
This includes end users and developers.
31
+
Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too!
27
32
28
-
Blog posts should not be
29
-
vendor pitches. They must contain content that applies broadly to
30
-
the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
33
+
Anyone can write a blog post and submit it for review.
31
34
-->
32
-
## 撰写博文 {#write-a-blog-post}
35
+
## Kubernetes 博客
33
36
34
-
博客内容不可以是销售用语。
35
-
其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
36
-
SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
- Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties.
50
+
- Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog.
51
+
- Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out.
- Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees.
70
+
- Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle.
71
+
- If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post.
72
+
- Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time.
- Blog posts should be relevant to Kubernetes users.
86
+
- Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts).
87
+
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
88
+
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
89
+
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
- The official blog is not for repurposing existing content from a third party as new content.
104
+
- The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog does allow commercial use of the content for commercial purposes, just not the other way around.
105
+
- Blog posts should aim to be future proof
106
+
- Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader.
107
+
- It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
108
+
- Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care.
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
45
-
- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
120
+
<!--
121
+
### Technical Considerations for submitting a blog post
46
122
47
-
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
123
+
Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack.
48
124
49
-
- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
50
-
- The front matter must include the following:
125
+
We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out.
The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
138
+
139
+
To submit a blog post follow these directions:
140
+
-->
141
+
SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。
- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
148
+
149
+
- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
150
+
151
+
- The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
152
+
- Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build.
- The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible.
176
+
- Examples of a good commit message:
177
+
- _Add blog post on the foo kubernetes feature_
178
+
- _blog: foobar announcement_
179
+
- Examples of bad commit message:
180
+
- _Add blog post_
181
+
- _._
182
+
- _initial commit_
183
+
- _draft post_
184
+
- The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published.
0 commit comments