Add a contributing guide (#315)

This adds instructions for people who want to contribute and also
documents the release process for maintainers.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Added contributor guidelines covering development setup, testing
procedures, and release processes.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

CONTRIBUTING.md

@@ -0,0 +1,60 @@
+# Contributing
+
+This document covers instructions and expectations when contributing to the project.
+
+Questions and feature requests should be discussed in [GitHub Discussions](https://github.com/netbirdio/kubernetes-operator/discussions) while bugs should be reported as an [issue](https://github.com/netbirdio/kubernetes-operator/issues).
+
+## Acceptance Policy
+
+This project is issue first driven. Meaning that any new PR should be linked to either a bug or feature issue. Any PR that has not been discussed first in an issue or with a maintainer can be closed without reason.
+
+All PRs are expected to be tested locally before they are submitted. PRs from non maintainers need approval to run GitHub actions meaning that you cannot submit a PR to run tests. If all steps covered in the development section passes then the CI should also pass.
+
+To keep commit history clean, keep PRs to consist of a single commit. Once the PR is ready to review squash the commit history if there are multiple commits.
+
+## Development
+
+The linter enforces any coding standards that are required.
+
+```bash
+make lint
+```
+
+Documentation and CRDs need to be generated after making changes to the API structs.
+
+```bash
+make generate
+```
+
+Unit tests use an in memory Kubernetes cluster to test controller functionality.
+
+```bash
+make test-unit
+```
+
+The e2e tests cover the installation and upgrade steps, along with testing certain functionality.
+
+```bash
+make test-e2e
+```
+
+You can run the operator locally against any cluster that you have access to. Running the operator like this means however that webhooks will not work.
+
+```bash
+NB_API_KEY=${API_KEY} make run
+```
+
+## Releases
+
+This project uses semantic versioning for releases. Each new release with new features should receive a new minor version. Release branches are to be able to backport bug fixes and cut patch releases without including new features. This makes the release process stable as it does not force releasing changes that may depend on other systems. Every new minor release tag should be done in a branch with the name format `release/v0.7.x`, any backported changes should be done to this branch and then the commit in the branch should be tagged with a new patch version.
+
+Follow these steps to release a new version.
+
+1. If this is a new minor release create a new release branch from the last commit to the main branch.
+2. Create a [new release](https://github.com/netbirdio/kubernetes-operator/releases/new) in GitHub.
+3. Create a new tag with the version of the release and make sure that the target branch is the release branch.
+4. Set the title of the release to be the same as the release version.
+5. Click the "Generate release notes" button so that release notes are added.
+6. Publish the release.
+
+Once this is done a [release action](https://github.com/netbirdio/kubernetes-operator/blob/main/.github/release.yaml) should be started automatically that publishes a new [operator image](https://github.com/netbirdio/kubernetes-operator/pkgs/container/netbird-operator) and [Helm chart](https://github.com/netbirdio/kubernetes-operator/pkgs/container/helm-charts%2Fnetbird-operator).