Release v0.8.1

docs/dv/01_introducing-charon.md

@@ -22,7 +22,7 @@ The below graphic visually outlines the internal functionalies of Charon.
 The `charon` client is in an early alpha state, and is not ready for mainnet, see [here](https://github.com/ObolNetwork/charon#supported-consensus-layer-clients) for the latest on charon's readiness.
 
 ```
-docker run ghcr.io/obolnetwork/charon:v0.8.0 --help
+docker run ghcr.io/obolnetwork/charon:v0.8.1 --help
 ```
 
 For more information on running charon, take a look at our [quickstart guide](../int/quickstart/index.md). 

docs/dv/09_charon_cli_reference.md

@@ -10,7 +10,7 @@ The `charon` client is under heavy development, interfaces are subject to change
 
 :::
 
-The following is a reference for charon version [`v0.8.0`](https://github.com/ObolNetwork/charon/releases/tag/v0.8.0). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+The following is a reference for charon version [`v0.8.1`](https://github.com/ObolNetwork/charon/releases/tag/v0.8.1). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
 
 ### Available Commands
 

docs/int/quickstart/quickstart-alone.md

@@ -38,7 +38,7 @@ Charon is in an early alpha state and is not ready to be run on mainnet
 
    ```sh
    # Create a testnet distributed validator cluster
-   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.0 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead"
+   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead"
    ```
 
 1. Start the cluster

docs/int/quickstart/quickstart-group.md

@@ -33,40 +33,31 @@ To create a distributed validator cluster with a group of other node operators r
    # Change directory
    cd charon-distributed-validator-node/
    ```
-
-1. Prepare the environment variables
+1. Next create a private key for charon to use for its ENR
 
    ```sh
-   # Copy the sample environment variables
-   cp .env.sample .env
+   # Create an ENR private key
+   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create enr
    ```
 
-   For simplicities sake, this repo is configured to work with a remote Beacon node such as one from [Infura](https://infura.io/).
-
-   Create an Eth2 project and copy the `https` URL:
-
-   ![Example Infura API Endpoint](/img/example-infura-details.png)
-
-   Replace the placeholder value of `CHARON_BEACON_NODE_ENDPOINT` in your newly created `.env` file with this URL.
-
-1. Now create a private key for charon to use for its ENR
+   This command will print your charon client's ENR to the console. It should look something like:
 
-   ```sh
-   # Create an ENR private key
-   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.0 create enr
+   ```
+   Created ENR private key: .charon/charon-enr-private-key
+   enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E
    ```
 
    :::caution
    The ability to replace a deleted or compromised private key is limited at this point. Please make a secure backup of this private key if this distributed validator is important to you.  
    :::
-   This command will print your charon client's ENR to the command line. It should look something like:
-
-   ```
-   enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E
-   ```
 
    This record identifies your charon client no matter where it communicates from across the internet. It is required for the following step of creating a set of distributed validator private key shares amongst the cluster operators.
 
+   Please make sure to make a backup of the private key at .charon/charon-enr-private-key. Be careful not to commit it to git! If you lose this file you won't be able to take part in the DKG ceremony.
+
+   If you are taking part in an organised Obol testnet, submit the created ENR public address (the console output starting with and including `enr:-`, not the contents of the private key file) to the appropriate typeform.
+
+
 ## Performing a Distributed Validator Key Generation Ceremony
 
 To create the private keys for a distributed validator securely, a Distributed Key Generation (DKG) process must take place.
@@ -78,7 +69,7 @@ To create the private keys for a distributed validator securely, a Distributed K
    # First set the ENRs of all the operators participating in DKG ceremony in .env file as CHARON_OPERATOR_ENRS
 
    # Create .charon/cluster-definition.json to participate in DKG ceremony
-   docker run --rm -v "$(pwd):/opt/charon" --env-file .env ghcr.io/obolnetwork/charon:v0.8.0 create dkg
+   docker run --rm -v "$(pwd):/opt/charon" --env-file .env ghcr.io/obolnetwork/charon:v0.8.1 create dkg
    ```
 
 1. The operator that ran this command should distribute the resulting `cluster-definition.json` file to each operator.
@@ -90,13 +81,28 @@ To create the private keys for a distributed validator securely, a Distributed K
    cp cluster-definition.json .charon/
 
    # Participate in DKG ceremony, this will create .charon/cluster-lock.json, .charon/deposit-data.json and .charon/validator_keys/
-   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.0 dkg
+   docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 dkg
    ```
 
 ## Verifying cluster health
 
 Once the key generation ceremony has been completed, the charon nodes have the data they need to come together to form a cluster.
 
+1. First you must prepare the required environment variables, in particular you need to set the `CHARON_BEACON_NODE_ENDPOINT` variable to point at either a local or remote beacon node API endpoint. 
+
+   ```sh
+   # Copy the sample environment variables
+   cp .env.sample .env
+   ```
+
+   For simplicities sake, this repo is configured to work with a remote Beacon node such as one from [Infura](https://infura.io/).
+
+   Create an Eth2 project and copy the `https` URL for the network you want to use (this repo expects `prater`):
+
+   ![Example Infura API Endpoint](/img/example-infura-details.png)
+
+   Replace the placeholder value of `CHARON_BEACON_NODE_ENDPOINT` in your newly created `.env` file with this URL.
+
 1. Start your distributed validator node with docker-compose
    ```sh
    # Run a charon client, a vc client, and prom+grafana clients as containers
@@ -107,6 +113,7 @@ Once the key generation ceremony has been completed, the charon nodes have the d
    # Open Grafana
    open http://localhost:3000/d/singlenode
    ```
+   If Grafana doesn't load any data the first time you open it, check [this method](https://github.com/ObolNetwork/charon-distributed-validator-node#grafana-doesnt-load-any-data) for fixing the issue. 
 
 ## Activating the distributed validator
 

versioned_docs/version-v0.8.1/cg/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Contribution guidelines",
+  "position": 10,
+  "collapsed": true
+}

versioned_docs/version-v0.8.1/cg/bug-report.md

@@ -0,0 +1,57 @@
+# Filing a bug report
+
+Bug reports are critical to the rapid development of Obol. In order to make the process quick and efficient for all parties, it is best to follow some common reporting etiquette when filing to avoid double issues or miscommunications.
+
+## Checking if your issue exists
+
+Duplicate tickets are a hinderance to the development process and, as such, it is crucial to first check through Charon's existing issues to see if what you are experiencing has already been indexed.
+
+To do so, head over to the [issue page](https://github.com/ObolNetwork/charon/issues) and enter some related keywords into the search bar. This may include a sample from the output or specific components it affects.
+
+If searches have shown the issue in question has not been reported yet, feel free to open up a new issue ticket.
+
+## Writing quality bug reports
+
+A good bug report is structured to help the developers and contributors visualise the issue in the clearest way possible. It's important to be concise and use comprehensive language, while also providing all relevant information on-hand. Use short and accurate sentences without any unnecessary additions, and include all existing specifications with a list of steps to reproduce the expected problem. Issues that cannot be reproduced **cannot be solved**.
+
+If you are experiencing multiple issues, it is best to open each as a separate ticket. This allows them to be closed individually as they are resolved.
+
+An original bug report will very likely be preserved and used as a record and sounding board for users that have similar experiences in the future. Because of this, it is a great service to the community to ensure that reports meet these standards and follow the template closely.
+
+
+## The bug report template
+
+Below is the standard bug report template used by all of Obol's official repositories.
+
+```sh
+<!--- Provide a general summary of the issue in the Title above -->
+
+## Expected Behaviour
+<!--- What should be happening? -->
+
+## Current Behaviour
+<!--- What happens instead? -->
+
+## Steps to Reproduce
+<!--- Provide a concise set of steps to reproduce this bug.  -->
+1.
+2.
+3.
+4.
+5.
+
+## Detailed Description
+<!--- Provide some context for the issue you are experiencing. -->
+
+## Specifications
+<!--- Provide some information regarding your local system. --->
+Operating system:
+Version(s) used:
+
+## Possible Solution
+<!--- (Optional) Suggest a fix, reason or implementation for the bug. -->
+
+## Further Information
+<!--- Anything else to add?
+```
+