From aea67a7c3b954d99da11d8bc53a5d3cd20aa07f1 Mon Sep 17 00:00:00 2001
From: sattij <julien.satti@etsi.org>
Date: Mon, 6 Jan 2025 12:18:59 +0000
Subject: [PATCH] Tweak documenting process

---
 doc/contribute/documenting.md | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/doc/contribute/documenting.md b/doc/contribute/documenting.md
index 2d6414a6..5c788f9f 100644
--- a/doc/contribute/documenting.md
+++ b/doc/contribute/documenting.md
@@ -91,25 +91,23 @@ python -m pip install mike
 mkdocs serve
 ```
 
-5) Document (and commit - *follow the steps in the section below before committing*)! 😊
+5) Document! 😊
 
 > You should always make sure that the local *MkDocs* server terminal is not producing any `INFO`/``WARNING`` messages regarding your contributions.
 
-> The documentation website supports branches, so your accepted changes will be reflected to the **develop** branch which becomes the **release** branch after each corresponding cycle.
-
 ### Add Documentation During Development
 
-To update the documentation properly during development, follow those steps:
+To update the documentation properly during development, follow those additional steps:
 
 1. Create an issue on the documentation [GitLab](https://labs.etsi.org/rep/ocf/documentation/-/issues) repository;
 2. Create a new branch with the **develop** branch as a source;
-3. Update the documentation:
-    1. **Remember to update index.md with new functionalities for the latest version**;
-    2. If a new test plan is defined, remember to **update the test plan documentation**
-4. Check if errors are being produced by ``mkdocs`` [locally](#getting-started);
-5. Push changes to branch;
+3. Update the documentation and any relevant parts (ie: the ``index.md`` with new functionalities for the latest version** or if a new test plan is defined, remember to **update the test plan documentation**);
+4. Check if errors are not being produced by ``mkdocs`` [locally](#getting-started);
+5. Commit and push changes to the new branch;
 6. Create a merge/pull request;
-7. Send the request to review to at least one TSC Member for approval.
+7. Send the request for review and approval to at least one **TSC Member**.
+
+> The documentation website supports branches, so your accepted changes will be reflected to the **develop** branch which becomes the **release** branch after each corresponding cycle.
 
 ### Release a New Version of the Documentation
 
-- 
GitLab