moves GOVERNANCE to documentation folder and expands MS

GOVERNANCE.md → documentation/GOVERNANCE.md

@@ -13,7 +13,7 @@ The following page introduces this process, the involved roles, and the states i
 | Modeling Team | Regular meeting round to discuss and moderate the modeling activities. |
 | Use Case | Application or scenario were the need for the model creation or update arises. In general, it is assumed that a use case consists of at least one data provider and one data consumer |
 
-### MS1 Request for Model
+### Modeling State 1 (MS1) Request for Model
 
 When there is a requirement for a new or modified Aspect model, a domain expert from that use case initiates the modeling process by creating a new issue on GitHub (Tab: Issues -> Button: New Issue or [this link](https://github.com/eclipse-tractusx/sldt-semantic-models/issues/new/choose)). 
 Depending on the type of request (new model, model update, model deprecation), one may use different templates for the issue. 
@@ -24,7 +24,7 @@ With the MS1 checklist and approval, the idea is to initiate the exchange betwee
 This way, model developers get fast feedback before investing time and effort on models for which they might not get an agreement within the modeling team. 
 The discussion of the model modifications shall further create awareness of currently ongoing modeling activities across modelers and use cases to avoid duplicate models and development for the same topic.
 
-### MS2 Valid Model
+### Modeling Stage 2 (MS2) Valid Model
 In the next step, the assigned domain experts and the modeling experts perform the modeling work and create a solution to fulfill the initial request.
 This work happens on a dedicated development branch preferably in a forked repository (for details regarding Forks in GitHub consult the [GitHub documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)).
 As a result of this phase, the model developers propose the changes by creating a Pull-Request (PR) to commit the content of the new or updated model to the main-branch of the Tractus-X model repository.
@@ -33,7 +33,7 @@ The PR should link the initial issue requesting the change, e.g., by mentioning
 There is a template for this PR, which contains a checklist of modeling-specific guidelines.
 It is the task of the modeling expert to check that the proposed model conforms to all items and best practices in the modeling checklist. 
 To indicate the conclusion of the modeling phase and that the model is ready for release and adoption, the modeling expert adds the label "MS2-Approved" to the PR.
-### MS3 Release Model
+### Modeling Stage 3 (MS3) Release Model
 The domain expert then checks with the use case team from which the initial modeling request originated to whether the proposed changes fulfill the requirements and that the use case will use it. There is a MS3 checklist in the PR template to guide the approval. This checklist, for example, asks whether there is at least one data provider and one data consumer planing to exchange data based on the definition in the proposed model. There is no specific process for getting the approval for the use case since this strongly depends on its working mode. However, one proven practice is to post the model and visualization in the working space of the use case team and ask for comments during a dedicated review period which could be one week. After the approval of the use case, the modeling team checks during one of its meetings that the proposed changes align with the other models in Tractus-X and that the model is ready for adoption from a modeling standpoint. The discussion of the model also helps the modeling team members to keep track of current modeling activities. If the use case and the modeling team approve the PR, the modeling team assigns the label "MS3-Approved" and merges the PR into the main branch of this Tractus-X models repository.
 
 ## Labels