diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000000..1df188cc8a5
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,72 @@
+# Contributing to Scylla Operator
+
+## Initial Setup
+
+### Fork the repository
+
+Follow GitHub's official documentation on [forking a repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo).
+
+## Development
+
+To add a feature or to make a bug fix, you will need to create a branch in your fork and then submit a pull request (PR) from the branch.
+A subset of useful commands:
+* `make build` - build project binaries
+* `make test-unit` - run unit tests
+* `make update` - run all code generators
+* `make verify` - verify if all autogenerated changes are generated.
+
+Check `make help` for more.
+
+## Coding convention
+
+Follow these guidelines for writing and structuring your code:
+* [Effective Go](https://go.dev/doc/effective_go)
+* [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments)
+* [API changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
+* [API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)
+
+
+In cases where the existing code doesn't fully follow these conventions, try to be consistent with what's already there. Make sure to familiarize yourself with these resources before making changes.
+
+## Enhancement proposals
+
+For significant features or API changes, you might be required to prepare an enhancement proposal beforehand, as these usually involve broader discussions. If unsure, please consult the [maintainers of the project](https://github.com/scylladb/scylla-operator/blob/master/OWNERS) to learn if your contribution falls into these categories before you start working on the implementation.  
+For further details, see [Enhancement Proposals directory](https://github.com/scylladb/scylla-operator/tree/master/enhancements).
+
+## Submitting a Pull Request
+
+Once you have implemented the feature or bug fix in your branch, open a PR to the upstream repository. Before doing so, ensure the following:
+- Unit tests are included.
+- End-to-end tests are passing.
+- Your commit history is clean.
+
+### Commit History
+
+To maintain a clean commit history, aim for a minimal number of logical commits. Typically, this means a single commit that contains all the changes, with a separate commit for autogenerated parts.
+
+### Commits and PRs
+
+The **subject line** of your commit message **and the PR title** should summarize the change in one clear sentence that would be meaningful to a user of the Operator. The sentence should be **written in the imperative**, i.e. written as if giving a command or instruction, e.g. "Add support for XYZ". A properly formed Git commit subject line should always be able to complete the sentence "If applied, this commit will...", e.g.  "If applied, this commit will **Add support for XYZ**".
+Changelog entries are verbatim PR titles, so make them concise yet informative.
+
+Further details should be added after a blank line. Explain why the change was necessary, not just what was changed. In the general case, extensive descriptions are well-received. Comparing the behavior before and after the change is especially helpful. Write the message with the mindset that you’ll need to revisit the code in the future.
+If your PR fixes an issue, include "Resolves #1234" in the description, replacing "1234" with the issue number.
+
+```
+**Description of your changes:**
+Add new XYZ field to ScyllaCluster CRD.
+The new field allows for configuration of ZYX feature of ScyllaDB.
+<more details>
+API change was discussed in the following enhancement: <link>.
+
+**Which issue is resolved by this Pull Request:**
+Resolves #1234 
+```
+
+### Code review
+
+Refer to [The Standard of Code Review](https://github.com/golang/go/wiki/CodeReviewComments) for best practices when conducting peer reviews or responding to feedback.
+
+### Submitting
+
+After addressing the review feedback, squash your changes into the original commits. Avoid adding new commits. Your PR should always be in a mergeable state.