Creating blog posts

The Knative blog is owned by the Documentation working group and run by the Editorial Team.

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



Submit a Post

Anyone can write a blog post and submit it for review. Commercial content is not allowed. Please refer to the blog guidelines for more guidance.

To submit a blog post, follow the steps below.

  1. Sign the Contributor License Agreements if you have not yet done so.
  2. Familiarize yourself with the Markdown format for existing blog posts in the docs repository. Blog posts are categorized into different directories. You can explore the directories to find examples.
  3. Write your blog post in a text editor of your choice.
  4. (Optional) If you need help with markdown, check out StakEdit or read GitHub’s formatting syntax for more information.
  5. Choose a directory in the docs repository, and click Create new file.
  6. Paste your content into the editor and save it. Name the file in the following way: [BLOG] Your proposed title , 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 on which the blog will be published.
  7. When you save the file, GitHub will walk you through the pull request (PR) process.
  8. A reviewer is assigned to all pull requests automatically. The reviewer checks your submission, and works with you on feedback and final details. When the pull request is approved, the blog will be scheduled for publication.
  9. Ping editorial team members on Slack #docs channel with a link to your recently created PR.

Blog Guidelines

Suitable content:

Unsuitable Content:

  • Blogs that do not address Knative in any way
  • Content that doesn’t interact with Knative APIs or interfaces
  • Vendor pitches

Communicating new project releases

Scheduled releases: The Knative project has a release every 6 weeks, and we need your help communicating new changes to our community! If you would like to contribute a blog post to the Knative blog, please consider writing about the latest changes to the project. Ideally, there should be a single blog post for every release version, for example, 0.17; 0.18; 0.19. The title convention should be: Version [version number] release - [date]. Release blog contributors should write a summary of the changes and select up to 3 highlights of the current release to write about. Big changes to the project. Big changes to the project require a deep dive blog that describes the new feature in detail and give examples of the new functionality.

Review Process

After a blog post is submitted as a PR, it is automatically assigned to a reviewer.

Each blog post requires a lgtm label from at least one person in the editorial team. Once the necessary labels are in place, one of the reviewers will add an approved label, and schedule publication of the blog post.

Service level agreement (SLA)

Blog posts can take up to 1 week to review. If you’d like to request an expedited review, please say so on your message when you ping the editorial team on Slack.