New/faq section

[akelity]

Description

Update faqs section and add new faqs sub-sections

Pull Request Type

• Documentation content changes
• Bugfix / Missing Redirects
• Docusaurus site code changes

PR Checklist

• The commit message follows our guidelines included in the CONTRIBUTING.md
• All tests of Lint, cspell and check-content pass. (How to launch them?)
• No sensitive content has been committed

[marcofilippi]

here we can also point out that the merge of configurations may happen also when two users are currently working on the same branch/revision:
if there are remote changes and you want to make your changes too, a warning shows up when opening the action popover, telling the users that they have current local changes but there are also remote changes that should be addressed

[marcofilippi]

i would not tell about the Design Overview, since in the future will be incorporated in the evolution of the software catalog

[marcofilippi]

we don't strictly follow this pattern when it comes to PATCHES: sometimes we also include very small features, especially if there are only a few of them.

[graz-dev]

Review first round

[graz-dev]

Suggested change

The Mia-Platform Console is a cloud-native Platform Builder that functions as an **internal developer platform** (**IDP platform**). It's designed to help organizations industrialize and govern the entire software development lifecycle. By providing a centralized **developer portal**, it simplifies cloud-native complexity, empowers development teams with self-service capabilities, and allows **platform engineers** to enforce governance and **platform engineering best practices**. The Console manages everything from infrastructure connection to API design, deployment, and monitoring.

The Mia-Platform Console is a cloud-native Platform Builder that functions as an **Internal Developer Platform (IDP)**. It's designed to help organizations industrialize and govern the entire software development lifecycle. By providing a centralized **developer hub**, it simplifies cloud-native complexity, empowers development teams with self-service capabilities, and allows **platform engineers** to enforce governance and **platform engineering best practices**. The Mia-Platform Console manages everything from infrastructure connection to API design, deployment, and monitoring.

I think using the "portal" term here can be misleading.

[graz-dev]

Suggested change

A **Company** is the highest-level organizational unit in the Console. It acts as a container for multiple **Projects** and provides centralized governance. At the Company level, you configure shared resources that are inherited by all its projects, such as Kubernetes cluster connections, **Providers** (like Git providers and secret managers), and default project templates. This structure allows an organization to manage different business units or teams in an isolated and organized manner.

A **Company** is the highest-level organizational unit in the Mia-Platform Console. It acts as a container for multiple **Projects** and provides centralized governance. At the Company level, you configure shared resources that are inherited by all its projects, such as Kubernetes cluster connections, **Providers** (like Git providers and secret managers), and default project templates. This structure allows an organization to manage different business units or teams in an isolated and organized manner.

We should't use the term Console or products name alone.
We should always use them with the "Mia-Platform" prefix.
It's a valid feedback for the whole PR, so please check the whole content event if I didn't left an explicit suggestion.

Then I suggest to add the link to the providers page where provider are mentioned.

[graz-dev]

Suggested change

	* A **Project** is where you build a specific application or system. It contains all the necessary configurations, including microservices, APIs, data models (CRUDs), and public variables. Each Project belongs to a Company.
	* A **Project** is where you build your services. It contains all the necessary configurations, including microservices, APIs, data models (CRUDs), and public variables. Each Project belongs to a Company.

Not always there is a 1:1 relationship between projects and application.

[graz-dev]

Suggested change

	* An **Environment** represents a specific deployment stage within a Project, such as `Development`, `Staging`, or `Production`. Each environment is mapped to a unique namespace in a Kubernetes cluster, allowing you to deploy and test your configurations in isolated runtime contexts.
	* An **Environment** represents a specific deployment stage within a Project, such as `Development`, `Staging`, or `Production`. Each environment is mapped to a unique namespace in a Kubernetes cluster, allowing you to deploy and test your services in isolated runtime contexts.

[graz-dev]

@marcofilippi we shold agree here if we can keep using the "Project Template" or "Project Blueprint" wording.

[graz-dev]

Suggested change

	To create a new Project, you must first have a Company, a Git Provider, and a Project Template configured. From the Console homepage, click "Create Project" and follow the three-step wizard:
	To create a new Project, you must first have a Company, a Git Provider, a CI/CD Provider, a Secret Management Provider and a Project Template configured. From the Console homepage, click "Create Project" and follow the three-step wizard:

[claudiafocchi]

Here I would include the complete list of all supported items:
Plugins
Templates
Examples
Applications
Sidecars
Proxies
Infrastructure resources
Extensions
Infrastructure Component runtime

[claudiafocchi]

This is too focused on microservices. I would suggest rephrasing the sentence like this: 'Based on the type of item instantiated (e.g., microservices, sidecars, etc), it will appear in the corresponding list within the Design section of your project.'