streamline contributing guidelines (#753)

Signed-off-by: Felix Breuer <f.breuer94@gmail.com>
Co-authored-by: Felix Breuer <f.breuer94@gmail.com>

Author: stackit-ske

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,9 +1,6 @@
 ---
 name: Bug report
 about: Report a bug in the cloud-provider-stackit
-title: ""
-labels: bug
-assignees: ""
 ---
 
 ## Description
@@ -30,6 +27,8 @@ _Please describe the behavior which you would expect from the cloud-provider-sta
 - Kubernetes version:
 - Version of the cloud-provider-stackit:
 
-**Additional information**
+## Additional information
 
 _Feel free to add any additional information here._
+
+/kind bug

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,9 +1,6 @@
 ---
 name: Feature request
 about: Suggest an idea for the cloud-provider-stackit
-title: ""
-labels: enhancement
-assignees: ""
 ---
 
 ## Problem description
@@ -21,3 +18,5 @@ _A clear and concise description of any alternative solutions or features you've
 ## Additional information
 
 _Feel free to add any additional information here._
+
+/kind enhancement

CONTRIBUTING.md

@@ -13,15 +13,14 @@ For major changes, API changes or features please open a [Discussion](https://gi
 >
 > Use **Issues** if you have a clear plan how to implement to propose how you would do the change.
 
-
 To contribute any code to this repository, just do the following:
 
 1. Make sure you have Go's latest version installed
 2. Fork this repository
 3. Make your changes
    > Please follow the [seven rules of great Git commit messages](https://chris.beams.io/posts/git-commit/#seven-rules)
    > and make sure to keep your commits clean and atomic.
-   > Your PR won't be squashed before merging so the commits should tell a story.
+   > Your PR will be squashed before merging so the commits can and should tell a story.
    >
    > Add documentation and tests for your addition if needed.
 4. Run `make verify` to ensure your code is ready to be merged

docs/release-procedure.md

@@ -19,8 +19,6 @@ This document outlines the standard procedure for creating new releases of the C
   - `PATCH` is incremented for each subsequent release within the same Kubernetes version
 - **CI/CD System:** All release and image builds are managed by our **Prow CI** infrastructure.
 
----
-
 ## Automated Release Process (Primary Method)
 
 The primary release method is automated using a tool called `release-tool`. This process is designed to be straightforward and require minimal manual intervention.
@@ -30,31 +28,18 @@ The primary release method is automated using a tool called `release-tool`. This
 
 Publishing the release automatically creates the corresponding Git tag (e.g., `v1.33.1`), which triggers a separate Prow job to build the final container images and attach them to the GitHub release.
 
----
-
 ## Manual Release Process (Fallback Method)
 
-If the `release-tool` or its associated Prow job fails, you can manually trigger a release by creating and pushing a Git tag from the appropriate release branch.
-
-1. **Check out the release branch:** Ensure you have the latest changes from the correct release branch.
+If the `release-tool` or its associated Prow job fails, use the GitHub web UI to create and publish a release:
 
-   ```bash
-   git checkout release-v1.33.x
-   git pull origin release-v1.33.x
-   ```
+1. Go to the repository on GitHub and click **Releases** on the right side, then click **Draft new release**.
 
-2. **Create the Git tag:** Create a new, annotated tag for the release, following semantic versioning.
+2. Open the **Select tag** dropdown and choose **Create new tag** at the bottom. Enter the new tag name (for example `v2.1.0`) and pick the correct `release-` as target branch, then confirm.
 
-   ```bash
-   # Example for creating version v1.33.1
-   git tag v1.33.1
-   ```
+3. Click **Generate release notes** to let GitHub populate the changelog.
 
-3. **Push the tag to the remote repository:**
+4. In the release description, add a line `Released by @<your github handle>` to indicate the publisher.
 
-   ```bash
-   # Example for pushing tag v1.33.1
-   git push origin v1.33.1
-   ```
+5. Click **Publish release** to create the release.
 
-Pushing a tag that starts with `v` (e.g., `v1.33.1`) automatically triggers the same Prow release job that builds and publishes the final container images. You may need to manually update the release notes on GitHub afterward.
+Publishing a new release triggers the same Prow release job that builds and publishes the final container images.