docs: contributing guide update (0xMiden#1109)

Author: igamigo

.github/workflows/web-docs-check.yml

@@ -27,21 +27,26 @@ jobs:
             core.setOutput('skip', labels.includes('bypass-sdk-version-bump'));
 
       - name: Install Rust toolchain
+        if: github.event_name == 'push' || steps.bypass.outputs.skip != 'true'
         run: rustup update --no-self-update
 
       - name: Setup Node.js
+        if: github.event_name == 'push' || steps.bypass.outputs.skip != 'true'
         uses: actions/setup-node@v3
         with:
           node-version: '20'
 
       - name: Add WASM target
+        if: github.event_name == 'push' || steps.bypass.outputs.skip != 'true'
         run: rustup target add wasm32-unknown-unknown
 
       - name: Install Dependencies
+        if: github.event_name == 'push' || steps.bypass.outputs.skip != 'true'
         working-directory: crates/web-client
         run: yarn install
 
       - name: Build Project
+        if: github.event_name == 'push' || steps.bypass.outputs.skip != 'true'
         working-directory: crates/web-client
         run: yarn build
 

CONTRIBUTING.md

@@ -71,23 +71,36 @@ For example, a new change to the `miden-node-store` crate might have the followi
     // ================================================================================
     ```
 
-- [Rustfmt](https://github.com/rust-lang/rustfmt), [Clippy](https://github.com/rust-lang/rust-clippy), [Rustdoc](https://doc.rust-lang.org/rustdoc/index.html) and [Typos](https://github.com/crate-ci/typos) linting is included in CI pipeline. Anyways it's preferable to run linting locally before push. To simplify running these commands in a reproducible manner we use `make` commands, you can run:
+- [Rustfmt](https://github.com/rust-lang/rustfmt), [Clippy](https://github.com/rust-lang/rust-clippy), [Rustdoc](https://doc.rust-lang.org/rustdoc/index.html), [Typos](https://github.com/crate-ci/typos) and [Taplo](https://github.com/tamasfe/taplo) linting is included in the CI pipeline. 
 
-    ```
-    make lint
-    ```
+You can run all checks locally before opening a PR. To simplify running all checks in a reproducible manner we use `make` commands:
 
-You can find more information about other `make` commands in the [Makefile](Makefile)
+```
+make lint
+```
+
+You can find more information about other `make` commands in the [Makefile](Makefile).
 
 ### Versioning
 We use [semver](https://semver.org/) naming convention.
 
 ## Pre-PR checklist
-1. Repo forked and branch created from `next` according to the naming convention.
-2. Commit messages and code style follow conventions.
-3. Tests added for new functionality.
-4. Documentation/comments updated for all changes according to our documentation convention.
-5. Rustfmt, Clippy and Rustdoc linting passed.
+
+> [!TIP]
+> You can check if you have the tools that we use by running `make check-tools`.
+
+- Repo forked and branch created from `next` according to the naming convention.
+- Commit messages and code style follow conventions.
+- Tests added for new functionality, with all previously existing tests passing.
+  - Read more on how to run integration tests [here](./tests/README.md).
+- Documentation/comments updated for all changes according to our documentation convention.
+- Lints: Rustfmt, Clippy, Rustdoc, Typos and TOML-formatting linting passing.
+  - As mentioned above, `make lint` can be used for checking there.
+- If the PR includes changes to the web client, the documentation needs to be up to date. You can automatically generate them by running `make typedoc`.
+
+### Changelog
+
+If a PR introduces anything a downstream user might notice - a new feature, a behaviour change, a bug-fix, a deprecation, or a breaking API change - add a bullet to [CHANGELOG.md](./CHANGELOG.md) under the last existing heading (corresponds to the unreleased version when working on the `next` branch). The convention is to write a past-tense summary (e.g. "* [BREAKING] Renamed foo() to bar() in `Client` {#PR number link}"). Internal refactors or smaller tweaks that don’t affect public behaviour can be left out.
 
 ## Write bug reports with detail, background, and sample code
 

tests/README.md

@@ -18,13 +18,20 @@ And on a second terminal do:
 make integration-test-full
 ```
 
+For running web client integration tests, you can do:
+
+```bash
+# This will run the integration test suite for the web SDK
+make integration-test-web-client
+```
+
 Note that in order to run this as part of a CI/CD workflow (at least on github), you'll need to use `make start-node-background` instead so the process keeps running on background.
 
 To stop the background node, you can use the `make stop-node` command.
 
-## Integration Test Flow
+## Integration tests flow
 
-The integration test goes through a series of supported flows such as minting and transferring assets which runs against a running node.
+The integration testing suite goes through a series of supported flows such as minting and transferring assets which runs against a running node.
 
 ### Setup