Tweak documenting process

```

As you can see here, we have at the time of writing this page, 5 main sections:

  * Overview: here we placed high-level information like version changelog, some initial scripts, ...

  * Overview: here we placed high-level information like version changelog, some initial scripts, ...;

  * Getting Started: this section contains a simple way to start working with the project;

  * Testing: detailed information of **how to test** OpenCAPIF, and test plan developed to ensure the code has all implemented functionality checked;

  * Contribute: details about how to contribute code and docs;

mkdocs serve

```

5) Document (and commit)! 😊

5) Document (and commit - *follow the steps in the section below before committing*)! 😊

Before committing, you should make sure that the local *MkDocs* server terminal is not producing any `INFO`/``WARNING`` messages regarding your contributions.

> 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 during development, follow those steps:

To update the documentation properly during development, follow those steps:

1. Perform the development of functionality on ``capif`` code repository;

2. Create an issue on [GitLab](https://labs.etsi.org/rep/ocf/documentation/-/issues);

3. Create a new branch with source from **develop**;

4. Update documentation:

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**

5. Check if errors are being produced by ``mkdocs`` [locally](#getting-started);

6. Push changes to branch;

7. Create a merge/pull request;

8. Send the request to review to at least one TSC Member for approval.

4. Check if errors are being produced by ``mkdocs`` [locally](#getting-started);

5. Push changes to branch;

6. Create a merge/pull request;

7. Send the request to review to at least one TSC Member for approval.

### Release a New Version of the Documentation