add basic contributing file

CONTRIBUTING.md

@@ -0,0 +1,148 @@
+# Contributing to Fuel Core
+
+Thanks for your interest in contributing to Fuel Core! This document outlines some the conventions on building, running, and testing Fuel Core.
+
+Fuel Core has many dependent repositories. If you need any help or mentoring getting started, understanding the codebase, or anything else, please ask on our [Discord](https://discord.gg/xfpK4Pe).
+
+## Code Standards
+
+We use an RFC process to maintain our code standards. They currently live in the RFC repo: https://github.com/FuelLabs/rfcs/tree/master/text/code-standards
+
+## Building and setting up a development workspace
+
+Fuel Core is mostly written in Rust, but includes components written in C++ (RocksDB). We are currently using the latest Rust stable toolchain.
+
+### Prerequisites
+
+To build Fuel Core you'll need to at least have the following installed:
+
+ * `git` - version control
+ * [`rustup`](https://rustup.rs/) - Rust installer and toolchain manager
+ * OpenSSL - Standard system libraries for networking
+ * Postgres - Used for indexing on-chain data
+ * [`llvm` and `clang`](http://releases.llvm.org/download.html) - Used to generate bindings for different platforms (WASM) and build native libraries (required for rocksdb).
+
+See the [README.md](README.md#system-requirements) for platform specific setup steps.
+
+### Getting the repository
+
+```
+git clone https://github.com/FuelLabs/fuel-core
+cd fuel-core
+## Future instructions assume you are in this repository
+```
+
+### Configuring your Rust toolchain
+
+`rustup` is the official toolchain manager for Rust. 
+
+We use some additional components such as `rustfmt` and `clippy`, to install those:
+```
+rustup component add rustfmt
+rustup component add clippy
+```
+
+### Building and testing
+
+Instead of a makefile, Fuel Core uses the `xtask` pattern to manage custom build processes.
+
+You can build Fuel Core:
+```
+cargo xtask build
+```
+
+This command will run `cargo build` and also dump the latest schema into `/assets/` folder.
+
+Linting is done using rustfmt and clippy, which are each separate commands:
+
+```
+cargo fmt --all --check
+```
+
+```
+cargo clippy --all-targets
+```
+
+The test suite follows the Rust cargo standards. The GraphQL service will be instantiated by Tower and will emulate a server/client structure.
+
+Testing is simply done using Cargo:
+```
+cargo test --all-targets
+```
+
+##### Build Options
+
+For optimal performance, we recommend using native builds. The generated binary will be optimized for your CPU and may contain specific instructions supported only in your hardware.
+
+To build, run:
+`$ RUSTFLAGS="-C target-cpu=native" cargo build --release --bin fuel-core`
+
+The generated binary will be located in `./target/release/fuel-core`
+
+### Build issues
+
+Due to dependencies on external components such as RocksDb, build times can be large without caching.
+Using an in-memory (hashmap) based database is supported for testing purposes, so build times can be improved by disabling 
+default features.
+
+```
+cargo build -p fuel-core --no-default-features
+```
+
+## Contribution flow
+
+This is a rough outline of what a contributor's workflow looks like:
+
+- Make sure what you want to contribute is already traced as an issue.
+    * We may discuss the problem and solution in the issue.
+- Create a Git branch from where you want to base your work. This is usually master.
+- Write code, add test cases, and commit your work.
+- Run tests and make sure all tests pass.
+- If the PR contains any breaking changes, add the breaking label to your PR.
+- Push your changes to a branch in your fork of the repository and submit a pull request.
+    * Make sure mention the issue, which is created at step 1, in the commit message.
+- Your PR will be reviewed and some changes may be requested.
+    * Once you've made changes, your PR must be re-reviewed and approved.
+    * If the PR becomes out of date, you can use GitHub's 'update branch' button.
+    * If there are conflicts, you can merge and resolve them locally. Then push to your PR branch. 
+      Any changes to the branch will require a re-review.
+- Our CI system (Github Actions) automatically tests all authorized pull requests.
+- Use Github to merge the PR once approved.
+
+Thanks for your contributions!
+
+### Finding something to work on
+
+For beginners, we have prepared many suitable tasks for you. Checkout our [Help Wanted issues](https://github.com/FuelLabs/fuel-core/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) for a list.
+
+If you are planning something big, for example, relates to multiple components or changes current behaviors, make sure to open an issue to discuss with us before going on.
+
+The Client team actively develops and maintains several dependencies used in Fuel Core, which you may be also interested in:
+
+- [fuel-types](https://github.com/FuelLabs/fuel-types)
+- [fuel-merkle](https://github.com/FuelLabs/fuel-merkle)
+- [fuel-tx](https://github.com/FuelLabs/fuel-tx)
+- [fuel-asm](https://github.com/FuelLabs/fuel-asm)
+- [fuel-vm](https://github.com/FuelLabs/fuel-vm)
+
+### Linking issues
+
+Pull Requests should be linked to at least one issue in the same repo.
+
+If the pull request resolves the relevant issues, and you want GitHub to close these issues automatically after it merged into the default branch, you can use the syntax (`KEYWORD #ISSUE-NUMBER`) like this:
+
+```
+close #123
+```
+
+If the pull request links an issue but does not close it, you can use the keyword `ref` like this:
+
+```
+ref #456
+```
+
+Multiple issues should use full syntax for each issue and separate by a comma, like:
+
+```
+close #123, ref #456
+```

README.md

@@ -7,21 +7,9 @@
 
 Fuel client implementation.
 
-## Testing
+## Contributing
 
-The test suite follows the Rust cargo standards. The GraphQL service will be instantiated by Tower and will emulate a server/client structure.
-
-To run the suite:
-`$ cargo test`
-
-## Developing
-
-When contributing we recommend using `xtask` for building the code.
-
-Build:
-`$ cargo xtask build`
-
-This command will run `cargo build` and also dump the latest schema into `/assets/` folder.
+If you are interested in contributing to Fuel, see our [CONTRIBUTING.md](CONTRIBUTING.md) guidelines for coding standards and review process.
 
 ## Building
 
@@ -48,14 +36,15 @@ export OPENSSL_LIB_DIR="/usr/lib/openssl-1.0";
 export OPENSSL_INCLUDE_DIR="/usr/include/openssl-1.0"
 ```
 
-##### Build Options
+## Building 
 
-For optimal performance, we recommend using native builds. The generated binary will be optimized for your CPU and may contain specific instructions supported only in your hardware.
+We recommend using `xtask` to build fuel-core:
 
-To build, run:
-`$ RUSTFLAGS="-C target-cpu=native" cargo build --release --bin fuel-core`
+```
+cargo xtask build
+```
 
-The generated binary will be located in `./target/release/fuel-core`
+This will run `cargo build` as well as any other custom build processes we have such as re-generating a GraphQL schema for the client.
 
 ## Running
 
@@ -95,8 +84,7 @@ Clear your local database using: `rm -rf ~/.fuel/db`
 
 #### Log level
 
-The service relies on the environment variable `RUST_LOG`. For more information, check the [env_logger](https://docs.rs/env_logger) crate.
-
+The service relies on the environment variable `RUST_LOG`. For more information, check the [EnvFilter examples](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/struct.EnvFilter.html#examples) crate.
 
 ## Docker & Kubernetes
 ```