Merge pull request #7605 from sftim/20231114_update_blog_community_details

Update details around blog contribution

Author: k8s-ci-robot

communication/README.md

@@ -129,9 +129,9 @@ community call, and more [YouTube Guidelines].
 
 #### Kubernetes Blog
 
-The [Kubernetes Blog] is owned by sig-docs and operated by the [blog team].
+The [Kubernetes Blog] is owned by SIG Docs and operated by the [blog team].
 
-[submit a blog post] | [2018 blog metrics]
+[submit a blog post]
 
 ## Misc Community Resources
 ### Issues & Troubleshooting

communication/contributor-comms/blogging-resources/blog-guidelines.md

@@ -16,7 +16,7 @@ existing tools and processes, and in general tips and suggestions on
 how to collaborate.
 
 Other types of content, like Kubernetes capabilities, tutorials, and
-technical articles, are better suited for the [SIG-Docs blogging
+technical articles, are better suited for the [SIG Docs blogging
 initiative](/sig-docs/blog-subproject/README.md).
 
 ## Where to publish
@@ -85,6 +85,9 @@ follows:
    guide](https://kubernetes.io/docs/contribute/style/style-guide/):
    these guidelines can help in improving the readability of your
    article, especially in terms of the use of Kubernetes terminology.
+   You can also read
+   [Submitting blog posts and case studies](https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/)
+   for extra context.
 4. Once you have reflected any feedback in the proposal draft,
    announce that the article is ready for submission (again, in the
    channel or in one of the weekly meetings): the assigned editor will
@@ -121,7 +124,7 @@ co-author](https://docs.github.com/en/pull-requests/committing-changes-to-your-p
 is done by adding `Co-authored-by: original-author-name
 <[email protected]>` to the commit message.
 
-The number of PRs depends on where the article will be published:
+The number of PRs you open depends on where the article will be published:
 
 1. If it's solely for the Contributor site: the PR should be opened in
    the
@@ -130,7 +133,7 @@ The number of PRs depends on where the article will be published:
 2. If it's to be mirrored in the main Kubernetes blog: after the
    previous step, a new PR is opened on
    [kubernetes/website](https://github.com/kubernetes/website),
-   mentioning the original PR. The SIG-Docs Blog editorial team will,
+   mentioning the original PR. Reviewers from SIG Docs Blog will,
    in this case, already been notified and involved in the initial PR.
 
 
@@ -186,7 +189,9 @@ Keep the following points in mind as you write in order to speed up the review p
   * As the author, never talk about your employer, sell, promote, or
     pitch; this is about upstream community endeavours and the
     individuals and groups that create it
-* Follow the [documentation style guide](https://kubernetes.io/docs/contribute/style/style-guide/).
+* Follow the [documentation style guide](https://kubernetes.io/docs/contribute/style/style-guide/);
+  for blog articles these are informative guidelines rather than anything more strict, but
+  it's still good to follow them where appropriate.
 
 ## Further Recommendations
 

sig-docs/blog-subproject/README.md

@@ -1,94 +1,108 @@
 # Kubernetes Blog Subproject
 
-The Kubernetes Blog Subproject is owned by [SIG-Docs](https://github.com/kubernetes/community/tree/master/sig-docs) and run by the [Editorial Team](#leadership).
+The Kubernetes Blog Subproject is owned by [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs).
 
 This section covers documentation, processes, and roles for the [Kubernetes blog](https://kubernetes.io/blog/).
 
 ## Meetings
 
-Regular Blog Meeting: Tuesdays at 18:30 UTC (biweekly). [Convert Your Timezone](http://www.thetimezoneconverter.com/?t=18:30&tz=UTC)
+See [meetings](/kubernetes/community/tree/master/sig-docs#meetings) for SIG Docs
 
-- [Meeting notes and Agenda](https://docs.google.com/document/d/1W5MKkaQGd3YKKZINzj1tJAQbql5R_Y4KAHlFNsJ44Bc/edit?usp=sharing)
-- [Meeting recordings](https://www.youtube.com/playlist?list=PL69nYSiGNLP3b5hlx0YV7Lo7DtckM84y8)
 
-## Leadership
+## Subproject contributors
 
-- **Technical Editors:** [Bob Killen](https://github.com/mrbobbytables), [Taylor Dolezal](https://github.com/onlydole), [Tim Bannister](https://github.com/sftim), [Nate Waddington](https://github.com/nate-double-u)
+<!-- GitHub username alphabetical order -->
+- **Blog approvers:** [Bob Killen](https://github.com/mrbobbytables), [Taylor Dolezal](https://github.com/onlydole),
+  [Nate Waddington](https://github.com/nate-double-u), [Tim Bannister](https://github.com/sftim)
+
+- **Blog shadow approvers:** _no contributors_
+
+- **Blog editors:** _no contributors_
+
+- **Blog shadow editors:** _no contributors_
+
+✨ Could **you** join the blog editorial team?
 
 ## Contact
 
 - Slack: [#sig-docs-blog](https://kubernetes.slack.com/messages/CJDHVD54J)
 - Mailing List: [[email protected]](mailto:[email protected])
 - Open Community Issues/PRs: [`is:open repo:kubernetes/website label:area/blog`](https://github.com/issues?q=is%3Aopen+label%3Aarea%2Fblog+repo%3Akubernetes%2Fwebsite)
-- GitHub Teams: [@kubernetes/kubernetes-blog](https://github.com/orgs/kubernetes/teams/kubernetes-blog), [@kubernetes/kubernetes-blog-maintainers](https://github.com/orgs/kubernetes/teams/kubernetes-blog-maintainers)
 
 ## Submit a Post
 
 Anyone can write a blog post and submit it for review. Blog posts should not be commercial in nature and should consist of content that will apply broadly to the Kubernetes community.
 
-To submit a blog post, follow the steps below.
+To propose a blog post, read [Submitting blog posts and case studies](https://k8s.io/docs/contribute/new-content/blogs-case-studies/).
 
-1. [Sign the CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla) if you have not yet done so.
-1. Have a look at the Markdown format for existing blog posts in the [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
-1. Write out your blog post in a text editor of your choice.
-1. On the same link from step 2, click the Create new file button. Paste your content into the editor. Name the file to match the proposed title of the blog post, but don’t put the date in the file name. The blog reviewers will work with you on the final file name and the date the blog will be published.
-1. When you save the file, GitHub will walk you through the pull request process.
-1. A blog post reviewer will review your submission and work with you on feedback and final details. When the blog post is approved, the blog will be scheduled for publication.
+### Article guidelines
 
-### Blog Guidelines
+**Original content only**. You cannot submit a blog article that has been published elsewhere. The Kubernetes project
+makes exception to this only for articles posted to the CNCF blog or to the [Kubernetes contributor blog](https://k8s.dev/blog/).
 
-Requested Content (with examples):
+Requested content:
 
 - New Kubernetes capabilities
 - Kubernetes projects updates
 - Updates from Special Interest Groups
 - Tutorials and walkthroughs
 - Thought leadership around Kubernetes
 - Kubernetes Partner OSS integration
-- **Original content only**
 
-Unsuitable Content:
+Unsuitable content:
 
 - Vendor product pitches
 - Partner updates without an integration and customer story
-- Syndicated posts (language translations ok)
+- Syndicated posts (it's OK to localized existing articles from English)
 
-## Review Process
+## Review process
 
 Once a blog post is submitted either via the form or a PR, it will be routed to the editorial team for review either via email for Google Docs or auto-assigning for a PR.
 
-Each blog post requires a LGTM from one copy editor, technical editor\*, and blog community manager. Once the necessary LGTMs are in place, an Editorial Lead will schedule and approve the blog post.
+Each blog post requires a LGTM from a blog editor (or approver) and an approval by a blog approver. Blog editors will usually also get a technical review from the appropriate SIG.
 
 _If a blog post does not contain any technical content (for example, [How You Can Help Localize Kubernetes Docs](https://kubernetes.io/blog/2019/04/26/how-you-can-help-localize-kubernetes-docs/)), the technical review can be omitted._
 
-### Embargoed Content
+Articles should merge _before_ their publication date; automation picks up scheduled posts and publishes them automatically.
+
+
+### Release communications
+
+SIG Release lead on blog articles to announce Kubernetes releases, and the post-release series of articles. SIG Docs and the blog subproject support
+that process and provide approvals for upcoming articles.
+
+### Embargoed content
+
+The blog repository on GitHub is public, therefore any content that needs to remain confidential until a certain time (for example: release posts, security vulnerabilities) should be proposed by email message to [[email protected]](mailto:[email protected]). If you need to, you can also send a Slack direct message to the set of blog approvers; please do this sparingly.
 
-The blog repository on GitHub is public, therefore any content that needs to remain confidential until a certain time (for example: release posts, security vulnerabilities) should be proposed by email message to [[email protected]](mailto:[email protected]). In your message, please note the time that the embargo will be lifted.
+In your message, please note the time that the embargo will be lifted.
 
 ### SLA
 
-Blog posts can take up to **2 weeks** to review. If you’d like to request an expedited review, please email [blog@kubernetes.io](mailto:[email protected]).
+Blog posts can take up to **4 weeks** to review. If you’d like to request an expedited review, please get in touch via [#sig-docs-blog](https://app.slack.com/client/T09NY5SBT/CJDHVD54J) on the Kubernetes Slack workspace.
 
-## Ongoing Blog Maintenance
+## Ongoing blog maintenance
 
-SIG-Docs approvers for English content can approve edits after the fact such as: broken links, copy edits, etc. However, approval and editorial review for new blog posts is limited to the Blog Team.
+SIG Docs approvers for English content can approve edits after the fact such as: broken links, copy edits, etc. However, approval and editorial review for new blog posts is limited to the Blog Team.
 
-We typically do not make edits to blog posts more than 1 years old.
+We typically do not make edits to blog posts more than 1 years old; there is an exception for articles marked `evergreen: true` in their
+[front matter](https://gohugo.io/content-management/front-matter/).
 
-## Editorial Team Selection
+## Editorial team selection
 
-Each Editorial Team role is responsible for staffing their respective role, with this order of fall-through in mind:
+Bloggers and reviewer responsibilities include staffing the team, with this order of fall-through in mind:
 
 - training and selecting a successor from the current pool of role shadows
 - training and selecting a successor from non-Editorial Team members
 - staffing the role themselves
 
-Ultimately, if none of these can be satisfied, responsibility falls to the Editorial Team Lead and SIG-Docs to staff the roles.
+Ultimately, if none of these can be satisfied, responsibility falls to the SIG Docs leadership to staff the roles.
 
 ### Shadows
 
-We are always open to adding new shadows to the editorial team roles. If you are interested in shadowing one of the roles on the team, please fill out [this application](The application form is now live for anyone interested in joining the blog editorial team: https://docs.google.com/forms/d/e/1FAIpQLScg9fHsyW-LlsBF8rc9J0sR8u3O3g17lwFUKIE-qrjL6Z-AyA/viewform?usp=sf_link). We review applications on a rolling basis.
+We are always open to adding new shadows to the editorial team roles. If you are interested in shadowing one of the roles on the team, please say Hi in
+[#sig-docs-blog](https://app.slack.com/client/T09NY5SBT/CJDHVD54J) on the Kubernetes Slack workspace. Visit https://slack.k8s.io/ for an invitation if you are not already part of the workspace.
 
-### Removing a Team Member
+### Removing a team member
 
-If a team member can no longer fulfill their duties, the role defaults to the shadow.
+If all members of a group (eg approvers) can no longer fulfil their duties, and there is a shadow for that role, that role defaults to the shadow.