add en pages

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

@@ -3,12 +3,12 @@ title: Reviewing changes
 weight: 30
 ---
 
-{{% capture overview %}}
+<!-- overview -->
 
 This section describes how to review content.
 
-{{% /capture %}}
 
-{{% capture body %}}
 
-{{% /capture %}}
+<!-- body -->
+
+

content/en/docs/contribute/review/for-approvers.md

@@ -2,11 +2,11 @@
 title: Reviewing for approvers and reviewers
 linktitle: For approvers and reviewers
 slug: for-approvers
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---
 
-{{% capture overview %}}
+<!-- overview -->
 
 SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
 
@@ -19,10 +19,10 @@ requests (PRs) that are not already under active review.
 In addition to the rotation, a bot assigns reviewers and approvers
 for the PR based on the owners for the affected files.
 
-{{% /capture %}}
 
 
-{{% capture body %}}
+
+<!-- body -->
 
 ## Reviewing a PR
 
@@ -224,4 +224,3 @@ If this is a documentation issue, please re-open this issue.
 ```
 
 
-{{% /capture %}}

content/en/docs/contribute/review/reviewing-prs.md

@@ -1,11 +1,11 @@
 ---
 title: Reviewing pull requests
-content_template: templates/concept
+content_type: concept
 main_menu: true
 weight: 10
 ---
 
-{{% capture overview %}}
+<!-- overview -->
 
 Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests.
 
@@ -19,9 +19,9 @@ Before reviewing, it's a good idea to:
 [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
 - Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
 
-{{% /capture %}}
 
-{{% capture body %}}
+
+<!-- body -->
 
 ## Before you begin
 
@@ -95,4 +95,3 @@ When reviewing, use the following as a starting point.
 
 For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`.  This lets the author know the issue is non-critical.
 
-{{% /capture %}}