Skip to content

Files

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 and run by the Editorial Team.

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

Meetings

Regular Blog Meeting: Tuesdays at 18:30 UTC (biweekly). Convert Your Timezone

Leadership

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 submit a blog post, follow the steps below.

  1. Sign the CLA if you have not yet done so.
  2. Have a look at the Markdown format for existing blog posts in the website repository.
  3. Write out your blog post in a text editor of your choice.
  4. 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.
  5. When you save the file, GitHub will walk you through the pull request process.
  6. 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.

Blog Guidelines

Requested Content (with examples):

  • 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:

  • Vendor product pitches
  • Partner updates without an integration and customer story
  • Syndicated posts (language translations ok)

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.

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.

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

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.

Editorial Team Selection

Each Editorial Team role is responsible for staffing their respective role, 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.

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.

Removing a Team Member

If a team member can no longer fulfill their duties, the role defaults to the shadow.