diff --git a/README.md b/README.md
index a04119955b985b4e127401a56859b6fef6955887..8ca1c5096956308c3728abc618499ef475783103 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,7 @@
-# Emerald Caas Framework Contribution Guidelines
+# Emerald CaaS Framework Contribution Guidelines
 
-This repository contains Contribution Guidelines for Caas Framework in emerald project.
+This repository contains Contribution Guidelines for CaaS Framework in EMERALD project.
+NOTE: These guidelines were written for the project team, and sometimes refer to private repositories not publicly accesible.
 
 ## Table of contents
   - [Table of contents](#table-of-contents)
@@ -14,26 +15,25 @@ This repository contains Contribution Guidelines for Caas Framework in emerald p
   - [Project status](#project-status)
 
 ## Description
-This repository contains diferent utility guidelines on how to contribute to the Emerald Caas Framework. The guidelines are divided into different sections, each one with a specific purpose.
+This repository contains diferent utility guidelines on how to contribute to the Emerald CaaS Framework. The guidelines are divided into different sections, each one with a specific purpose.
 - [Enroll](https://git.code.tecnalia.com/emerald/public/enroll/-/blob/master/README.md) how to join to the repository for contributions.
-- [Component Development](./component_development.md): Contains the guidelines for developing a new component for the Caas Framework.
-- [Component Integration](./component_integration.md): Contains the guidelines for integrating a new component into the Caas Framework.
-- [Component Validation](./component_validation.md): Contains the guidelines for validating a new component for the Caas Framework.
-- [Keycloak Integration](./keycloak_integration.md): Contains the guidelines for integrating Keycloak into the components of the Caas Framework.
-- [Component Update](./component_update.md): Contains the guidelines for updating a component of the Caas Framework.
-- [Component Troubleshooting](./component_troubleshooting.md): Contains the guidelines for troubleshooting a component of the Caas Framework.
-- [Semantic Versioning with Gitlab CI/CD](./semantic_versioning_ci_cd.md): Contains the guidelines for versioning the components of the Caas Framework.
+- [Component Development](./component_development.md): Contains the guidelines for developing a new component for the CaaS Framework.
+- [Component Integration](./component_integration.md): Contains the guidelines for integrating a new component into the CaaS Framework.
+- [Component Validation](./component_validation.md): Contains the guidelines for validating a new component for the CaaS Framework.
+- [Keycloak Integration](./keycloak_integration.md): Contains the guidelines for integrating Keycloak into the components of the CaaS Framework.
+- [Component Update](./component_update.md): Contains the guidelines for updating a component of the CaaS Framework.
+- [Component Troubleshooting](./component_troubleshooting.md): Contains the guidelines for troubleshooting a component of the CaaS Framework.
+- [Semantic Versioning with Gitlab CI/CD](./semantic_versioning_ci_cd.md): Contains the guidelines for versioning the components of the CaaS Framework.
 - [Component Publish with Gitlab CI/CD](./component_publish_ci_cd.md): Contains the guidelines for setting up the CI/CD pipeline for a component image publishing in gitlab.
 
 Version: 1.0.0
 
 ## Support
-If you require support for improving the template add an [issue](../../../-/issues) to the template and contact the [Owners/Maintainers](../-/project_members?sort=access_level_desc) of the repo.
+If you want to improve the guidelines, add an [issue](../../../-/issues) and contact the [Owners/Maintainers](../-/project_members?sort=access_level_desc) of the repo.
 
-Note: remember to change this section to match the support options for your project.
 
 ## Roadmap
-No future plans for this project appart from improving the template based on feedback.
+No future plans for this project apart from improving the guidelines based on your feedback.
 
 ## Contributing
 In order to contribute to the project, you can [fork](../../../-/forks/new) the repository and create a merge request. The merge request will be reviewed by the project maintainers and if it is accepted it will be merged into the main branch.
@@ -51,4 +51,4 @@ Thanks to:
 Read the [license file](../../../LICENSE) for more information.
 
 ## Project status
-The project is in a stable state and is not actively being developed.
+The project is in a stable state and is not actively being developed.
\ No newline at end of file
diff --git a/component_development.md b/component_development.md
index af9d75aebe27f39dbc438e365fdac95de475a4ac..345c8ca8712c62eb887c46de8a6574a5e2cc6fe0 100644
--- a/component_development.md
+++ b/component_development.md
@@ -12,31 +12,35 @@ Emerald project architecture is based in containers and containers orchestration
   - [Login](#login)
   - [Publish](#publish)
 
+## Basics of component development
+
 ## Basics of component publishing
 
-Independent of the component nature: open source, or proprietary. It must have a repository in the Tecnalia GitLab. The repository must have a README.md and a LICENSE file.
+Independently of the component nature -open source or proprietary- it must have a repository in the Tecnalia GitLab. The repository must have a README.md and a LICENSE file.
 
-In the case of open source components, the README.md will describe the usage of the component and the LICENSE file will contain the license of the component. By default, the license in Emerald project is Apache 2.0.
+In the case of **open source** components, the README.md will describe the usage of the component, and the LICENSE file will contain the license of the component. By default, the license in Emerald project is Apache 2.0.
 
-In the case of proprietary components, the README.md will describe the objective of the component and the means to access the component. The LICENSE file will contain the license of the component.
+In the case of **proprietary** components, the README.md will describe the objective of the component, and how to access the component. The LICENSE file will contain the license of the component.
 
-**Note: during the public release of the component, for proprietary components, only the README.md and the LICENSE file will be copied to the public repository.**
+**Note: for the public release of the proprietary components, only the README and the LICENSE files will be copied to the public repository.**
 
 ## Component placement in the Tecnalia GitLab
 
-The components must be placed in the Tecnalia GitLab. The components must be placed in the `emerald/private/components` group. Inside we have prepared individual groups for each component, i.e `emerald/private/components/amoe`, `emerald/private/components/rcm`, etc.
+The components must be placed in the Tecnalia GitLab. The components must be placed in the `emerald/private/components` group. Inside we have prepared individual groups for each component, e.g., `emerald/private/components/amoe`, `emerald/private/components/rcm`, etc.
 
 **Note: if your component is not in the list, please contact the CaaS Framework administrator to create the group for your component.**
 
-Inside, the component group, you can create repos for each of the images that your component require. For example, the `rcm` component has the following repositories: `frontend`, `backend` and `converter`. 
+Inside the component group, you can create a repo for each of the images that your component require. For example, the `rcm` component has the following repositories: `frontend`, `backend` and `converter`. 
 
-Adittionally, if you require more repositories for your component, you can create them. For example, the `amoe` component has an internal group `emerald/private/components/amoe/python-clients` that contains the code generated with the client libraries. For example, `rcm` has a repository `docker-compose` that contains a compostion that we use to develop rcm, and it also has a `initial-data` component that contain the initial configuration data that we use in the docker-compose project.
+Adittionally, if you require more repositories for your component, you can create them. For example, 
+- The `amoe` component has an internal group `emerald/private/components/amoe/python-clients` that contains the code generated with the client libraries. 
+- The `rcm` has a repository `docker-compose` that contains a composition that we use to build rcm; and it also has an `initial-data` repository that contain the initial configuration data that we use in the docker-compose project.
 
 ## Manual build and publish
 
-The manual build and publish is the simplest way to build and publish a component. It is useful for testing purposes.
+The simplest way to build and publish a component is manually. It is useful for testing purposes.
 
-To build and publish a component manually you will need a Dockerfile.
+To build and publish a component manually, you will need a Dockerfile.
 
 ### Dockerfile
 
@@ -46,19 +50,14 @@ The following is an example of a Dockerfile:
 
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 CMD ["python", "src/main.py"]
 ```
 
-The Dockerfile is a simple example of a python application. It installs the requirements, copies the source code and runs the main.py file.
+The above file is a simple example of a python application. It installs the requirements, copies the source code and runs the main.py file.
 
 ### Build
 
@@ -68,19 +67,17 @@ To build the docker image, you can use the following command:
 docker build -t my-component:latest .
 ```
 
-This command will build the docker image with the tag `my-component:latest`.
+that will build the docker image with the tag `my-component:latest`.
 
-### Login
+### Publish
 
-To publish the docker image, you need to login to the docker image registry. You can use the following command:
+To publish the docker image in some binary repository, you need first to login into the docker image registry. You can use the following command:
 
 ```bash
 docker login -u emerald -p <secure-token> emerald-docker-dev-local.artifact.tecnalia.com
 ```
 
-### Publish
-
-To publish the docker image, you can use the following command:
+To publish the docker image in Tecnalia's Artifactory, you can use the following command:
 
 ```bash
 docker tag my-component:latest emerald-docker-dev-local.artifact.tecnalia.com/my-component/my-component:latest
@@ -89,68 +86,52 @@ docker push emerald-docker-dev-local.artifact.tecnalia.com/my-component/my-compo
 
 ## Dockerfile Recommendations
 
-When developing the dockerfile you should have in mind that depending of how you write the dockerfile, the docker image will be more or less efficient, stable and big. Here are some recommendations:
+When developing the dockerfile you should have in mind that depending of how you write the dockerfile, the resulting docker image will be more (or less) efficient, stable or large. Here are some recommendations:
+
+- **SIZE**. Check the size of the resulting image. The size of the image is important because it affects the time it takes to download the image, the time it takes to start the container, and the amount of disk space used. You can use the `docker image ls` command to check the size of the image. If it is too big, you can try to reduce the size by removing unnecessary files, using a smaller base image, or using multi-stage builds.
+- **SET-UP FILES**. Avoid including large setup files inside the image. If you need to include them, you can use a volume to mount the files at runtime. This will reduce the size of the image.
+- **BASE IMAGES**. Use versioned base images. For example, if you are developing a python application, you can use the `python:3.8` image instead of the `python:latest` image. Using the `latest` tag can lead to unexpected behavior when the base image is updated.
+- **IMAGE SIZE**. Use the smallest base image that you can. For example, if you are developing a python application, you can use the `python:3.8-slim` image instead of the `python:3.8` image.
+- **DEPENDENCIES**. Install dependecies at the beginning of the Dockerfile. This will allow you to take advantage of the docker cache, so that if you change the source code, the dependencies will not be installed again, saving lots of time. For example:
 
-- Check the size of the resulting image. The size of the image is important because it affects the time it takes to download the image, the time it takes to start the container, and the amount of disk space that is used. You can use the `docker image ls` command to check the size of the image. If it is too big, you can try to reduce the size by removing unnecessary files, using a smaller base image, or using multi-stage builds.
-- Avoid including large setup files inside the image. If you need to include large setup files, you can use a volume to mount the files at runtime. This will reduce the size of the image.
-- Use versioned base images. For example, if you are developing a python application, you can use the `python:3.8-slim` image instead of the `python:latest` image. Using the `latest` tag can lead to unexpected behavior when the base image is updated.
-- Use the smallest base image that you can. For example, if you are developing a python application, you can use the `python:3.8-slim` image instead of the `python:3.8` image.
-- Install dependecies at the beginning of the Dockerfile. This will allow you to take advantage of the docker cache. If you change the source code, the dependencies will not be installed again. Saving lots of time. i.e.:
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 CMD ["python", "src/main.py"]
 ```
-- Use multi-stage builds. If your application requires build stage with packages that are not needed in the final image, you can use multi-stage builds. i.e.:
+
+- **MULTI-STAGE**. If your application requires a build stage with packages that are not needed in the final image, you can use multi-stage builds. For example:
+
 ```Dockerfile
 FROM maven:3.6.3-jdk-11 AS build
-
 WORKDIR /app
-
 COPY pom.xml .
-
 RUN mvn dependency:go-offline
-
 COPY src src
-
 RUN mvn package
-
 FROM openjdk:11-jre-slim
-
 WORKDIR /app
-
 COPY --from=build /app/target/my-app.jar .
-
 CMD ["java", "-jar", "my-app.jar"]
 ```
-- Use COPY instead of ADD. The ADD instruction is more powerful than the COPY instruction. However, the ADD instruction can be confusing and lead to unexpected behavior. For example, the ADD instruction can download files from the internet. This can be a security risk. 
 
-- If you need to ensure permissions after COPY use `--chown` option. For example, if you copy a file and you need to ensure that the file has the correct permissions, you can use the `--chown` option. i.e.:
+- **COPY vs ADD**. Use COPY instead of ADD. The ADD instruction is more powerful than the COPY instruction. However, the ADD instruction can be confusing and lead to unexpected behavior. For example, the ADD instruction can download files from the internet. This can be a security risk. If you need to ensure permissions after COPY use `--chown` option. For example, if you copy a file and you need to ensure that the file has the correct permissions, you can use the `--chown` option. i.e.:
+
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY --chown=1000:1000 src src
-
 CMD ["python", "src/main.py"]
 ```
 
-- Combine instructions. If you can combine instructions, you can reduce the number of layers in the docker image. Do not forget to clean up the cache in the same instruction. Use Heredoc syntax to combine instructions. i.e.:
-```Dockerfile
+- **COMBINE INSTRUCTIONS**. Combining instructions, you can reduce the number of layers in the docker image. Do not forget to clean up the cache in the same instruction. Use *Heredoc* syntax to combine instructions. For example:
 
+```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 RUN <<EOF
     set -e
     apt-get update
@@ -161,72 +142,47 @@ RUN <<EOF
     apt-get clean
     rm -rf /var/lib/apt/lists/*
 EOF
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 CMD ["python", "src/main.py"]
 ```
 
-- Define the EXPOSE instruction. The EXPOSE instruction informs not only the user but also other utility containers (i.e. traefik) that the container listens on the specified network ports at runtime. i.e.:
+- **USE EXPOSE**. The EXPOSE instruction informs not only the user, but also other utility containers (i.e. traefik) that the container listens on the specified network ports at runtime. For example:
+
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 EXPOSE 8080
-
 CMD ["python", "src/main.py"]
 ```
 
-- (Optional) Use the HEALTHCHECK instruction. The HEALTHCHECK instruction tells Docker how to test a container to check that it is still working. This can be used to detect when a container is unhealthy. i.e.:
+- **(Optional) USE HEALTHCHECK**. The HEALTHCHECK instruction tells Docker how to test a container to check that it is working. This can be used to detect when a container is unhealthy. For example:
+
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 EXPOSE 8080
-
 HEALTHCHECK --interval=5m --timeout=3s \
   CMD wget -qO- http://localhost:8080/health || exit 1
-
 CMD ["python", "src/main.py"]
 ```
 
-- (Optional) Define VOLUME instruction. The VOLUME instruction creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers. i.e.:
+- **(Optional) DEFINE VOLUMES**. The VOLUME instruction creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers. For example:
+
 ```Dockerfile
 FROM python:3.8-slim
-
 WORKDIR /app
-
 COPY requirements.txt requirements.txt
-
 RUN pip install -r requirements.txt
-
 COPY src src
-
 EXPOSE 8080
-
 VOLUME /app/data
-
 CMD ["python", "src/main.py"]
-```
-
-
-
-
+```
\ No newline at end of file
diff --git a/component_integration.md b/component_integration.md
index f01ae7bf6b6bb44eac3c1bc0f91dddae1ad7c9f6..5d4c031e3c1102f5e911f3352797c451bd193154 100644
--- a/component_integration.md
+++ b/component_integration.md
@@ -1,22 +1,22 @@
+
 # Component Integration
 
-Once the components are developed and their images are published in some accesible registry, the next step is to integrate them into the Caas Framework. The integration of a new component into the Caas Framework is done by adding the component manifests files to the repository and extending the Kustomization file to include those manifests files in the deployment.
+Once a component is developed, and its image published in some accesible registry, we need to integrate it into the CaaS Framework. The CaaS Framework runs in a [Kubernetes](https://kubernetes.io/) cluster. The integration of a new component consist in adding the component manifests files to the repository and extending the Kustomization file to include those manifests files in the deployment.
 
-This document contains the guidelines for integrating a new component into the Caas Framework. The final target in the integration of a new component into the Caas Framework is to submit a merge request. The merge request will be reviewed by the project maintainers and if it is accepted it will be merged into the main branch.
+This document contains the guidelines for integrating a new component into the CaaS Framework. The integration is based in merge requests. The merge request will be reviewed by the project maintainers and, if accepted, merged into the main branch.
 
-The merge request should contain the following information:
-- A folder with the component manifests files.
-- The required sections in the Kustomization file to include those manifests in the Caas Framework deployment.
+The merge request should be based in the followingpreliminar actions:
+- Creation of a folder containing the manifests files for the components.
+- Edit the required sections in the Kustomization file in order to include those manifests in the CaaS Framework deployment.
 
-In the following sections we will explain how to create the merge request with the required information.
+In the following sections we explain how to create the merge request with the required information.
 
 ## Table of contents
-
 - [Merge request initialisation](#merge-request-initialisation)
   - [From an issue](#from-an-issue)
-  - [From a branch](#from-a-branch)
+  - [From a branch before adding the component](#from-a-branch-before-adding-the-component)
+    - [(Optional) Download the branch and add the component](#optional-download-the-branch-and-add-the-component)
   - [From a branch after adding the component](#from-a-branch-after-adding-the-component)
-- [(Optional) Download the branch and add the component](#optional-download-the-branch-and-add-the-component)
 - [Create the component folder](#create-the-component-folder)
   - [Add the component manifests files](#add-the-component-manifests-files)
   - [ConfigMaps](#configmaps)
@@ -28,38 +28,47 @@ In the following sections we will explain how to create the merge request with t
 - [Kustomize check configuration](#kustomize-check-configuration)
 - [Testing the kustomize](#testing-the-kustomize)
   - [Getting the kubeconfig](#getting-the-kubeconfig)
+  - [Check the deployment in the kubernetes cluster](#Acces-the-kubernetes-cluster)
 - [Submit the merge request](#submit-the-merge-request)
 
 
 ## Merge request initialisation
 
-There are many ways to create a merge request in Gitlab. In this section we will explain some of them.
-- From an issue, which is the recommended way.
-- From a branch.
+There are many ways to create a merge request in GitLab. In this section we will explain three of them.
+- From an issue (recommended way).
+- From a branch (before adding the component)
+- From a branch (after adding the component)
 
 ### From an issue
 
-This is the recommended way to create a merge request. The issue should be created before starting the integration of a new component into the Caas Framework. 
+This is the recommended way to create a merge request. The issue should be created before starting the integration of a new component into the CaaS Framework. 
 - [Create a new issue](../../../-/issues/new)
 You can additionally link the issue with the [requirement](https://git.code.tecnalia.com/emerald/private/requirements/-/issues) that this issue contributes to fulfil.
 
-Once the issue is created, you can create a merge request from the issue. The merge request will be linked to the issue and the issue will be automatically closed when the merge request is accepted. 
-
-The creation of the merge request from the issue is done by clicking on the **Create merge request** button in the issue page. That will also include the creation of a new branch in the repository to hold the changes necessary to integrate the component.
+Once the issue is created, you can create a linked merge request by clicking on the <kbd>**Create merge request**</kbd> button in the issue page. That will also create a new branch in the repository that hold the changes. When the merge request is accepted, the linked issue will be automatically closed.
 
 The merge request will be annotated as **draft** so that you can work without the intervention of the project maintainers. Once the component is ready for review, you can change the status of the merge request to **ready for review**. 
 
-### From a branch before adding the component
+### From a branch *before* adding the component
+
+This is an alternative way to create a merge request. You can create a new branch in the repository and then create a merge request from that branch. It is recommended to create the merge request as a **draft**, so that you can work without the intervention of the project maintainers. Once the component is ready for review, you can change the status of the merge request to **ready for review**.
+
+#### (Optional) Download the branch and add the component
 
-This is an alternative way to create a merge request. You can create a new branch in the repository and then create a merge request from that branch. In this case, it is recommended to create the merge request as a **draft** so that you can work without the intervention of the project maintainers. Once the component is ready for review, you can change the status of the merge request to **ready for review**.
+If you create the branch in the GitLab interface before adding the component, you can download the branch as follows:
 
-### From a branch after adding the component
+```bash
+git clone git@git.code.tecnalia.com:emerald/private/devops/CaaS-framework.git
+cd CaaS-framework
+git checkout feature/component_integration
+```
+### From a branch *after* adding the component
 
-Another way to work is to clone the repository, add the component to the repository, and then create a merge request from the branch where you added the component.
+Another way to work is to clone the GitLab repository, add the component in a new branch, push it to the repository, and then create a merge request from that branch.
 
 ```bash
-git clone git@git.code.tecnalia.com:emerald/private/devops/caas-framework.git
-cd caas-framework
+git clone git@git.code.tecnalia.com:emerald/private/devops/CaaS-framework.git
+cd CaaS-framework
 echo "Add the component files to the repository"
 git checkout -b feature/component_integration
 git add .
@@ -67,34 +76,23 @@ git commit -m "Add the component files"
 git push origin feature/component_integration
 ```
 
-## (Optional) Download the branch and add the component
-
-This is applicable if you create the branch from the Gitlab interface before adding the component. You can download the branch as follows:
-
-```bash
-git clone git@git.code.tecnalia.com:emerald/private/devops/caas-framework.git
-cd caas-framework
-git checkout feature/component_integration
-```
-
 ## Create the component folder
 The first step to integrate a new component into the Caas Framework is to create a folder in the repository to hold the component manifests files. The folder should be created inside the components folder of the repository and should have the name of the component. The folder will contain the manifests files of the component.
 
-i.e. for the amoe component, the folder should be named `amoe` and should contain the manifests files of the component.
+E.g., for the amoe component, the folder should be named `amoe` and should contain the manifests files of the component.
 
 ```bash
 mkdir components/amoe
 ```
 
-The type of the manifests files can be different depending on the component. The most common types are:
-- jobs
-- services
-- deployments
-- ingresses
+There are different types of manifests files, depending on the type of component. The most common types are:
+- [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/job/)
+- [services](https://kubernetes.io/docs/concepts/services-networking/service/)
+- [deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
+- [ingresses](https://kubernetes.io/docs/concepts/services-networking/ingress/)
 
 ### Add the component manifests files
-
-The next step is to add the component manifests files to the folder created in the previous step. We recommend to prepend the name of the file with a number to indicate the order in which the files should be applied. There are example of names into the `rcm` component.
+The next step is to add the component manifests files to the created  folder. We recommend to prepend the name of the file with a number to indicate the order in which the files should be applied. There are examples into the `rcm` component [folder](https://git.code.tecnalia.com/emerald/private/devops/caas-framework/-/tree/master/rcm?ref_type=heads)
 
 ### ConfigMaps
 
@@ -102,7 +100,7 @@ It is recommended to create Configmaps using the `kustomize` tool. The contents
 
 ### Secrets
 
-The Secrets will be created using the `kustomize` tool. The files to be used for the secrets generation should be **NOT** be stored in the repository. The secrets should be added in the component folder in a folder named `.secrets`. The secrets will be excluded from the repository because `.gitignore` file contains the `.secrets/` folder. 
+The Secrets will be created using the `kustomize` tool. The files to be used for the secrets generation SHOULD NOT BE STORED in the repository. Fot that, the secrets should be added in the LOCAL component folder, in a folder named `.secrets`, and should be excluded from the repository adding the `.secrets/` folder to the `.gitignore` file. 
 
 ![alt text](.media/image02.png)
 ## Create the Kustomization file for the component
@@ -119,12 +117,12 @@ kustomize create --resources .
 ```
 
 The relevant sections in the Kustomization file are:
- - `resources`: This section contains the list of the manifests files that should be included in the deployment. The manifests files should be relative to the root of the repository.
- - `configMapGenerator`: This section contains the list of the ConfigMaps that should be included in the deployment. The ConfigMaps should be relative to the root of the repository.
- - `secretGenerator`: This section contains the list of the Secrets that should be included in the deployment. The Secrets should be relative to the root of the repository.
+ - `resources`
+ - `configMapGenerator`
+ - `secretGenerator`
 
 ### Kustomize resources
-This is the most common section in the Kustomization file. The `resources` section contains the list of the manifests files that should be included in the deployment. The manifests files should be relative to the root of the repository.
+The `resources` section contains the list of the manifests files that should be included in the deployment. The manifests files should be relative to the root of the repository.
 
 ### Kustomize configMapGenerator
 This section contains the list of the ConfigMaps that should be included in the deployment. If we follow the previous example, the ConfigMaps should use the `configmaps` folder in the component folder.
@@ -132,18 +130,16 @@ This section contains the list of the ConfigMaps that should be included in the
 ### Kustomize secretGenerator
 This section contains the list of the Secrets that should be included in the deployment. The secrets should be in the root of the repository and they should be excluded from the repository in the `.gitignore` file.
 
-The secrets will be added during the CI/CD pipeline execution. The secrets that are not in the repository should be added to the Gitlab CI/CD variables as files. The files should be named with the name of the secret and should contain the secret value.
+The secrets should be added to the GitLab [CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) as files. The files should be named with the name of the secret and should contain the secret value. (Latter, during the CI/CD pipeline execution, the secrets will be taken from a temporary folder and will be added to the root of the repository by the `k8s-pre-apply.sh`.)
 
-Latter, during the CI/CD pipeline execution, the secrets will be added to the root of the repository by the k8s-pre-apply.sh. This script takes the secrets from the temporary folder and adds them to the root of the repository.
+In summary, the steps to add a secret are:
+1. Create the secret file in the component folder, to verify the kustomize configuration. 
+2. Add configuration in the `kustomization.yaml` file to include the secret file.
+3. Check the kustomize configuration.
+4. Add the secret CI/CD setup at the end of the `k8s-pre-apply.sh` file.
+5. Request to some GitLab project [owner or maintainer](https://git.code.tecnalia.com/emerald/private/devops/CaaS-framework/-/project_members) to create the secret in the GitLab CI/CD variables.
 
-In summary the steps to add a secret are:
-- Create the secret file in the component folder, to verify the kustomize configuration. 
-- Add configuration in the kustomization.yaml file to include the secret file.
-- Check the kustomize configuration.
-- Add the secret CI/CD setup at the end of the k8s-pre-apply.sh file.
-- Request a gitlab project [owner or maintainer](https://git.code.tecnalia.com/emerald/private/devops/caas-framework/-/project_members) to create the secret in the Gitlab CI/CD variables.
-
-example of the secret file creation and kustomize configuration:
+This is an example of the secret file creation and kustomize configuration:
 
 ```bash
 cd components/amoe
@@ -164,7 +160,7 @@ cd ../..
 echo 'copy_from_cicd_variables "amoe_redis_secrets" "components/amoe/.secrets/amoe_redis"' >> k8s-pre-apply.sh
 ```
 
-Once the secret is in the Gitlab CI/CD variables, the k8s-pre-apply.sh script will add the secret to the root of the repository.
+Once the secret is placed in the GitLab CI/CD variables, the `k8s-pre-apply.sh` script will add the secret to the root of the repository.
 
 ## Add Keycloak configuration
 
@@ -178,7 +174,7 @@ The next step is to add the component to the base. The base is the base folder o
 
 ## Kustomize check configuration
 
-The Kustomize tool allows you to check the configuration of the Kustomization file. The `kustomize` tool has a command to check the configuration of the Kustomization file. The command is:
+The `Kustomize` tool allows you to check the configuration of the Kustomization file. The `kustomize` tool has a command to check the configuration of the Kustomization file. The command is:
 
 ```bash
 kustomize build `path`
@@ -207,38 +203,39 @@ kustomize build . | kubectl apply -f -
 
 ### Getting the kubeconfig
 
-To get the kubeconfig login into kubernetes https://k8so.emerald.digital.tecnalia.dev/ and download the kubeconfig. **Be aware that the kubeconfig is valid for one month**.
+Yo need the KubeConfig file to access to the Kubernetes cluster from kubctl.
+To get the kubeconfig, login into kubernetes https://k8so.emerald.digital.tecnalia.dev/ and download the kubeconfig (see figure below). **Be aware that the kubeconfig is valid for one month**.
 
-![Kubeconfig Download](.media/image03.png)
-![Kubeconfig deadline](.media/image06.png)
+![Kubeconfig Download](.media/image03.png){width=400}
+![Kubeconfig deadline](.media/image06.png){width=400}
 
-The kubeconfig should be stored in the `~/.kube/config` file. 
+The kubeconfig should be stored in the LOCAL `~/.kube/config` file. 
 
 ```bash
 cat << EOF > ~/.kube/config
 <content of the kubeconfig file>
 EOF
 ```
-![alt text](.media/image07.png)
+![alt text](.media/image07.png){width=50%}
+
+NOTE: The above is valid for one kubernetes cluster. If you have more than one kubernetes cluster, you can store the kubeconfig in different files and use the `KUBECONFIG` environment variable to select the kubeconfig file.
 
 ```bash
 kubectl config get-contexts
 kubectl config use-context local
 ```
 
-The above is valid for one kubernetes cluster. If you have more than one kubernetes cluster, you can store the kubeconfig in different files and use the `KUBECONFIG` environment variable to select the kubeconfig file.
-
-### Access the kubernetes cluster
-
-The kubernetes cluster includes a rancher server that allows you to access the kubernetes cluster. The rancher server is available at https://k8so.emerald.digital.tecnalia.dev/. 
+### Check the deployment in the kubernetes cluster
+The EMERALD kubernetes cluster includes a [Rancher server](https://ranchermanager.docs.rancher.com/) to access the cluster. The rancher is available at https://k8so.emerald.digital.tecnalia.dev/. 
 
-![Rancher Welcome Page](.media/image04.png)
-![Rancher Cluster Selection](.media/image05.png)
+![Rancher Welcome Page](.media/image04.png){width=400}
+![Rancher Cluster Selection](.media/image05.png){width=400}
 
-There you can access the kubernetes cluster and check the deployment of the component.
+There, you can access the kubernetes cluster and check the deployment of the component.
 
-![Rancher UI](.media/image08.png)
+![Rancher UI](.media/image08.png){width=400}
 
 ## Submit the merge request
+Finally, you can submit as many commits as you need to the branch. Once the component is ready for review, you can change the status of the merge request to **ready for review**. The project maintainers will review the merge request and, if it is accepted, they will add a final commit for semantic versioning and willmerged it into the main branch.
 
-You can submit as much commit as you need to the branch. Once the component is ready for review, you can change the status of the merge request to **ready for review**. The project maintainers will review the merge request and if it is accepted they will add a final commit for semantic versioning and it will be merged into the main branch.
+[^k]: https://kubernetes.io/es/
diff --git a/component_update.md b/component_update.md
index b4be0a189b4f837a891ce7123ef0c940ab5a57db..062b93c04a2507f008ff7365026353c5eaab5bd0 100644
--- a/component_update.md
+++ b/component_update.md
@@ -1,12 +1,12 @@
 # Component Update
 
-Components are updated to fix bugs, add new features, or improve performance. In this guide, we will show you how the different ways in which a component can be updated.
+Components are normally updated to fix bugs, add new features, or improve performance. In this guide, we will show you different ways to updated your component.
 
 There are two ways to update a component:
 - Automatically by RenovateBot
 - Manually
 
-Finally, there may be situations when configuration changes are require appart from the component update. This will be explained in the last section.
+There may be situations where, apart from the component update, some configuration changes will be required. This will be explained in the last section.
 
 ## Table of contents
 - [Automatically by RenovateBot](#automatically-by-renovatebot)
@@ -14,24 +14,19 @@ Finally, there may be situations when configuration changes are require appart f
 - [Configuration changes](#configuration-changes)
 
 ## Automatically by RenovateBot
-
-RenovateBot is a tool that helps you to keep your dependencies up to date. It will automatically create pull requests to update the dependencies of the components. It will periodically check the component versions in the docker image registry and create a pull request if a new version is available.
+`RenovateBot` is a tool that helps you to keep your dependencies up to date. It will automatically create pull requests to update the dependencies of the components. It will periodically check the component versions in the docker image registry and create a pull request if a new version is available.
 
 This procedure is transparent to the developers.
 
 ## Manually
-
 This is required when the component does not use versioning. If you need to update a component manually, you can follow these steps:
-- Ensure the new version is available in the docker image registry.
-- Login into the [kubernetes cluster](https://k8so.emerald.digital.tecnalia.dev).
-- Find the pod that uses the component you want to update.
-- Delete the pod.
-- The pod will be recreated with the new version of the component.
+1. Ensure the new version is available in the docker image registry.
+2. Login into the [kubernetes cluster](https://k8so.emerald.digital.tecnalia.dev), and find the pod that uses the component you want to update.
+3. Delete the pod. The pod will be recreated with the new version of the component.
 
 ## Configuration changes
-
 Sometimes, when a component is updated, configuration changes are required. This is because the new version of the component may have new features or changes in the configuration. In this case, the component configuration files should be updated.
 
-To do so, create an issue and an MR in the CaaS Framework repository with the changes required in the configuration files. The MR should be reviewed and merged by the CaaS Framework administrator.
+To do so, create an issue and a Merge Request (MR) in the [CaaS Framework repository](https://git.code.tecnalia.com/emerald/private/devops/caas-framework) with the changes required in the configuration files. The MR should be reviewed and merged by the CaaS Framework administrator.
 
 In the case of automatic updates, it may happen that the component update fails and the MR is not merged. In this case, add the configuration changes to the MR and ask the CaaS Framework administrator to merge it.