chore: Update contributing guide about commits

CONTRIBUTING.md

@@ -1,32 +1,29 @@
-# Contributing to the Configuration as Code Tool Monaco
-
-- [Contributing to the Configuration as Code Tool Monaco](#contributing-to-the-configuration-as-code-tool-monaco)
-  - [What to contribute](#what-to-contribute)
-  - [How to contribute](#how-to-contribute)
-  - [Examples of Commit Style Messages](#examples-of-commit-style-messages)
-  - [Code of Conduct and Shared Values](#code-of-conduct-and-shared-values)
-  - [Building the Dynatrace Configuration as Code Tool](#building-the-dynatrace-configuration-as-code-tool)
-  - [Testing the Dynatrace Configuration as Code Tool](#testing-the-dynatrace-configuration-as-code-tool)
-    - [Integration Tests](#integration-tests)
-    - [Writing Tests](#writing-tests)
-  - [Checking in go mod and sum files](#checking-in-go-mod-and-sum-files)
-  - [General information on code](#general-information-on-code)
-    - [Test Mocks](#test-mocks)
-    - [Formatting](#formatting)
-  - [Pre-Commit Hook](#pre-commit-hook)
-  - [A note on Dynatrace APIs](#a-note-on-dynatrace-apis)
+# Contributing to the Configuration as Code Tool `Monaco`
+
+Thank you for considering contributing to Monaco.
+We welcome contributions from the community to help improve and expand Monaco's capabilities.
+Please follow the guidelines below to ensure a smooth contribution process.
+
+- [What to contribute](#what-to-contribute)
+- [How to contribute](#how-to-contribute)
+  - [Commit structure](#Commits)
+- [Code of Conduct and Shared Values](#code-of-conduct-and-shared-values)
+- [Building the Dynatrace Configuration as Code Tool](#building-the-dynatrace-configuration-as-code-tool)
+- [Testing the Dynatrace Configuration as Code Tool](#testing-the-dynatrace-configuration-as-code-tool)
+  - [Integration Tests](#integration-tests)
+  - [Writing Tests](#writing-tests)
+- [Checking in go mod and sum files](#checking-in-go-mod-and-sum-files)
+- [General information on code](#general-information-on-code)
+  - [Test Mocks](#test-mocks)
+  - [Formatting](#formatting)
+- [Pre-Commit Hook](#pre-commit-hook)
+- [A note on Dynatrace APIs](#a-note-on-dynatrace-apis)
 
 ## What to contribute
 
-This tool was created out of the following needs but not limited to:
-
-* Provide an easy way to deploy numerous Dynatrace configurations for several applications across different environments such as Development, Pre-production, and Production environments to maintain consistency.
-
+Monaco was created to easily manage Dynatrace configurations at scale across different Dynatrace environments and accounts.
 Thus, this tool aims to provide a way to reproducibly deploy Dynatrace configuration in a "configuration as code"-way.
 
-As with all things Dynatrace, scalability is an important requirement, both in the number of configuration files and the number of environments.
-This is also the area currently offering the most opportunity to improve the tool.
-
 ## How to contribute
 
 The easiest way to start contributing or helping with the Configuration as Code project is to pick an existing [issue/bug](https://github.com/dynatrace/dynatrace-configuration-as-code/issues) and [get to work](#building-the-Dynatrace-Configuration-as-Code-Tool).
@@ -38,71 +35,100 @@ This allows being respectful of the time of community contributors.
 
 The repo follows a relatively standard branching & PR workflow.
 
-Branches naming follows the `feature/{Issue}/{description}` or `bugfix/{Issue}/{description}` pattern.
-
-Branches are rebased, and only fast-forward merges to main are permitted. No merge commits.
+Branches naming follows the `feature/{Issue}/{description}` or `bugfix/{Issue}/{description}` pattern. \
+Branches are rebased, and only fast-forward merges to main are permitted. \
+No merge commits.
 
 By default, commits are not auto-squashed when merging a PR, so please ensure your commits are fit to go into main.
 
 For convenience auto-squashing all PR commits into a single one is an optional merge strategy - but we strive for [atomic commits](https://www.freshconsulting.com/insights/blog/atomic-commits/)
 with [good commit messages](https://cbea.ms/git-commit/) in main, so not auto-squashing is recommended.
 
-Commits should conform to  [Conventional Commit](https://www.conventionalcommits.org/) standard.
+### Commits
 
-### Examples of Commit Style Messages
+Each commit must conform to a [Conventional Commit], with a [good commit message] and [atomic commits].
 
-New Feature Changes
-``` 
-feat: allow provided config object to extend other configs
-```
+[Conventional Commit]: https://www.conventionalcommits.org/
+[good commit message]: https://cbea.ms/git-commit/
+[atomic commits]: https://dev.to/samuelfaure/how-atomic-git-commits-dramatically-increased-my-productivity-and-will-increase-yours-too-4a84
 
-Bug Fix Changes
-```
-fix: change function call
+#### Conventional commits - prefixes
 
-see the issue for details
+* Production code
+  * `feat`: New code has been written to support a new feature
+  * `fix`: Bug fix of production code (not in build scripts)
+  * `refactor`: Refactor production code
+  * `test`: Add missing tests, refactor tests, ... 
+* Non-production code
+  * `ci`: Build system changes (workflows, linting, ...) 
+  * `chore`: Updating non-production code (that is not `ci:`) 
+  * `docs`: Changes to the documentation (not GoDoc documentation)
 
-on typos fixed.
+#### Examples
 
-Reviewed-by: Z
-Refs #133 
+**New feature change**
+``` 
+feat: Add support for federated attribute values in account groups
+
+This change adds support for `federatedAttributeValues` to account groups.
+This allows Monaco to deploy groups with owner `SAML`.
 ```
 
-Documentation Changes
+Bug Fix Changes
 ```
-docs: correct getting started guide 
+fix: Very important feature misbehaved
+
+Instead of thing A, B happened. This change fixes this behavior by introducing C and checking for D.
 ```
 
 More examples can be found [here](https://www.conventionalcommits.org/en/v1.0.0/#examples)
 
 
 ## Code of Conduct and Shared Values
 
-Before contributing, please read and approve [our Code Of Conduct](https://github.com/dynatrace/dynatrace-configuration-as-code/blob/main/CODE_OF_CONDUCT.md) outlining our shared values and expectations. 
+Before contributing, please read and approve [our Code Of Conduct](./CODE_OF_CONDUCT.md) outlining our shared values and expectations. 
 
 ## Building the Dynatrace Configuration as Code Tool
 
-The `monaco` tool is written in [Go](https://golang.org/), so you'll need to have [installed Go](https://golang.org/dl/) to build it.
+This section describes how to build and test Monaco.  
 
-To build the tool, run `make build` in the repository root folder.
+### Requirements
+* Latest [Go] version
 
-**_NOTE:_**  `$GOPATH/bin` is required to be loaded in your `$PATH`
+[Go]: https://golang.org/
 
-> This guide references the make target for each step. If you want to see the actual Go commands take a look at the [Makefile](./Makefile)
+### Building Monaco
+To build Monaco, execute the following command in the repository root folder:
+```shell
+go build ./cmd/monaco
+```
 
-To install the tool to your machine, run `make install` in the repository root folder.
+This command builds the `monaco` executable which then can be executed with:
+```shell
+./monaco version
+```
 
-This will create a `monaco` executable you can use.
+### Install Monaco from source
 
-To build a platform-specific executable, run: `GOOS={OS} GOARCH={ARCH} make build`.
+To install Monaco from source, execute the following command in the repository root folder:
+```shell
+go install ./cmd/monaco
+```
 
-For example, a Windows executable can be built with `GOOS=windows GOARCH=386 make build BINARY=monaco.exe`.
+This will create a `monaco` executable and install it inside the path `$GOBIN` (defaults to `$GOPATH/bin`).
 
 ## Testing the Dynatrace Configuration as Code Tool
 
-Run the unit tests for the whole module with `make test` in the root folder.
+To run the unit tests for Monaco, execute the following commands in the repository root folder:
+```shell
+# Generate mock files
+go generate ./...
 
-For convenience, single package tests can be run with `make test-package pkg={PACKAGE}` - e.g. `make test-package pkg=api`.
+# Execute all tests
+go test -tags=unit -v -race ./...
+```ª
+
+Note: The `go generate ./...` command must only be executed if the source files changed, not on every test run.
 
 ### Integration Tests
 
@@ -130,8 +156,6 @@ Instead, whenever you need to test a path, make sure to do it in one of these wa
 * Use the public function `ReplacePathSeparators`, which replaces path separators in a given string with `os.PathSeparator`
 
 We use [github.com/stretchr/testify](github.com/stretchr/testify) as our testing library.
-
-> You might still find `gotest.tools` used for asserts in a few places, as it's being replaced. If you change a test file using it, replace it.
 
 We use `require` for asserting test requirements after which it makes no sense to continue - e.g. no error was returned, a slice has the expected length, pointers aren't nil, etc. - as it will fail the test immediately and exit.