docs: extend contribution guide

ARCHITECTURE.md

@@ -0,0 +1,73 @@
+# Architecture
+
+This codebase is set up as a [Cargo workspace](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html). The `rover` binary is built from the root `bin` target, which is a thin wrapper around the `rover-client` library crate.
+
+## CLI Design
+
+Great thought and attention has been paid to Rover's design, and any new command surface must be considered holistically.
+
+### Command layout
+
+Rover commands are laid out as `rover [NOUN] [VERB]` to create clear separation of concerns for multiple areas of graph management.
+
+### Designing new commands
+
+Generally, we are hesitant to add a new `NOUN` to Rover's surface area, unless there is a clear and real need. 
+
+An example of a clear need is the `graph` vs. `subgraph` vs. `supergraph` command structure. Each of these nouns has similar associated verbs. 
+
+Let's look at the `fetch` commands as an example. `rover graph fetch` and `rover subgraph fetch` each take a positional required `<GRAPH_REF>` argument, and `subgraph fetch` also has a required `--subgraph` flag. It really looks like there doesn't need to be differentiation between these commands. We could have made this behavior implicit by making `--subgraph` optional, and only returning a subgraph schema if the `--subgraph` argument was provided. 
+
+The problem with this approach is that having two different return types from the same command leads to unexpected results and makes it difficult to understand the mental model needed to work with the graph registry. Additionally, it would have made it difficult to design commands that _only_ exist for `subgraphs`, and vice versa (such as `rover subgraph check`).
+
+In general, it is best to keep related commands together, and to avoid cognitive complexity wherever possible. New commands should either be associated with an existing top-level noun, or a new noun should be proposed.
+
+### Error Handling
+
+
+
+### Project Structure
+
+- `Cargo.toml`: crate metadata, including definitions for both internal and external dependencies
+
+- `Cargo.lock`: an autogenerated lockfile for Rover's dependencies
+
+- `src`: the `rover` CLI
+    - `src/bin/rover.rs`: the entry point for the CLI executable
+    - `src/command`: logic for the CLI commands
+      - `src/command/output.rs`: Enum containing all possible `stdout` options for Rover commands
+      - `src/command/{command_name}/mod.rs`: Contains the definition of Rov
+    - `src/utils`: shared utility functions
+    - `src/error`: application-level error handling including suggestions and error codes
+    - `src/cli.rs`: Module containing definition for all top-level commands
+    - `src/lib.rs`: all the logic used by the CLI
+
+- `tests`: Integration tests
+
+- `crates`
+    - `crates/houston`: logic related to configuring rover
+    - `crates/robot-panic`: Fork of `human-panic` to create panic handlers that allows users to submit crash reports as GitHub issues
+    - `crates/rover-client`: logic for querying apollo services
+    - `crates/sputnik`: logic for capturing anonymous usage data
+    - `crates/timber`: output formatting and logging logic
+    - `crates/xtask`: logic for building and testing Rover
+
+- `.cargo`: Sets up `cargo xtask` commands in the workspace
+
+- `docs`
+    - `source/*.md`: Individual documentation pages
+    - `source/assets`: Images and other resources
+    - `static/_redirects`: [Netlify redirects](https://docs.netlify.com/routing/redirects/)
+
+- `netlify.toml`: Configuration for Rover's [docs](https://apollographql.com/docs/rover)
+
+- `installers`
+    - `binstall`: Rover's cross-platform installer that downloads and installs prebuilt binaries
+    - `npm`: Rover's npm installer that downloads and installs prebuilt binaries
+
+- `.github`
+    - `ISSUE_TEMPLATE`: Issues templates for our GitHub repository
+    - `workflows/lint.yml`: GitHub Action that checks for idiomatic code style, proper formatting, and broken markdown links
+    - `workflows/release.yml`: GitHub Action that builds cross-platform binaries and creates a GitHub release when a version is tagged
+    - `workflows/test.yml`: Runs integration and unit tests on each commit that is pushed to GitHub
+

CODE_OF_CONDUCT.md

@@ -0,0 +1,43 @@
+## Code of Conduct
+
+The project has a [Code of Conduct] that _all_ contributors are expected to
+follow. This code describes the _minimum_ behavior expectations for all
+contributors.
+
+As a contributor, how you choose to act and interact towards your fellow
+contributors, as well as to the community, will reflect back not only on
+yourself but on the project as a whole. The Code of Conduct is designed and
+intended, above all else, to help establish a culture within the project that
+allows anyone and everyone who wants to contribute to feel safe doing so.
+
+Should any individual act in any way that is considered in violation of the
+[Code of Conduct], corrective actions will be taken. It is possible, however,
+for any individual to _act_ in such a manner that is not in violation of the
+strict letter of the Code of Conduct guidelines while still going completely
+against the spirit of what that Code is intended to accomplish.
+
+Open, diverse, and inclusive communities live and die on the basis of trust.
+Contributors can disagree with one another so long as they trust that those
+disagreements are in good faith and everyone is working towards a common goal.
+
+## Bad Actors
+
+All contributors to tacitly agree to abide by both the letter and spirit of the
+[Code of Conduct]. Failure, or unwillingness, to do so will result in
+contributions being respectfully declined.
+
+A _bad actor_ is someone who repeatedly violates the _spirit_ of the Code of
+Conduct through consistent failure to self-regulate the way in which they
+interact with other contributors in the project. In doing so, bad actors
+alienate other contributors, discourage collaboration, and generally reflect
+poorly on the project as a whole.
+
+Being a bad actor may be intentional or unintentional. Typically, unintentional
+bad behavior can be easily corrected by being quick to apologize and correct
+course _even if you are not entirely convinced you need to_. Giving other
+contributors the benefit of the doubt and having a sincere willingness to admit
+that you _might_ be wrong is critical for any successful open collaboration.
+
+Don't be a bad actor.
+
+[code of conduct]: https://github.com/apollographql/.github/blob/main/CODE_OF_CONDUCT.md