A note about the project board to help with transparency

COLLABORATING.md

@@ -6,7 +6,9 @@
    - **use preferably short-lived PRs when…**
      - …you potentially want feedback on changes
      - …changes would break _known_ downstream users, to allow those who are affected to influence the outcome towards greater value.
-   - **use issues for analysis and discussion of features and to track PRs**
+   - **use issues for analysis and discussion of features and to track PRs…**
+     - …if collaboration on a feature and prior feedback is desired
+   - **feel free to use the [project-board] to organize your issues, PRs or cards**
 - **`main` must never be broken or show warnings**
    - An easy way to achieve this is to run `make tests check-size` before pushing or `make tests check-size && git push`.
    - If you're unsure about remembering to do this, we suggest using a pre-commit git hook.
@@ -18,7 +20,7 @@
     - feel free to make any kind of changes to it, including major ones.
     - please use `cargo smart-release` for publishing to crates.io as it will handle dependencies properly.
 - **for crates _you do not own_**
-    - for major or architectural changes please open a discussion, an issue or a PR to allow
+    - for major or architectural changes please open a [discussion], an issue or a PR to allow
       participation and don't merge until there is agreement.
     - for minor code changes, if they are minor, feel free to make any kind of change you need.
 
@@ -28,4 +30,6 @@ The workflow can be changed after public discussion - to get started, open a PR.
 Please see the [development guide] for more detailed information on how code and cargo manifests are structured.
 
 [development guide]: https://github.com/Byron/gitoxide/blob/main/DEVELOPMENT.md
+[project-board]: https://github.com/Byron/gitoxide/projects
+[discussions]: https://github.com/Byron/gitoxide/discussions