diff --git a/docs/about.md b/docs/about.md
index 5fbe8981..e1361922 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -16,7 +16,7 @@ Suggesting improvements and best practices or applying quality standards and aut
In a service driven IT sector (with calculated ambiguities and many hidden interests) the product is the hours billed by the consultant, being almost irrelevant the **content of the job and the delivered quality**. It is thus too common to find technical solutions under the policy of applying "the most difficult, non-standard, slowest and most obfuscated way possible" as a competitive element ([the hard way](https://www.fairwinds.com/blog/never-should-you-ever-in-kubernetes-1-do-k8s-the-hard-way) and doing weird things). This does not scale. Being ambiguous in JDs (not to say dishonest) without clarifying the real content of the job is easy and very well paid.
-**Ambiguities about DevOps term**. Development of new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of devops specialists. DevOps professionals develop IaC and CI/CD pipelines with standard tools and code, ideally with a [cattle service model](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle), GitOps patterns & [kubernetes](https://www.nextplatform.com/store/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/1654000) among other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with [client-go skills](https://itnext.io/generically-working-with-kubernetes-resources-in-go-53bce678f887), a developer of devops/kubernetes/monitoring tools). In addition, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Moreover, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin. Maybe DevOps should be renamed as OpsDev to avoid misunderstandings.
+**Ambiguities about DevOps term**. Development of new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of devops specialists. DevOps professionals develop IaC and CI/CD pipelines with standard tools and code, ideally with a [cattle service model](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle), GitOps patterns & [kubernetes](https://www.nextplatform.com/store/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/1654000) among other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with [client-go skills](https://itnext.io/generically-working-with-kubernetes-resources-in-go-53bce678f887?gi=d8016dbe6b59), a developer of devops/kubernetes/monitoring tools). In addition, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Moreover, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin. Maybe DevOps should be renamed as OpsDev to avoid misunderstandings.
A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended[^1] approach.
@@ -125,8 +125,8 @@ These are the core tools and frameworks that have been or are significant in my
- [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc) [DE FACTO STANDARD] — Standardizing Jenkins master configuration via declarative YAML, eliminating configuration drift and manual UI administration.
- [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli) [GUIDE] — Command-line interface for managing and triggering jobs in Jenkins automation server.
- [Jenkins Remote Access API](https://www.jenkins.io/doc/book/using/remote-access-api) [GUIDE] — Programmatic REST API endpoints for Jenkins integration and orchestration.
-- [GitLab CI/CD](https://docs.gitlab.com/ee/ci) [DE FACTO STANDARD] — Built-in continuous integration and delivery engine of GitLab, supporting declarative YAML pipeline specifications.
-- [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines) [DE FACTO STANDARD] — Cloud-hosted CI/CD pipeline service by Microsoft, supporting both Windows, Linux, and macOS environments.
+- [GitLab CI/CD](https://docs.gitlab.com/ci) [DE FACTO STANDARD] — Built-in continuous integration and delivery engine of GitLab, supporting declarative YAML pipeline specifications.
+- [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops) [DE FACTO STANDARD] — Cloud-hosted CI/CD pipeline service by Microsoft, supporting both Windows, Linux, and macOS environments.
- [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) [DE FACTO STANDARD] — Automatic generation of API client libraries and server stubs from OpenAPI/Swagger specifications.
- [Postman](https://www.postman.com) [DE FACTO STANDARD] — The industry-standard platform for API design, testing, mock servers, and automated collection runs.
- [Terraform Kubernetes Provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) [DE FACTO STANDARD] — Official Kubernetes provider for Terraform, enabling declarative deployment and management of Kubernetes resources using HashiCorp Configuration Language (HCL).