docs/git/Workflow.md

+In a nutshell (click the individual steps for detailed guidelines):
+
+   ```mermaid
+   graph LR
+    A{Question/Bug/Feature Request?}
+    --> B(Create an issue)
+    --> B1(Issue Review)
+    --> C(Expert Discussion)
+    --> D(Concept development)
+    --> E(Concept Implementation)
+    --> F(Review and merge)
+    click B "/simulation/wiki/-/wikis/docs/git/Workflow#create-an-issue" "d"
+    click B1 "/simulation/wiki/-/wikis/docs/git/Workflow#issue-review" "d"
+    click C "/simulation/wiki/-/wikis/docs/git/Workflow#expert-discussion" "a"
+    click D "/simulation/wiki/-/wikis/docs/git/Workflow#concept-development" "a"
+    click E "/simulation/wiki/-/wikis/docs/git/Workflow#concept-implementation" "a"
+    click F "/simulation/wiki/-/wikis/docs/git/Workflow#review-and-merge" "a"
+   ```
+
+
+# Create an Issue
+1. Any questions, todos, bugs, requests?\
+   -> Create an Issue in the repository for the standard (make sure to check to see if a similar issue exists already)
+
+1. When creating an issue, select a relevant template. This will provide you a basic template to fill out and assign some initial labels to the issue\
+~Feature  ~Question  ~Bug
+
+1. If you already know what group the issue is relevant for, add it as a label, e.g.:\
+~TrafficParticipants ~SensorModeling ~HarmonisationOpenX ~Performance&Packaging
+
+1. If you know what WP the issue is for, add it as a label, e.g.:\
+~WP-V2X  ~"WP-OSI as a measurement file"
+
+See [Label Types](../git/ASAM-Issue-and-MR-Labels) for an overview of available ASAM labels. Feel free to create further labels for your groups. If you create a new label, please update the wiki page [here](../git/ASAM-Issue-and-MR-Labels).
+
+# Issue Review
+
+The Change Control Board(CCB) ([see CCB]](../project_guidelines/CCB)) is expected to regularly review and maintain the issues in the repository. CCB members will review any new issues and either answer them directly (if of type ~Question ) or categorise the issues and assign them to a project group for further review. If it is decided that the issue should be addressed and requires further discussion or implementation, it is assigned the ~Analysis label.
+
+# Expert Discussion
+
+During their weekly meetings, each group in an ASAM project is expected to review the open issues assigned to their group and, if new ones are present, label them further and determine the next steps in order to address the issue. 
+
+Issue status should be changed from ~Analysis to ~Concept to indicate the group has reviewed it and is discussing concepts to address it. 
+
+Next steps include (in no particular order):
+
+- Assigning the issue to a responsible
+- Discussing a concept to address the issue
+  - Use the comment functionality on issues and merge requests to discuss the topic
+  - Flag people for discussion with @  (this will bring up a popup)
+  - See [this cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) for tips and tricks for comment formatting
+  - Additionally, refer to the full documentation - Make sure to click the right link for the platform [GitHub](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github) / [GitLab (code.asam.net)](https://docs.gitlab.com/ee/user/markdown.html)
+
+
+## Concept development
+
+Once an initial concept has been agreed upon (e.g. as a documentation extension or a new feature in the standard) the first active development can begin.
+>This does not mean that proposals or suggestions cannot be developed in repository branches or forks during the discussion!
+
+Some tips:
+- Collaborate on the same branch, we don’t need a new one everytime
+- Commit and push/pull regularly to prevent headaches!
+- Use clear commit messages to make sure others understand what you have been doing! (see [Commit Guidelines](../git/Commit-Guidelines))
+- See [Resolving Merge Conflicts](../git/Resolving-Merge-Conflicts) for some tips if you have problems with pushing/pulling to a branch
+> Project members for ASAM projects are able to branch directly (see [How to create a Branch](./Branching)). Non-project members will need to use the fork & PR process (see [Forking](./Forking))
+
+# Concept Implementation
+
+Once a concise concept has been developed by the involved members, the status is changed to ~Implementation 
+
+This indicates to the contracted service provider (if relevant), that the concept is ready for their review and final implementation. This will include changes to data models, documentation or (rarely) code, depending on the contract with the provider.
+
+## Concept Review 
+
+Should the developed concept not be concise
+
+
+# Review and merge
\ No newline at end of file