Update docs with a note on draft PRs and workflow runs

docs/source/CONTRIBUTE.md

@@ -1,15 +1,15 @@
 # Contributions
 
-MALA is an open-source software and is built upon the collaborative efforts of 
-many contributors. The MALA team warmly welcomes additional contributions and 
+MALA is an open-source software and is built upon the collaborative efforts of
+many contributors. The MALA team warmly welcomes additional contributions and
 kindly requests potential contributors to follow the suggested guidelines below
 to ensure the code's overall quality and maintainability.
 
 ## MALA contributors
 
-Many people have made valuable contributions to MALA, and we are immensely 
+Many people have made valuable contributions to MALA, and we are immensely
 grateful for their support.
-If you decide to contribute to MALA, please add your name to the following 
+If you decide to contribute to MALA, please add your name to the following
 alphabetically ordered list of contributors and include a note of the
 nature of your contribution:
 
@@ -59,16 +59,16 @@ used in this changelog.
 
 ### Creating a release
 
-In order to correctly update the MALA version, we use 
-[bumpversion](https://github.com/peritus/bumpversion). The actual release 
+In order to correctly update the MALA version, we use
+[bumpversion](https://github.com/peritus/bumpversion). The actual release
 process is very straightforward:
 
 1. Create a PR from `develop` to `master`.
 2. Merge the PR.
 3. Update the `date-released: ...` entry in `CITATION.cff` (on `master`).
 4. Create a tagged (and signed) commit on `master` with `bumpversion minor --allow-dirty` (check changes with `git show` or `git diff HEAD^`). Use either `major`, `minor` or `fix`, depending on what this release updates.
 5. Check out `develop` and do a `git merge master --ff`
-6. Push `master` and `develop` including tags (`--tags`). 
+6. Push `master` and `develop` including tags (`--tags`).
 7. Create a new release out of the tag on GitHub (https://github.com/mala-project/mala/releases/new) and add release notes/change log.
 8. Check if release got published to PyPI.
 
@@ -110,18 +110,25 @@ the core development team.
 ### Adding dependencies
 
 If you add additional dependencies, make sure to add them to `requirements.txt`
-if they are required or to `setup.py` under the appropriate `extras` tag if 
-they are not. 
-Further, in order for them to be available during the CI tests, make sure to 
+if they are required or to `setup.py` under the appropriate `extras` tag if
+they are not.
+Further, in order for them to be available during the CI tests, make sure to
 add _required_ dependencies to the appropriate environment files in folder `install/` and _extra_ requirements directly in the `Dockerfile` for the `conda` environment build.
 
 ## Pull Requests
 We actively welcome pull requests.
 1. Fork the repo and create your branch from `develop`
 2. During development, make sure that you follow the guidelines for [developing code](#developing-code)
-3. Rebase your branch onto `develop` before submitting a merge request
+3. Rebase your branch onto `develop` before submitting a pull request
 4. Ensure the test suite passes before submitting a pull request
 
+```{note}
+The test suite workflows are not triggered for draft pull requests in order to avoid expensive multiple runs.
+As soon as a pull request is marked as *ready to review*, the test suite is run through.
+If the pipeline fails, one should return to a draft pull request, fix the problems, mark it as ready again
+and repeat the steps if necessary.
+```
+
 ## Issues
 
 * Use issues to document potential enhancements, bugs and such