Skip to content

Latest commit

 

History

History

blog-subproject

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

Kubernetes Blog Subproject

The Kubernetes Blog Subproject is owned by SIG Docs.

This section covers documentation, processes, and roles for the Kubernetes blog.

Meetings

See meetings for SIG Docs

Subproject contributors

✨ Could you join the blog editorial team?

Contact

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 propose a blog post, read Submitting blog posts and case studies.

Article 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.

Requested content:

  • New Kubernetes capabilities
  • Kubernetes projects updates
  • Updates from Special Interest Groups
  • Tutorials and walkthroughs
  • Thought leadership around Kubernetes
  • Kubernetes Partner OSS integration

Unsuitable content:

  • Vendor product pitches
  • Partner updates without an integration and customer story
  • Syndicated posts (it's OK to localized existing articles from English)

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 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), the technical review can be omitted.

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 blog@kubernetes.io. If you need to, you can also send a Slack direct message to the set of blog approvers; please do this sparingly.

In your message, please note the time that the embargo will be lifted.

SLA

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 on the Kubernetes Slack workspace.

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.

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.

Editorial team selection

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 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 say Hi in #sig-docs-blog 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

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.