docs: fixes for the guide, add CONTRIBUTING.md: addressing Stan's review comments

Author: alehander92

CONTRIBUTING.md

@@ -0,0 +1,35 @@
+<!-- copied as both top-level codetracer repo CONTRIBUTING.md and a contributing page in the docs book  -->
+
+## Contributing
+
+We welcome contributors!
+
+If you want to fix something smaller, feel free to open an issue or a a PR.
+
+For bigger changes it's advised to first open an issue/discussion in the relevant Github repo or to discuss it our team in our [Discord chat server](https://discord.gg/aH5WTMnKHT).
+
+### Contributors guide
+
+Here are some recommendations, however if you want more info, our docs/contributor guide are hosted [on the CodeTracer site](https://contributors-guide.codetracer.com/) !
+
+The guide is written as a set of markdown documents and built using [mdbook](https://rust-lang.github.io/mdBook/) and [mdbook-alerts](https://crates.io/crates/mdbook-alerts) . 
+
+You can contribute to the documentation itself, by editing it in `docs/book` and making a pull request. You can iterate on it locally , by cloning the repo, activating it's nix devshell and running `just serve-docs [hostname port]`: it will serve it locally(by default on http://localhost:3000).
+
+### Style guide
+
+For Rust, we are using `cargo fmt` to autoformat our code, and `cargo clippy` with some custom allow/deny rules inside the code.
+We have a `cargo clippy` check in our CI, but one can also run it locally.
+
+For Nim, we still haven't written down a guide or list of rules and principles that we agree on, so this is something that we hope to do.
+We might also link to an existing document. 
+
+### Commits/Pull Requests
+
+We are using [the "Conventional Commits" strategy](https://www.conventionalcommits.org/). 
+
+We use or are ok with using more "types", not only those included by default in their official page: e.g. `cleanup:`, `tooling:`, `examples:` etc.
+
+We use `git rebase`, not merge and currently use the github pull requests as the main way to add code. Any pull request would need at least one review
+from someone from the CodeTracer team.
+

docs/book/book.toml

@@ -1,5 +1,5 @@
 [book]
-authors = ["Stanislav Vasilev"]
+authors = ["CodeTracer team"]
 language = "en"
 multilingual = false
 src = "src"

docs/book/src/CONTRIBUTING.md

@@ -0,0 +1,35 @@
+<!-- copied as both top-level codetracer repo CONTRIBUTING.md and a contributing page in the docs book  -->
+
+## Contributing
+
+We welcome contributors!
+
+If you want to fix something smaller, feel free to open an issue or a a PR.
+
+For bigger changes it's advised to first open an issue/discussion in the relevant Github repo or to discuss it our team in our [Discord chat server](https://discord.gg/aH5WTMnKHT).
+
+### Contributors guide
+
+Here are some recommendations, however if you want more info, our docs/contributor guide are hosted [on the CodeTracer site](https://contributors-guide.codetracer.com/) !
+
+The guide is written as a set of markdown documents and built using [mdbook](https://rust-lang.github.io/mdBook/) and [mdbook-alerts](https://crates.io/crates/mdbook-alerts) . 
+
+You can contribute to the documentation itself, by editing it in `docs/book` and making a pull request. You can iterate on it locally , by cloning the repo, activating it's nix devshell and running `just serve-docs [hostname port]`: it will serve it locally(by default on http://localhost:3000).
+
+### Style guide
+
+For Rust, we are using `cargo fmt` to autoformat our code, and `cargo clippy` with some custom allow/deny rules inside the code.
+We have a `cargo clippy` check in our CI, but one can also run it locally.
+
+For Nim, we still haven't written down a guide or list of rules and principles that we agree on, so this is something that we hope to do.
+We might also link to an existing document. 
+
+### Commits/Pull Requests
+
+We are using [the "Conventional Commits" strategy](https://www.conventionalcommits.org/). 
+
+We use or are ok with using more "types", not only those included by default in their official page: e.g. `cleanup:`, `tooling:`, `examples:` etc.
+
+We use `git rebase`, not merge and currently use the github pull requests as the main way to add code. Any pull request would need at least one review
+from someone from the CodeTracer team.
+

docs/book/src/SUMMARY.md

@@ -1,7 +1,7 @@
 ## Summary
 
 - [Introduction](./introduction.md)
-- [Contributions](./contributions.md)
+- [Contributing](./CONTRIBUTING.md)
 
 ## Usage guide
 

docs/book/src/backends/db-backend/py.md

@@ -1,4 +1,4 @@
-## python
+## Python language
 
 We currently have started adding support for recording python programs for the DB backend, but the prototype isn't finished yet. 
 

docs/book/src/backends/db-backend/ruby.md

@@ -5,5 +5,5 @@ We support many cases, you can use it like `ct record <path to rb file> [<args>]
 
 The recorder for Ruby is currently hosted in the [codetracer-ruby-recorder](https://github.com/metacraft-labs/codetracer-ruby-recorder) repo.
 
-You can read its README for more details. We are welcoming contributors!
+You can read its README for more details. We welcome contributors!
 

docs/book/src/backends/db_backend.md

@@ -1,5 +1,7 @@
 ## DB backend
 
+### Languages
+
 The DB backend is currently used for interpreted languages, like scripting and blockchain/zero knowledge languages:
 
 1. [Noir](./db-backend/noir.md)
@@ -8,14 +10,18 @@ The DB backend is currently used for interpreted languages, like scripting and b
 1. [Lua(not done: just a plan)](./db-backend/lua.md)
 1. [small(a toy interpreter for dogfooding)](./db-backend/small.md)
 
-If you're interested in db-backend support for those languages or for now ones, you can discuss with us on our Github issue tracker,
-in the discussions or in our [chat server](https://discord.gg/aH5WTMnKHT). We welcome contributors!
+If you're interested in db-backend support for those languages or for now ones, you can discuss with us on our [GitHub issue tracker](https://github.com/metacraft-labs/codetracer/issues),
+in the [GitHub repo discussions forum](https://github.com/metacraft-labs/codetracer/discussions) or in our [discord chat server](https://discord.gg/aH5WTMnKHT). We welcome contributors!
+
+### Additional directions
 
-However it might be used for emulators(and this way for native languages) in the future.
+However we're exploring using this method for emulators(and conversely, for emulating native languages) in the future.
 
 Also, languages can have both native(AOT) and interpreted implementations: 
 so we can more easily support e.g. interpreters/VM-s of certain languages with this backend currently.
 
+### Implementation
+
 As the name suggests, this backend is implemented as a database. Due to its properties, this backend provides
 a more complete feature set - one of the reasons it was ready first.
 

docs/book/src/backends/rr-backend/go.md

@@ -1,4 +1,4 @@
 # Go
 
 We have developed а basic integration that supports small parts of the Golang language in the Core backend. 
-Development on a more complete revision is scheduled to start soon!
+Development of a more complete revision is scheduled to start soon!

docs/book/src/backends/rr_backend.md

@@ -17,7 +17,7 @@ preloading information, such as the information, needed for omniscience and call
 currently implemented using python code using the gdb API. 
 (If required, this can be changed to use the lldb API or something more custom, like a dwarf lib-based solution. We are currently using the rust `gimli` DWARF lib for a tool, that helps with recording/metadata in the RR backend).
 
-These are the main differences, when compared to the DB Backend: based on the way RR works:
+These are the main differences, when compared to the DB Backend, based on the way RR works:
 
 1. Only non-deterministic events are recorded.
 1. The program's different states are navigated through re-execution.

docs/book/src/building_and_packaging/build_systems.md

@@ -3,14 +3,16 @@
 Codetracer uses nix, just, tup and direnv as parts of its build system.
 
 ## Breakdown of the different components
+
 ### Nix
-The Nix package manager/build system deals with managing all dependencies, required by CodeTracer, as well as packaging
+
+The [Nix](https://nixos.org/) package manager/build system deals with managing all dependencies, required by CodeTracer, as well as packaging
 it for NixOS. It can package for other operating systems through an AppImage generator utility, however currently we are building our
 appimages with custom shell scripts in `appimage-scripts`.
 
 ### Just
 
-The `just` tool is used to trigger build commands and various other actions. It's semi-analogous to a Makefile. The following commands are
+The [just](https://just.systems/) task runner is used to trigger build commands and various other actions. It's semi-analogous to a Makefile. The following commands are
 the most widely-used:
 
 1. `just build` - Builds the project with Tup and starts the automatic build process, which is used for active development
@@ -25,10 +27,11 @@ the most widely-used:
 1. `just reset-config` - Resets the user's configuration if it's incompatible with the latest version of CodeTracer. Further [documentation](https://dev-docs.codetracer.com/Introduction/Configuration)
 
 ### Tup
-The Tup build system is used for local builds of CodeTracer and deals with calling the actual low-level build instructions.
+
+The [Tup](https://gittup.org/tup/) build system is used for local builds of CodeTracer and deals with calling the actual low-level build instructions.
 
 ### Direnv
-The `direnv` utility sets up your local environment for using CodeTracer.
+The [direnv](https://direnv.net/) utility sets up your local environment for using CodeTracer.
 
 ## Packaging