Update contribution relevant guides (#2993)

Co-authored-by: Lukas Hinterreiter <[email protected]>

.github/pull_request_template.md

@@ -1,21 +1,33 @@
+<!--
+
+Thanks for opening a pull request! Here are some tips to get everything merged smoothly:
+
+1. Read our contributor guidelines: https://github.com/Dynatrace/dynatrace-operator/blob/main/CONTRIBUTING.md
+
+2. If the PR is unfinished, raise it as a draft or prefix the title with "WIP:" so it's clear to everyone.
+
+3. Be sure to allow edits from maintainers, so it's easier for us to help: https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork
+
+-->
+
 ## Description
 
+<!--
+
 Please include the following:
+- The motivation for the change
+    - Link to the Github issue or Jira ticket, if exists.
+- The summary of the change
 
-- A meaningful PR title [guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#use-imperative-mood-in-your-commit-message-subject)
-- A summary of the change
-- Which issue is fixed (if there is one)
-- Relevant motivation and context
+-->
 
 ## How can this be tested?
 
+<!--
+
 Please include some guiding steps on how to test this change during a review.
 
 - What environment is necessary for the change to be noticeable ?
 - What needs to be enabled/applied for the change to be noticeable ?
 
-## Checklist
-
-- [ ] Unit tests have been updated/added
-- [ ] PR is labeled accordingly with a single label
-- [ ] I have read and understood the [contribution guidelines](https://github.com/Dynatrace/dynatrace-operator/blob/main/CONTRIBUTING.md)
+-->

CONTRIBUTING.md

@@ -1,6 +1,7 @@
 # Contributing
 
-- [Steps](#steps)
+- [Pull requests](#pull-requests)
+- [Quick start](#quick-start)
 - [Unit tests](#unit-tests)
 - [E2E tests](#e2e-tests)
 - [Useful commands](#useful-commands)
@@ -9,7 +10,19 @@
   - [Add debug suffix on E2E tests to avoid removing pods](#add-debug-suffix-on-e2e-tests-to-avoid-removing-pods)
   - [Debug cluster nodes by opening a shell prompt (details here)](#debug-cluster-nodes-by-opening-a-shell-prompt)
 
-## Steps
+## Pull requests
+
+Make sure all the following are true when creating a pull-request:
+
+- The [coding style guide](doc/coding-style-guide.md) was followed when creating the change.
+- The PR has a meaningful title [guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#use-imperative-mood-in-your-commit-message-subject).
+- The PR is labeled accordingly with a **single** label.
+- Unit tests have been updated/added.
+- Relevant documentation has been updated/added.
+  - [ARCHITECTURE.md](https://github.com/Dynatrace/dynatrace-operator/blob/main/ARCHITECTURE.md)
+  - [Other docs](https://github.com/Dynatrace/dynatrace-operator/blob/main/doc)
+
+## Quick start
 
 1. Read the [coding style guide](doc/coding-style-guide.md).
 
@@ -27,10 +40,11 @@
    ```
 
 4. Create a new branch to work on:
+   - Group your branch into a category using a prefix for your branch name, like `feature/`, `ci/`, `bugfix/`, `doc/`.
 
-   ```sh
-   git checkout -b feature/your-branch
-   ```
+      ```sh
+      git checkout -b feature/your-branch
+      ```
 
 5. Once the changes are finished, make sure there are no warnings on the code. For debugging you can [run the unit tests](#unit-tests) and [end-to-end tests](#e2e-tests).
 

doc/coding-style-guide.md

@@ -21,11 +21,17 @@
 
 ## General
 
-- Use descriptive names (`namespace` is better than `ns`, `dynakube` is better than `dk`, etc.)
+- Use descriptive (variable) names
+  - Shortnames for known Kubernetes Objects are fine. (`ns` for namespace)
+  - Avoid "stuttering". (In the `beepboop` package don't call you `struct` `BeepBoopController`, but just `Controller`)
+    - Relevant for: folder/package, file, struct, func and const/variable names.
+  - Do NOT shadow builtin names and packages.
 - Avoid using `client.Client` for 'getting' resources, use `client.Reader` (also known as `apiReader`) instead.
   - `client.Client` uses a cache (or tries to) that requires more permissions than normally, and can also give you outdated results.
-- Do not create methods with more than two parameters (in extremely rare occasions maybe three) except constructors and factory functions. Structs and interfaces exist for a reason.
+- Avoid creating functions with more than 3 params, except constructors and factory functions. Structs and interfaces exist for a reason.
 - Avoid returning responses (e.g., reconcile.Result, admission.Patched) in anything but Reconcile or Handle functions.
+- Run the linters locally before opening a PR, it will save you time.
+  - There is a pre-commit hook that you can configure via `make prerequisites/setup-pre-commit`
 
 ## Function Parameter and Return-Value Order