Merge pull request #50438 from michellengnx/merged-main-dev-1.33

Merging main branch into dev-1.33

Author: divya-mohan0209

OWNERS_ALIASES

@@ -84,11 +84,13 @@ aliases:
   sig-docs-es-owners: # Admins for Spanish content
     - electrocucaracha
     - krol3
+    - raelga
     - ramrodo
   sig-docs-es-reviews: # PR reviews for Spanish content
     - electrocucaracha
     - jossemarGT
     - krol3
+    - raelga
     - ramrodo
   sig-docs-fr-owners: # Admins for French content
     - perriea

content/en/blog/_posts/2024-05-09-gateway-api-v1.1/index.md

@@ -136,20 +136,20 @@ metadata:
 spec:
   gatewayClassName: acme-lb
   listeners:
-    name: foo-https
+  - name: foo-https
     protocol: HTTPS
     port: 443
     hostname: foo.example.com
-  tls:
-    certificateRefs:
-      kind: Secret
-      group: ""
-      name: foo-example-com-cert
-    frontendValidation:
-      caCertificateRefs:
-        kind: ConfigMap
+    tls:
+      certificateRefs:
+      - kind: Secret
         group: ""
-        name: foo-example-com-ca-cert
+        name: foo-example-com-cert
+      frontendValidation:
+        caCertificateRefs:
+        - kind: ConfigMap
+          group: ""
+          name: foo-example-com-ca-cert
 ```
 
 #### [Session Persistence and BackendLBPolicy](https://gateway-api.sigs.k8s.io/geps/gep-1619/)

content/en/docs/contribute/_index.md

@@ -14,16 +14,18 @@ card:
 <!-- overview -->
 
 There are lots of ways to contribute to Kubernetes. You can work on designs for new features,
-you can document the code we already have, you can write for our [blog](/blog). There's more:
-you can implement those new features or fix bugs. You can help people join our contributor
-community, or support existing contributors.
+you can document the code we already have, you can [write for our blogs](/docs/contribute/blog/).
+There's more: you can implement those new features or fix bugs. You can help people join our
+contributor community, or support existing contributors.
 
 With all these different ways to make a difference to the project, we - Kubernetes - have made
 a dedicated website: https://k8s.dev/. You can go there to learn more about
 contributing to Kubernetes.
 
-If you specifically want to learn about contributing to _this_ documentation, read
-[Contribute to Kubernetes documentation](/docs/contribute/docs/).
+If you specifically want to learn about contributing to the documentation or
+other parts of _this_ website, read [Contribute to Kubernetes documentation](/docs/contribute/docs/).
+If you specifically want to help with the official Kubernetes blogs, read
+[Contributing to Kubernetes blogs](/docs/contribute/blog/).
 
 You can also read the
 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}

content/en/docs/contribute/blog/_index.md

@@ -0,0 +1,66 @@
+---
+title: Contributing to Kubernetes blogs
+slug: blog-contribution
+content_type: concept
+weight: 15
+simple_list: true
+---
+
+<!-- overview -->
+
+There are two official Kubernetes blogs, and the CNCF has [its own blog](https://www.cncf.io/blog/) where you can cover Kubernetes too.
+For the main Kubernetes blog, we (the Kubernetes project) like to publish articles with different perspectives and special focuses, that have a link to Kubernetes.
+
+With only a few special case exceptions, we only publish content that hasn't been submitted or published anywhere else.
+
+Read the [blog guidelines](/docs/contribute/blog/guidelines/#what-we-publish) for more about that aspect.
+
+## Official Kubernetes blogs
+
+### Main blog
+
+The main [Kubernetes blog](/blog/) is used by the project to communicate new features, community reports, and any
+news that might be relevant to the Kubernetes community. This includes end users and developers.
+Most of the blog's content is about things happening in the core project, but Kubernetes
+as a project encourages you to submit about things happening elsewhere in the ecosystem too!
+
+Anyone can write a blog post and submit it for publication. With only a few special case exceptions, we only publish content that hasn't been submitted or published anywhere else.
+
+### Contributor blog
+
+The [Kubernetes contributor blog](https://k8s.dev/blog/) is aimed at an audience of people who
+work **on** Kubernetes more than people who work **with** Kubernetes. The Kubernetes project
+deliberately publishes some articles to both blogs.
+
+Anyone can write a blog post and submit it for review.
+
+## Article updates and maintenance {#maintenance}
+
+The Kubernetes project does not maintain older articles for its blogs. This means that any
+published article more than one year old will normally **not** be eligible for issues or pull
+requests that ask for changes. To avoid establishing precedent, even technically correct pull
+requests are likely to be rejected.
+
+However, there are exceptions like the following:
+
+* (updates to) articles marked as [evergreen](#maintenance-evergreen)
+* removing or correcting articles giving advice that is now wrong and dangerous to follow
+* fixes to ensure that an existing article still renders correctly
+
+For any article that is over a year old and not marked as _evergreen_, the website automatically
+displays a notice that the content may be stale.
+
+### Evergreen articles {#maintenance-evergreen}
+
+You can mark an article as evergreen by setting `evergreen: true` in the front matter.
+
+We only mark blog articles as maintained (`evergreen: true` in front matter) if the Kubernetes project
+can commit to maintaining them indefinitely. Some blog articles absolutely merit this; for example, the release comms team always marks official release announcements as evergreen.
+
+## {{% heading "whatsnext" %}}
+
+* Discover the official blogs:
+  * [Kubernetes blog](/blog/)
+  * [Kubernetes contributor blog](https://k8s.dev/blog/)
+
+* Read about [reviewing blog pull requests](/docs/contribute/review/reviewing-prs/#blog)

content/en/docs/contribute/blog/buddying.md

@@ -0,0 +1,109 @@
+---
+title: Helping as a blog writing buddy
+slug: writing-buddy
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+
+There are two official Kubernetes blogs, and the CNCF has its own blog where you can cover Kubernetes too.
+Read [contributing to Kubernetes blogs](/docs/contribute/blog/) to learn about these two blogs.
+
+When people contributor to either blog as an author, the Kubernetes project pairs up authors
+as _writing buddies_. This page explains how to fulfil the buddy role.
+
+You should make sure that you have at least read an outline of [article submission](/docs/contribute/blog/submission/)
+before you read on within this page.
+
+<!-- body -->
+
+## Buddy responsibilities
+
+As a writing buddy, you:
+
+* help the blog team get articles ready to merge and to publish
+* support your buddy to produce content that is good to merge
+* provide a review on the article that your buddy has written
+
+
+When the team pairs you up with another author, the idea is that you both support each other by
+reviewing the other author's draft article.
+Most people reading articles on the Kubernetes blog are not experts; the content should
+try to make sense for that audience, or at least to support non-expert readers appropriately.
+
+The blog team are also there to help you both along the journey from draft to publication.
+They will either be directly able to approve your article for publication, or can arrange for
+the approval to happen.
+
+## Supporting the blog team
+
+Your main responsibility here is to communicate about your capacity, availability and progress
+in a reasonable timeline. If many weeks go by and your buddy hasn't heard from you, it makes
+the overall work take more time.
+
+## Supporting your buddy
+
+There are two parts to the process
+
+{{< tabs name="buddy_support" >}}
+{{% tab name="Collaborative editing" %}}
+**(This is the recommended option)**
+
+The blog team recommend that the main author for the article sets up collaborative editing
+using either a Google Doc or HackMD (their choice). The main author then shares that document
+with the following people:
+
+ * Any co-authors
+ * You (their writing buddy)
+ * Ideally, with a nominated
+person from the blog team.
+
+As a writing buddy, you then read the draft text and either directly make suggestions or provide
+feedback in a different way. The author of the blog is very commonly also **your** writing buddy in turn, so they will provide the
+same kind of feedback on the draft for your blog article.
+
+Your role here is to recommend the smallest set of changes that will get the article look good
+for publication. If there's a diagram that really doesn't make sense, or the writing is really
+unclear: provide feedback. If you have a slight different of opinion about wording or punctuation,
+skip it. Let the article author(s) write in their own style, provided that they align to
+the [blog guidelines](/docs/contribute/blog/guidelines/).
+
+After this is ready, the lead author will open a pull request and use Markdown to submit the
+article. You then provide a [review](#pull-request-review).
+{{% /tab %}}
+{{% tab name="Markdown / Git editing" %}}
+Some authors prefer to start with
+[collaborative editing](#buddy-support-0); others like to go straight into
+GitHub.
+
+Whichever route they take, your role is to provide feedback that lets the blog team provide
+a simple signoff and confirm that the article can merge as a draft. See
+[submitting articles to Kubernetes blogs](/docs/contribute/blog/submission/) for what the authors
+need to do.
+
+Use GitHub suggestions to point out any required changes.
+
+Once the Markdown and other content (such as images) look right, you provide a
+formal [review](#pull-request-review).
+{{% /tab %}}
+{{< /tabs >}}
+
+
+## Pull request review
+
+Follow the [blog](/docs/contribute/review/reviewing-prs/#blog) section of _Reviewing pull requests_.
+
+When you think that the open blog pull request is good enough to merge, add the `/lgtm` comment to the pull request.
+
+This indicates to the repository automation tooling (Prow) that the content "looks good to me". Prow moves things forward. The `/lgtm` command lets you add your opinion to the record whether or not you are formally a member of the Kubernetes project.
+
+Either you or the article author(s) should let the blog team know that there is an article
+ready for signoff. It should already be marked as `draft: true` in the front matter, as
+explained in the submission guidance.
+
+## Subsequent steps
+
+For you as a writing buddy, **there is no step four**. Once the pull request is good to merge,
+the blog team (or, for the contributor site, the contributor comms team) take things from there.
+It's possible that you'll need to return to an earlier step based on feedback, but you can usually expect that your work as a buddy is done.