diff --git a/docs/.gitbook/assets/Tellor.png b/docs/.gitbook/assets/Tellor.png
deleted file mode 100644
index 2c227053..00000000
Binary files a/docs/.gitbook/assets/Tellor.png and /dev/null differ
diff --git a/docs/.gitbook/assets/minerspecs.png b/docs/.gitbook/assets/minerspecs.png
deleted file mode 100644
index fd0bb9e9..00000000
Binary files a/docs/.gitbook/assets/minerspecs.png and /dev/null differ
diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md
new file mode 100755
index 00000000..d93eb6a7
--- /dev/null
+++ b/docs/CHANGELOG.md
@@ -0,0 +1,24 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
+and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
+
+NOTE: As semantic versioning states all 0.y.z releases can contain breaking changes in API (flags, grpc API, any backward compatibility)
+
+We use *breaking :warning:* to mark changes that are not backward compatible (relates only to v0.y.z releases.)
+
+## Unreleased
+- [#272](https://github.com/tellor-io/telliot/pull/272) Automated Docker images on every push to master and with every tagged release.
+
+## [v5.2.0](https://github.com/tellor-io/telliot/releases/tag/v5.2.0) - 2020.11.12
+- [#254](https://github.com/tellor-io/telliot/pull/254)
+ - Added support for expanding variables in the indexer api url.
+ - Added config to specify the `.env` file location. The default is now `configs/.env` so users should either specify a custom location in the `config.json` or move it inside the default config folder.
+
+## [v5.0.0](https://github.com/tellor-io/telliot/releases/tag/v5.0.0) - 2020.11.02
+
+### Added
+ - Profitability calculations which is set through the `ProfitThreshold`(in percents) settings in the config,
+ - Docs how to contribute.
diff --git a/docs/README.md b/docs/README.md
old mode 100644
new mode 100755
index 00d0e4bb..39960270
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,50 +1,63 @@
-# Introduction
- [](https://www.tellor.io/)
+
+
+ 
+
+
- [](https://twitter.com/WeAreTellor)
+
+
+ 
+
+
-> ### ⚠️ Note!
->
-> Telliot docs are synced from the project repository. To edit please visit:
-> [Telliot gitbook space](https://docs.tellor.io/telliot)
-> or
-> [Telliot github repo](https://github.com/tellor-io/telliot/tree/master/docs)
-## Telloit
+> ## ⚠️ Note!
+> Telliot docs are synced from the project repository.
+To edit please visit:
+[Telliot gitbook space](https://docs.tellor.io/telliot)
+or
+[Telliot github repo](https://github.com/tellor-io/telliot/tree/master/docs)
-This is the main cli of the project. One if its commands is to run in mining mode\(solve a POW challenge\) and submit values to the tellor oracle contract. It's built on Go and utilizes a split structure. The database piece is a LevelDB that keeps track of all variables \(challenges, difficulty, values to submit, etc.\) and the miner simply solves the PoW challenge. This enables parties to split the pieces for optimization.
-The Tellor system is a way to push data on-chain. What pieces of data are pushed are specificied in the `configs/indexes.json`. Note that the data corresponds to a specific API. The tellor mining system is set up to pull api data to generate these values to submit on-chain once a correct nonce is mined. These specific apis are just suggestions. The system is not guarunteed to work for everyone. It is up to the consnesus of the Tellor token holders to determine what a correct value is. As an example, request ID 4 is BTC/USD. If the api's all go down, it is the responsibility of the miner to still submit a valid BTC/USD price. If they do not, they risk being disputed and slashed. For these reasons, please contribute openly to the official Tellor miner \(or an open source variant\), as consensus here is key. If you're miner gets a different value than the majority of the of the other miners, you risk being punished.
-A list of all PSR's\(pre specified requests\) and the expected data can be found [here](https://github.com/tellor-io/telliot/tree/f6791d8fb61f7d49051624a70a96b7d6a3f77345/pkg/tracker/psrs.go).
+# Telloit
-
+This is the main cli of the project. One if its commands is to run in mining mode(solve a POW challenge) and submit values to the tellor oracle contract.
+It's built on Go and utilizes a split structure. The database piece is a LevelDB that keeps track of all variables (challenges, difficulty, values to submit, etc.) and the miner simply solves the PoW challenge. This enables parties to split the pieces for optimization.
-### Instructions for deployment
+The Tellor system is a way to push data on-chain. What pieces of data are pushed are specificied in the `configs/indexes.json`. Note that the data corresponds to a specific API. The tellor mining system is set up to pull api data to generate these values to submit on-chain once a correct nonce is mined. These specific apis are just suggestions. The system is not guarunteed to work for everyone. It is up to the consnesus of the Tellor token holders to determine what a correct value is. As an example, request ID 4 is BTC/USD. If the api's all go down, it is the responsibility of the miner to still submit a valid BTC/USD price. If they do not, they risk being disputed and slashed. For these reasons, please contribute openly to the official Tellor miner (or an open source variant), as consensus here is key. If you're miner gets a different value than the majority of the of the other miners, you risk being punished.
-* [Telliot Instructions](https://github.com/tellor-io/telliot/tree/f6791d8fb61f7d49051624a70a96b7d6a3f77345/docs/docs/setup-and-usage.md)
+A list of all PSR's(pre specified requests) and the expected data can be found [here](../pkg/tracker/psrs.go).
-### Contributing and building from source
+
+ 
+
-Contributions are very welcome!
- See our [04\_contributing.md](telliot-documentation/contributing.md) for more information.
-### Run with Docker
+## Instructions for deployment
+ - [Telliot Instructions](docs/setup-and-usage.md)
-Available tags: [https://hub.docker.com/u/tellor](https://hub.docker.com/u/tellor) docker run -v $\(pwd\)/.local:/configs tellor/telliot:master mine
+## Contributing and building from source
+Contributions are very welcome!
+See our [04_contributing.md](contributing.md) for more information.
-### Maintainers
+## Run with Docker
+Available tags: https://hub.docker.com/u/tellor
+docker run -v $(pwd)/.local:/configs tellor/telliot:master mine
+## Maintainers
This repository is maintained by the [Tellor team](https://github.com/orgs/tellor-io/people)
-#### DISCLAIMER
+### DISCLAIMER
+
+-------
Mine at your own risk.
-Mining requires you deposit 1000 Tellor Tributes. These are a security deposity. If you are a malicious actor \(aka submit a bad value\), the community can vote to slash your 1000 tokens.
+Mining requires you deposit 1000 Tellor Tributes. These are a security deposity. If you are a malicious actor (aka submit a bad value), the community can vote to slash your 1000 tokens.
-Mining also requires submitting on-chain transactions on Ethereum. These transactions cost gas \(ETH\) and can sometimes be signifiant if the cost of gas on EThereum is high \(i.e. the network is clogged\). Please reach out to the community to find the best tips for keeping gas costs under control or at least being aware of the costs.
+Mining also requires submitting on-chain transactions on Ethereum. These transactions cost gas (ETH) and can sometimes be signifiant if the cost of gas on EThereum is high (i.e. the network is clogged). Please reach out to the community to find the best tips for keeping gas costs under control or at least being aware of the costs.
If you are building a competing client, please contact us. The miner specifications are off-chain and the validity of the mining process hinges on the consensus of the Tellor community to determine what proper values are. Competing clients that change different pieces run the risk of being disputed by the commmunity.
@@ -52,3 +65,6 @@ There is no guaruntee of profit from mining.
There is no promise that Tellor Tributes currently hold or will ever hold any value.
+----------
+### Copyright
+Tellor Inc. 2019
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
index 64378ad7..e46fd8bb 100644
--- a/docs/SUMMARY.md
+++ b/docs/SUMMARY.md
@@ -1,14 +1,8 @@
-# Table of contents
-
-* [Introduction](README.md)
-
## Telliot Documentation
-
-* [Introduction](telliot-documentation/readme.md)
-* [Setup and usage](telliot-documentation/setup-and-usage.md)
-* [Configuation](telliot-documentation/configuation.md)
-* [Contributing](telliot-documentation/contributing.md)
-* [Coding style guide](telliot-documentation/coding-style-guide.md)
-* [Release process](telliot-documentation/release-process.md)
-* [Changelog](telliot-documentation/changelog.md)
-
+* [Introduction](README.md)
+* [Setup and usage](setup-and-usage.md)
+* [Configuation](configuation.md)
+* [Contributing](contributing.md)
+* [Coding style guide](coding-style-guide.md)
+* [Release process](release-process.md)
+* [Changelog](CHANGELOG.md)
diff --git a/docs/telliot-documentation/coding-style-guide.md b/docs/coding-style-guide.md
old mode 100644
new mode 100755
similarity index 64%
rename from docs/telliot-documentation/coding-style-guide.md
rename to docs/coding-style-guide.md
index 9fd82181..4794f90c
--- a/docs/telliot-documentation/coding-style-guide.md
+++ b/docs/coding-style-guide.md
@@ -2,11 +2,11 @@
description: Coding style guide for contributors.
---
-# Coding style guide
+# Coding Style Guide
-## Coding Style Guide
-
-This document details the official style guides for the various languages we use in the project. Feel free to familiarize yourself with and refer to this document during code reviews. If something in our codebase does not match the style, it means it was missed or it was written before this document. Help wanted to fix it! \(:
+This document details the official style guides for the various languages we use in the project.
+Feel free to familiarize yourself with and refer to this document during code reviews. If something in our codebase does not match the style, it means it
+was missed or it was written before this document. Help wanted to fix it! (:
Generally, we care about:
@@ -16,23 +16,30 @@ Generally, we care about:
* Testability. Even if it means some changes to the production code, like `timeNow func() time.Time` mock.
* Consistency: If some pattern repeats, it means fewer surprises.
-Some style is enforced by our linters and is covered in separate smaller sections. Please look there if you want to embrace some of the rules in your own project! Some of those are currently impossible to detect with linters. Ideally, everything would be automated. \(:
+Some style is enforced by our linters and is covered in separate smaller sections. Please look there if you want to
+embrace some of the rules in your own project! Some of those are currently impossible to detect with linters. Ideally, everything would be automated. (:
-## Go
+# Go
-For code written in [Go](https://golang.org/) we use the standard Go style guides \([Effective Go](https://golang.org/doc/effective_go.html), [CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments)\) with a few additional rules that make certain areas stricter than the standard guides. This ensures even better consistency in modern distributed systems, where reliability, performance, and maintainability are extremely important.
+For code written in [Go](https://golang.org/) we use the standard Go style guides ([Effective Go](https://golang.org/doc/effective_go.html),
+[CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments)) with a few additional rules that make certain areas stricter
+than the standard guides. This ensures even better consistency in modern distributed systems, where reliability, performance,
+and maintainability are extremely important.
-### Development / Code Review
+## Development / Code Review
In this section, we will go through rules that on top of the standard guides that we apply during development and code reviews.
-NOTE: If you know that any of those rules can be enabled by some linter, automatically, let us know! \(:
+NOTE: If you know that any of those rules can be enabled by some linter, automatically, let us know! (:
-#### Reliability
+### Reliability
-The coding style is not purely about what is ugly and what is not. It's mainly to make sure programs are reliable for running on production 24h per day without causing incidents. The following rules are describing some unhealthy patterns we have seen across the Go community that are often forgotten. Those things can be considered bugs or can significantly increase the chances of introducing a bug.
+The coding style is not purely about what is ugly and what is not. It's mainly to make sure programs are reliable for
+running on production 24h per day without causing incidents. The following rules are describing some unhealthy patterns
+we have seen across the Go community that are often forgotten. Those things can be considered bugs or can significantly
+increase the chances of introducing a bug.
-**Defers: Don't Forget to Check Returned Errors**
+#### Defers: Don't Forget to Check Returned Errors
It's easy to forget to check the error returned by a `Close` method that we deferred.
@@ -46,9 +53,11 @@ defer f.Close() // What if an error occurs here?
// Write something to file... etc.
```
-Unchecked errors like this can lead to major bugs. Consider the above example: the `*os.File` `Close` method can be responsible for actually flushing to the file, so if an error occurs at that point, the whole **write might be aborted!** 😱
+Unchecked errors like this can lead to major bugs. Consider the above example: the `*os.File` `Close` method can be responsible
+for actually flushing to the file, so if an error occurs at that point, the whole **write might be aborted!** 😱
-Always check errors! To make it consistent and not distracting, use [runutil](https://pkg.go.dev/github.com/thanos-io/thanos@v0.11.0/pkg/runutil?tab=doc) helper package, e.g.:
+Always check errors! To make it consistent and not distracting, use [runutil](https://pkg.go.dev/github.com/thanos-io/thanos@v0.11.0/pkg/runutil?tab=doc)
+helper package, e.g.:
```go
// Use `CloseWithErrCapture` if you want to close and fail the function or
@@ -62,8 +71,10 @@ defer runutil.CloseWithErrCapture(&err, f, "close file")
defer runutil.CloseWithLogOnErr(logger, f, "close file")
```
+
_Avoid 🔥_
+----
```go
func writeToFile(...) error {
f, err := os.Open(...)
@@ -76,9 +87,9 @@ func writeToFile(...) error {
return nil
}
```
+Better 🤓
-Better 🤓
-
+----
```go
func writeToFile(...) (err error) {
f, err := os.Open(...)
@@ -93,16 +104,19 @@ func writeToFile(...) (err error) {
}
```
-**Exhaust Readers**
+#### Exhaust Readers
-One of the most common bugs is forgetting to close or fully read the bodies of HTTP requests and responses, especially on error. If you read the body of such structures, you can use the [runutil](https://pkg.go.dev/github.com/thanos-io/thanos@v0.11.0/pkg/runutil?tab=doc) helper as well:
+One of the most common bugs is forgetting to close or fully read the bodies of HTTP requests and responses, especially on
+error. If you read the body of such structures, you can use the [runutil](https://pkg.go.dev/github.com/thanos-io/thanos@v0.11.0/pkg/runutil?tab=doc)
+helper as well:
```go
defer runutil.ExhaustCloseWithLogOnErr(logger, resp.Body, "close response")
```
-Avoid 🔥
+Avoid 🔥
+----
```go
resp, err := http.Get("http://example.com/")
if err != nil {
@@ -117,8 +131,9 @@ scanner := bufio.NewScanner(resp.Body)
for scanner.Scan() {
```
-Better 🤓
+Better 🤓
+----
```go
resp, err := http.Get("http://example.com/")
if err != nil {
@@ -132,24 +147,30 @@ scanner := bufio.NewScanner(resp.Body)
for scanner.Scan() {
```
-**Avoid Globals**
-No globals other than `const` are allowed. Period. This means also, no `init` functions.
+#### Avoid Globals
-**Never Use Panics**
+No globals other than `const` are allowed. Period.
+This means also, no `init` functions.
-Never use them. If some dependency uses it, use [recover](https://golang.org/doc/effective_go.html#recover). Also, consider avoiding that dependency. 🙈
+#### Never Use Panics
-**Avoid Using the reflect or unsafe Packages**
+Never use them. If some dependency uses it, use [recover](https://golang.org/doc/effective_go.html#recover). Also, consider
+avoiding that dependency. 🙈
+
+#### Avoid Using the `reflect` or `unsafe` Packages
Use those only for very specific, critical cases. Especially `reflect` tend to be very slow. For testing code, it's fine to use reflect.
-**Avoid variable shadowing**
+#### Avoid variable shadowing
-Variable shadowing is when you use the same variable name in a smaller scope that "shadows". This is very dangerous as it leads to many surprises. It's extremely hard to debug such problems as they might appear in unrelated parts of the code. And what's broken is tiny `:` or lack of it.
+Variable shadowing is when you use the same variable name in a smaller scope that "shadows". This is very
+dangerous as it leads to many surprises. It's extremely hard to debug such problems as they might appear in unrelated parts of the code.
+And what's broken is tiny `:` or lack of it.
-Avoid 🔥
+Avoid 🔥
+----
```go
var client ClientInterface
if clientTypeASpecified {
@@ -169,8 +190,9 @@ Avoid 🔥
resp, err := client.Call(....) // nil pointer panic!
```
-Better 🤓
+Better 🤓
+----
```go
var client ClientInterface = NewNoop(...)
if clientTypeASpecified {
@@ -193,24 +215,32 @@ This is also why we recommend to scope errors if you can:
}
```
-While it's not yet configured, we might think consider not permitting variable shadowing with [`golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow`](https://godoc.org/golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow) in future. There was even Go 2 proposal for [disabling this in the language itself, but was rejected](https://github.com/golang/go/issues/21114):
+While it's not yet configured, we might think consider not permitting variable shadowing with [`golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow`](https://godoc.org/golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow)
+in future. There was even Go 2 proposal for [disabling this in the language itself, but was rejected](https://github.com/golang/go/issues/21114):
Similar to this problem is the package name shadowing. While it is less dangerous, it can cause similar issues, so avoid package shadowing if you can.
-#### Performance
+### Performance
-After all better performance is important and this might require some additional patterns in our code. With those patterns, we try to not sacrifice the readability and apply those only on the critical code paths.
+After all better performance is important and this might require some additional patterns in our code. With those patterns, we try to not sacrifice the readability and apply those only
+on the critical code paths.
-**Keep in mind to always measure the results.** The Go performance relies on many hidden things and tweaks, so the good micro benchmark, following with the real system load test is in most times required to tell if optimization makes sense.
+**Keep in mind to always measure the results.** The Go performance relies on many hidden things and tweaks, so the good
+micro benchmark, following with the real system load test is in most times required to tell if optimization makes sense.
-**Pre-allocating Slices and Maps**
+#### Pre-allocating Slices and Maps
-Try to always preallocate slices and map. If you know the number of elements you want to put apriori, use that knowledge! This significantly improves the latency of such code. Consider this as micro optimization, however, it's a good pattern to do it always, as it does not add much complexity. Performance wise, it's only relevant for critical, code paths with big arrays.
+Try to always preallocate slices and map. If you know the number of elements you want to put
+apriori, use that knowledge! This significantly improves the latency of such code. Consider this as micro optimization,
+however, it's a good pattern to do it always, as it does not add much complexity. Performance wise, it's only relevant for critical,
+code paths with big arrays.
-NOTE: This is because, in very simple view, the Go runtime allocates 2 times the current size. So if you expect million of elements, Go will do many allocations on `append` in between instead of just one if you preallocate.
+NOTE: This is because, in very simple view, the Go runtime allocates 2 times the current size. So if you expect million of elements, Go will do many allocations
+on `append` in between instead of just one if you preallocate.
-Avoid 🔥
+Avoid 🔥
+----
```go
func copyIntoSliceAndMap(biggy []string) (a []string, b map[string]struct{})
b = map[string]struct{}{}
@@ -222,8 +252,9 @@ func copyIntoSliceAndMap(biggy []string) (a []string, b map[string]struct{})
}
```
-Better 🤓
+Better 🤓
+----
```go
func copyIntoSliceAndMap(biggy []string) (a []string, b map[string]struct{})
b = make(map[string]struct{}, len(biggy))
@@ -237,14 +268,20 @@ func copyIntoSliceAndMap(biggy []string) (a []string, b map[string]struct{})
}
```
-**Reuse arrays**
+#### Reuse arrays
-To extend the above point, there are cases where you don't need to allocate new space in memory all the time. If you repeat the certain operation on slices sequentially and you just release the array on every iteration, it's reasonable to reuse the underlying array for those. This can give quite enormous gains for critical paths. Unfortunately, currently there is no way to reuse the underlying array for maps.
+To extend the above point, there are cases where you don't need to allocate new space in memory all the time. If you repeat
+the certain operation on slices sequentially and you just release the array on every iteration, it's reasonable to reuse
+the underlying array for those. This can give quite enormous gains for critical paths.
+Unfortunately, currently there is no way to reuse the underlying array for maps.
-NOTE: Why you cannot just allocate slice and release and in new iteration allocate and release again etc? Go should know it has available space and just reuses that no? \(: Well, it's not that easy. TL;DR is that Go Garbage Collection runs periodically or on certain cases \(big heap\), but definitely not on every iteration of your loop \(that would be super slow\). Read more in details [here](https://about.sourcegraph.com/go/gophercon-2018-allocator-wrestling).
+NOTE: Why you cannot just allocate slice and release and in new iteration allocate and release again etc? Go should know it has
+available space and just reuses that no? (: Well, it's not that easy. TL;DR is that Go Garbage Collection runs periodically or on certain cases
+(big heap), but definitely not on every iteration of your loop (that would be super slow). Read more in details [here](https://about.sourcegraph.com/go/gophercon-2018-allocator-wrestling).
-Avoid 🔥
+Avoid 🔥
+----
```go
var messages []string
for _, msg := range recv {
@@ -261,8 +298,9 @@ for _, msg := range recv {
}
```
-Better 🤓
+Better 🤓
+----
```go
var messages []string
for _, msg := range recv {
@@ -278,22 +316,26 @@ for _, msg := range recv {
}
```
-#### Readability
+### Readability
The part that all Gophers love ❤️ How to make code more readable?
-For the Team, readability is about programming in a way that does not surprise the reader of the code. All the details and inconsistencies can distract or mislead the reader, so every character or newline might matter. That's why we might be spending more time on every Pull Requests' review, especially in the beginning, but for a good reason! To make sure we can quickly understand, extend and fix problems with our system.
-
-**Keep the Interface Narrow; Avoid Shallow Functions**
+For the Team, readability is about programming in a way that does not surprise the reader of the code. All the details
+and inconsistencies can distract or mislead the reader, so every character or newline might matter. That's why we might be spending
+more time on every Pull Requests' review, especially in the beginning, but for a good reason! To make sure we can quickly understand,
+extend and fix problems with our system.
-This is connected more to the API design than coding, but even during small coding decisions it matter. For example how you define functions or methods. There are two general rules:
+#### Keep the Interface Narrow; Avoid Shallow Functions
-* Simpler \(usually it means smaller\) interfaces are better. This might mean a smaller, simpler function signature as well as fewer methods
+This is connected more to the API design than coding, but even during small coding decisions it matter. For example how you define functions
+or methods. There are two general rules:
- in the interfaces. Try to group interfaces based on functionality to expose at max 1-3 methods if possible.
+* Simpler (usually it means smaller) interfaces are better. This might mean a smaller, simpler function signature as well as fewer methods
+in the interfaces. Try to group interfaces based on functionality to expose at max 1-3 methods if possible.
-Avoid 🔥
+Avoid 🔥
+----
```go
// Compactor aka: The Big Boy. Such big interface is really useless ):
type Compactor interface {
@@ -310,8 +352,9 @@ type Compactor interface {
}
```
-Better 🤓
+Better 🤓
+----
```go
// Smaller interfaces with a smaller number of arguments allow functional grouping, clean composition and clear testability.
type Compactor interface {
@@ -344,14 +387,14 @@ type Cleaner interface {
}
```
-* It's better if you can hide more unnecessary complexity from the user. This means that having shallow function introduce
-
- more cognitive load to understand the function name or navigate to implementation to understand it better. It might be much
- more readable to inline those few lines directly on the caller side.
+* It's better if you can hide more unnecessary complexity from the user. This means that having shallow function introduce
+more cognitive load to understand the function name or navigate to implementation to understand it better. It might be much
+more readable to inline those few lines directly on the caller side.
-Avoid 🔥
+Avoid 🔥
+----
```go
// Some code...
s.doSomethingAndHandleError()
@@ -366,8 +409,9 @@ func (s *myStruct) doSomethingAndHandleError() {
}
```
-Better 🤓
+Better 🤓
+----
```go
// Some code...
if err := doSomething(); err != nil {
@@ -378,10 +422,13 @@ Better 🤓
}
```
-This is a little bit connected to `There should be one-- and preferably only one --obvious way to do it` and [`DRY`](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) rules. If you have more ways of doing something than one, it means you have a wider interface, allowing more opportunities for errors, ambiguity and maintenance burden.
+This is a little bit connected to `There should be one-- and preferably only one --obvious way to do it` and [`DRY`](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+rules. If you have more ways of doing something than one, it means you have a wider interface, allowing more opportunities for
+errors, ambiguity and maintenance burden.
-Avoid 🔥
+Avoid 🔥
+----
```go
// We have here SIX potential ways the caller can get an ID. Can you find all of them?
@@ -405,8 +452,9 @@ func (b *Block) ID() ulid.ULID {
func (b *Block) IDNoLock() ulid.ULID { return b.ID }
```
-Better 🤓
+Better 🤓
+----
```go
type Block struct {
// Things...
@@ -422,18 +470,22 @@ func (b *Block) ID() ulid.ULID {
}
```
-**Use Named Return Parameters Carefully**
+#### Use Named Return Parameters Carefully
-It's OK to name return parameters if the types do not give enough information about what function or method actually returns. Another use case is when you want to define a variable, e.g. a slice.
+It's OK to name return parameters if the types do not give enough information about what function or method actually returns.
+Another use case is when you want to define a variable, e.g. a slice.
-**IMPORTANT:** never use naked `return` statements with named return parameters. This compiles but it makes returning values implicit and thus more prone to surprises.
+**IMPORTANT:** never use naked `return` statements with named return parameters. This compiles but it makes returning values
+implicit and thus more prone to surprises.
-**Clean Defer Only if Function Fails**
+#### Clean Defer Only if Function Fails
-There is a way to sacrifice defer in order to properly close all on each error. Repetition makes it easier to make an error and forget something when changing the code, so on-error deferring is doable:
+There is a way to sacrifice defer in order to properly close all on each error. Repetition makes it easier to make an error
+and forget something when changing the code, so on-error deferring is doable:
-Avoid 🔥
+Avoid 🔥
+----
```go
func OpenSomeFileAndDoSomeStuff() (*os.File, error) {
f, err := os.OpenFile("file.txt", os.O_RDONLY, 0)
@@ -457,8 +509,9 @@ func OpenSomeFileAndDoSomeStuff() (*os.File, error) {
}
```
-Better 🤓
+Better 🤓
+----
```go
func OpenSomeFileAndDoSomeStuff() (f *os.File, err error) {
f, err = os.OpenFile("file.txt", os.O_RDONLY, 0)
@@ -484,30 +537,37 @@ func OpenSomeFileAndDoSomeStuff() (f *os.File, err error) {
}
```
-**Explicitly Handle Returned Errors**
+#### Explicitly Handle Returned Errors
-Always handle returned errors. It does not mean you cannot "ignore" the error for some reason, e.g. if we know implementation will not return anything meaningful. You can ignore the error, but do so explicitly:
+Always handle returned errors. It does not mean you cannot "ignore" the error for some reason, e.g. if we know implementation
+will not return anything meaningful. You can ignore the error, but do so explicitly:
-Avoid 🔥
+Avoid 🔥
+----
```go
someMethodThatReturnsError(...)
```
-Better 🤓
+Better 🤓
+----
```go
_ = someMethodThatReturnsError(...)
```
+
The exception: well-known cases such as `level.Debug|Warn` etc and `fmt.Fprint*`
-**Avoid Defining Variables Used Only Once.**
+#### Avoid Defining Variables Used Only Once.
-It's tempting to define a variable as an intermittent step to create something bigger. Avoid defining such a variable if it's used only once. When you create a variable _the reader_ expects some other usage of this variable than one, so it can be annoying to every time double check that and realize that it's only used once.
+It's tempting to define a variable as an intermittent step to create something bigger. Avoid defining
+such a variable if it's used only once. When you create a variable *the reader* expects some other usage of this variable than
+one, so it can be annoying to every time double check that and realize that it's only used once.
-Avoid 🔥
+Avoid 🔥
+----
```go
someConfig := a.GetConfig()
address124 := someConfig.Addresses[124]
@@ -517,8 +577,9 @@ Avoid 🔥
return c
```
-Better 🤓
+Better 🤓
+----
```go
// This variable is required for potentially consistent results. It is used twice.
someConfig := a.FetchConfig()
@@ -528,12 +589,13 @@ Better 🤓
}
```
-**Only Two Ways of Formatting Functions/Methods**
+#### Only Two Ways of Formatting Functions/Methods
Prefer function/method definitions with arguments in a single line. If it's too wide, put each argument on a new line.
-Avoid 🔥
+Avoid 🔥
+----
```go
func function(argument1 int, argument2 string,
argument3 time.Duration, argument4 someType,
@@ -541,8 +603,9 @@ func function(argument1 int, argument2 string,
) (ret int, err error) {
```
-Better 🤓
+Better 🤓
+----
```go
func function(
argument1 int,
@@ -556,7 +619,7 @@ func function(
This applies for both calling and defining method / function.
-NOTE: One exception would be when you expect the variadic \(e.g. `...string`\) arguments to be filled in pairs, e.g:
+NOTE: One exception would be when you expect the variadic (e.g. `...string`) arguments to be filled in pairs, e.g:
```go
level.Info(logger).Log(
@@ -567,12 +630,14 @@ level.Info(logger).Log(
)
```
-**Control Structure: Prefer early returns and avoid else**
+#### Control Structure: Prefer early returns and avoid `else`
-In most of the cases, you don't need `else`. You can usually use `continue`, `break` or `return` to end an `if` block. This enables having one less indent and better consistency so code is more readable.
+In most of the cases, you don't need `else`. You can usually use `continue`, `break` or `return` to end an `if` block.
+This enables having one less indent and better consistency so code is more readable.
-Avoid 🔥
+Avoid 🔥
+----
```go
for _, elem := range elems {
if a == 1 {
@@ -583,8 +648,9 @@ for _, elem := range elems {
}
```
-Better 🤓
+Better 🤓
+----
```go
for _, elem := range elems {
if a == 1 {
@@ -595,41 +661,47 @@ for _, elem := range elems {
}
```
-**Wrap Errors for More Context; Don't Repeat "failed ..." There.**
+#### Wrap Errors for More Context; Don't Repeat "failed ..." There.
-We use [`pkg/errors`](https://github.com/pkg/errors) package for `errors`. We prefer it over standard wrapping with `fmt.Errorf` + `%w`, as `errors.Wrap` is explicit. It's easy to by accident replace `%w` with `%v` or to add extra inconsistent characters to the string.
+We use [`pkg/errors`](https://github.com/pkg/errors) package for `errors`. We prefer it over standard wrapping with `fmt.Errorf` + `%w`,
+as `errors.Wrap` is explicit. It's easy to by accident replace `%w` with `%v` or to add extra inconsistent characters to the string.
-Use [`pkg/errors.Wrap`](https://github.com/pkg/errors) to wrap errors for future context when errors occur. It's recommended to add more interesting variables to add context using `errors.Wrapf`, e.g. file names, IDs or things that fail, etc.
+Use [`pkg/errors.Wrap`](https://github.com/pkg/errors) to wrap errors for future context when errors occur. It's recommended
+to add more interesting variables to add context using `errors.Wrapf`, e.g. file names, IDs or things that fail, etc.
When using `Errorf,Warpf` put arguments at the end to make it easyer to read and use `%v` to reduce human error if the argument type changed.
+Difficult to read 🔥
-Difficult to read 🔥
-
+----
```go
errors.Errorf("insufficient balance %s, mining stake requires %s", a, b)
```
-Better 🤓
+Better 🤓
+----
```go
errors.Errorf("insufficient mining stake TRB balance - actual:%v, required:%v", a, b)
```
-NOTE: never prefix wrap messages with wording like `failed...`, `couldn't...` or `error occurred while...`. Just describe what we wanted to do when the failure occurred. Those prefixes are just noise. We are wrapping error, so it's obvious that some error occurred, right? \(: Improve readability and consider avoiding those.
+NOTE: never prefix wrap messages with wording like `failed...`, `couldn't...` or `error occurred while...`. Just describe what we
+wanted to do when the failure occurred. Those prefixes are just noise. We are wrapping error, so it's obvious that some error
+occurred, right? (: Improve readability and consider avoiding those.
-Avoid 🔥
+Avoid 🔥
+----
```go
fmt.Errorf("error while reading from file %s: %w", f.Name, err)
```
-Better 🤓
+Better 🤓
+----
```go
errors.Wrapf(err, "read file %s", f.Name)
```
-
-**Use the Blank Identifier \_**
+#### Use the Blank Identifier `_`
Blank identifiers are very useful to mark variables that are not used. Consider the following cases:
@@ -654,19 +726,25 @@ var _ InterfaceA = TypeA
func (t *Type) SomeMethod(_ context.Context, abc int) error {
```
-**Rules for Log Messages**
+#### Rules for Log Messages
-The project uses [go-kit logger](https://github.com/go-kit/kit/tree/master/log). This means that we expect log lines to have a certain structure. Structure means that instead of adding variables to the message, those should be passed as separate fields. Keep in mind that all log lines should be `lowercase` \(readability and consistency\) and all struct keys are using `camelCase`. It's suggested to keep key names short and consistent. For example, if we always use `block` for block ID, let's not use in the other single log message `id`.
+The project uses [go-kit logger](https://github.com/go-kit/kit/tree/master/log). This means that we expect log lines
+to have a certain structure. Structure means that instead of adding variables to the message, those should be passed as
+separate fields. Keep in mind that all log lines should be `lowercase` (readability and consistency) and
+all struct keys are using `camelCase`. It's suggested to keep key names short and consistent. For example, if
+we always use `block` for block ID, let's not use in the other single log message `id`.
-Avoid 🔥
+Avoid 🔥
+----
```go
level.Info(logger).Log("msg", fmt.Sprintf("Found something epic during compaction number %v. This looks amazing.", compactionNumber),
"block_id", id, "elapsed-time", timeElapsed)
```
-Better 🤓
+Better 🤓
+----
```go
level.Info(logger).Log("msg", "found something epic during compaction; this looks amazing", "compNumber", compNumber,
"block", id, "elapsed", timeElapsed)
@@ -675,31 +753,30 @@ level.Info(logger).Log("msg", "found something epic during compaction; this look
Additionally, there are certain rules we suggest while using different log levels:
* level.Info: Should always have `msg` field. It should be used only for important events that we expect to happen not too
-
- often.
-
+often.
* level.Debug: Should always have `msg` field. It can be a bit more spammy, but should not be everywhere as well. Use it
-
- only when you want to really dive into some problems in certain areas.
-
+only when you want to really dive into some problems in certain areas.
* level.Warn: Should have either `msg` or `err` or both fields. They should warn about events that are suspicious and to investigate
-
- but the process can gracefully mitigate it. Always try to describe _how_ it was mitigated, what action will be performed e.g. `value will be skipped`
-
+but the process can gracefully mitigate it. Always try to describe *how* it was mitigated, what action will be performed e.g. `value will be skipped`
* level.Error: Should have either `msg` or `err` or both fields. Use it only for a critical event.
-**Comment Necessary Surprises**
+#### Comment Necessary Surprises
-Comments are not the best. They age quickly and the compiler does not fail if you will forget to update them. So use comments only when necessary. **And it is necessary to comment on code that can surprise the user.** Sometimes, complexity is necessary, for example for performance. Comment in this case why such optimization was needed. If something was done temporarily add `TODO(): `.
+Comments are not the best. They age quickly and the compiler does not fail if you will forget to update them. So use comments
+only when necessary. **And it is necessary to comment on code that can surprise the user.** Sometimes, complexity
+is necessary, for example for performance. Comment in this case why such optimization was needed. If something
+was done temporarily add `TODO(): `.
-#### Testing
+### Testing
-**Table Tests**
+#### Table Tests
-Use table-driven tests that use [t.Run](https://blog.golang.org/subtests) for readability. They are easy to read and allows to add a clean description of each test case. Adding or adapting test cases is also easier.
+Use table-driven tests that use [t.Run](https://blog.golang.org/subtests) for readability. They are easy to read
+and allows to add a clean description of each test case. Adding or adapting test cases is also easier.
-Avoid 🔥
+Avoid 🔥
+----
```go
host, port, err := net.SplitHostPort("1.2.3.4:1234")
testutil.Ok(t, err)
@@ -720,7 +797,9 @@ host, port, err = net.SplitHostPort("yolo")
testutil.NotOk(t, err)
```
-Better 🤓
+Better 🤓
+
+----
```go
for _, tcase := range []struct{
@@ -774,12 +853,14 @@ for _, tcase := range []struct{
}
```
-**Tests for Packages / Structs That Involve time package.**
+#### Tests for Packages / Structs That Involve `time` package.
-Avoid unit testing based on real-time. Always try to mock time that is used within struct by using, for example, a `timeNow func() time.Time` field. For production code, you can initialize the field with `time.Now`. For test code, you can set a custom time that will be used by the struct.
+Avoid unit testing based on real-time. Always try to mock time that is used within struct by using, for example, a `timeNow func() time.Time` field.
+For production code, you can initialize the field with `time.Now`. For test code, you can set a custom time that will be used by the struct.
-Avoid 🔥
+Avoid 🔥
+----
```go
func (s *SomeType) IsExpired(created time.Time) bool {
// Code is hardly testable.
@@ -787,8 +868,9 @@ func (s *SomeType) IsExpired(created time.Time) bool {
}
```
-Better 🤓
+Better 🤓
+----
```go
func (s *SomeType) IsExpired(created time.Time) bool {
// s.timeNow is time.Now on production, mocked in tests.
@@ -796,21 +878,21 @@ func (s *SomeType) IsExpired(created time.Time) bool {
}
```
-### Enforced by Linters
+## Enforced by Linters
-This is the list of rules we ensure automatically. This section is for those who are curious why such linting rules were added or want similar ones in their Go project. 🤗
+This is the list of rules we ensure automatically. This section is for those who are curious why such linting rules
+were added or want similar ones in their Go project. 🤗
-**Avoid Prints**
+#### Avoid Prints
Never use `print`. Always use a passed `go-kit/log.Logger`.
-**Comments Should be Full Sentences**
+#### Comments Should be Full Sentences
All comments should be full sentences. They should start with an uppercase letter and end with a period.
-## Bash
+# Bash
Overall try to NOT use bash. For scripts longer than 30 lines, consider writing it in Go as we did [here](https://github.com/tellor-io/telliot/blob/e502c668c0f76aa4d382eadcb7d3f0c26cfee9fb/scripts/copyright/copyright.go).
-If you have to, we follow the Google Shell style guide: [https://google.github.io/styleguide/shellguide.html](https://google.github.io/styleguide/shellguide.html)
-
+If you have to, we follow the Google Shell style guide: https://google.github.io/styleguide/shellguide.html
diff --git a/docs/telliot-documentation/configuation.md b/docs/configuation.md
similarity index 97%
rename from docs/telliot-documentation/configuation.md
rename to docs/configuation.md
index 691ff986..da58991c 100644
--- a/docs/telliot-documentation/configuation.md
+++ b/docs/configuation.md
@@ -1,13 +1,9 @@
---
description: Telliot tweaks and settings to keep your rig running smoothly.
---
-
-# Configuation
-
+# Telliot configuration
## Cli reference
-
Telliot commands and config file options are as the following:
-
#### Required Flags
* `--config` \(path to your config file.\)
@@ -29,7 +25,7 @@ Telliot commands and config file options are as the following:
#### Config file options:
* `contractAddress` \(required\) - address of TellorContract
-* `nodeURL` \(required\) - node URL \(e.g [https://mainnet.infura.io/bbbb](https://mainnet.infura.io/bbbb) or [https://localhost:8545](https://localhost:8545) if own node\)
+* `nodeURL` \(required\) - node URL \(e.g https://mainnet.infura.io/bbbb or https://localhost:8545 if own node\)
* `privateKey` \(required\) - privateKey for your address
* `databaseURL` \(required\) - where you are reading from for the server database \(if hosted\)
* `publicAddress` \(required\) - public address for your miner \(note, no 0x\)
@@ -162,6 +158,7 @@ Note that your dataServer and miners must be started with separate commands.
For more detailed instructions:[ https://docs.google.com/document/d/1k8ELb1cXkEpztHkHUt8QTL4JCcnHw5\_yQjTKIHCaSCE](https://docs.google.com/document/d/1k8ELb1cXkEpztHkHUt8QTL4JCcnHw5_yQjTKIHCaSCE)
+
### LogConfig file options
The logging.config file consists of two fields: \* component \* level
@@ -178,5 +175,4 @@ INFO - logs most information about the mining operation
WARN - logs all warnings and errors
-ERROR - logs only serious errors
-
+ERROR - logs only serious errors
\ No newline at end of file
diff --git a/docs/telliot-documentation/contributing.md b/docs/contributing.md
old mode 100644
new mode 100755
similarity index 61%
rename from docs/telliot-documentation/contributing.md
rename to docs/contributing.md
index 21a5f957..ce671d24
--- a/docs/telliot-documentation/contributing.md
+++ b/docs/contributing.md
@@ -5,48 +5,38 @@ description: Process of contributing to the project.
# Contributing
## Philosophy
-
-* The philosophy is borrowing much from UNIX philosophy and the golang programming language.Each sub command should do one thing and do it well
- * Every component behaviour should be covered with an e2e tests and if an e2e tests is not appropriate should at least have unit tests for key components of a package.
+- The philosophy is borrowing much from UNIX philosophy and the golang programming language.Each sub command should do one thing and do it well
+ - Every component behaviour should be covered with an e2e tests and if an e2e tests is not appropriate should at least have unit tests for key components of a package.
## Feedback / Issues
-
If you encounter any issue or you have an idea to improve, please:
* Search through Google and [existing open and closed GitHub Issues](https://github.com/tellor-io/telliot/issues) for the
-
- answer first. If you find relevant topic, please comment on the issue.
-
+answer first. If you find relevant topic, please comment on the issue.
* If not found, please add an issue to [GitHub issues](https://github.com/tellor-io/telliot/issues). Please provide
-
- all relevant information as template suggest.
-
+all relevant information as template suggest.
* If you have a quick question you might want to also ask on our [Discord](https://discord.gg/n7drGjh).
-
- We are recommending, using GitHub issues for issues and feedback, because GitHub issues are track-able.
+We are recommending, using GitHub issues for issues and feedback, because GitHub issues are track-able.
If you encounter security vulnerability, please let us know privately via the Team email address: [info@tellor.io](mailto:info@tellor.io?subject=Security%20vulnerability%20report)
## Adding New Features / Components
-
-For any major changes or new features, please first discuss the change you wish to make via issue or Discord, or any other method before making a change.
+For any major changes or new features, please first
+discuss the change you wish to make via issue or Discord, or any other
+method before making a change.
## Development
-
The following section explains various suggestions and procedures to note during development.
### First Steps
-
* Familiarizing yourself with our [coding style guidelines.](coding-style-guide.md).
-* Familiarizing yourself with the [Makefile](https://github.com/tellor-io/telliot/tree/4b4e37cbbd76473f59261ae9790918446cc5114c/Makefile/README.md) commands, for example, `build`, `format`, `test`, `lint`.
-
- `make help` will print all available commands with some description.
+* Familiarizing yourself with the [Makefile](../Makefile) commands, for example, `build`, `format`, `test`, `lint`.
+`make help` will print all available commands with some description.
### Pull Request Process
-
1. Fork tellor-io/telliot.git and start development from your own fork. Here are sample steps to setup your development environment:
-```text
+```console
$ GOPATH=$(go env GOPATH)
$ mkdir -p $GOPATH/src/github.com/tellor-io
$ cd $GOPATH/src/github.com/tellor-io
@@ -57,11 +47,11 @@ $ make build
$ ./telliot -h
```
-1. Keep PRs as small as possible. For each of your PRs, you create a new branch based on the latest master.
- Chain them if needed \(base one PR on other PRs\). You can read more details about the workflow from [here](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
+1. Keep PRs as small as possible. For each of your PRs, you create a new branch based on the latest master.
+Chain them if needed (base one PR on other PRs). You can read more details about the workflow from [here](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
-```text
+```console
$ git checkout master
$ git pull origin master
$ git checkout -b
@@ -69,13 +59,12 @@ $
$ git push fork
```
-1. If your change affects users \(adds,removes or changes a feature\) add the item to the [CHANGELOG](changelog.md).
-2. Add e2e tests for new features and changes to functionality. Add unit tests for key components of the packages.
-3. A PR will me merged once the PR has been approved by at least one developer with write access.
-4. If you feel like your PR is waiting too long for a review, feel free to ping in the [Discord](https://discord.gg/n7drGjh) channel for a review!
+1. If your change affects users (adds,removes or changes a feature) add the item to the [CHANGELOG](CHANGELOG.md).
+1. Add e2e tests for new features and changes to functionality. Add unit tests for key components of the packages.
+1. A PR will me merged once the PR has been approved by at least one developer with write access.
+1. If you feel like your PR is waiting too long for a review, feel free to ping in the [Discord](https://discord.gg/n7drGjh) channel for a review!
### Dependency management
-
The project uses [Go modules](https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) to manage dependencies on external packages. This requires a working Go environment with version 1.11 or greater and git installed.
To add or update a new dependency, use the `go get` command:
@@ -97,6 +86,4 @@ git commit
```
### Project development go tools
-
-The project uses [Bingo](https://github.com/tellor-io/telliot/tree/4b4e37cbbd76473f59261ae9790918446cc5114c/.bingo/README.md) for adding any go tools required by the project.
-
+The project uses [Bingo](../.bingo/README.md) for adding any go tools required by the project.
diff --git a/docs/telliot-documentation/release-process.md b/docs/release-process.md
old mode 100644
new mode 100755
similarity index 74%
rename from docs/telliot-documentation/release-process.md
rename to docs/release-process.md
index 18b8e9d4..d1637c11
--- a/docs/telliot-documentation/release-process.md
+++ b/docs/release-process.md
@@ -2,32 +2,28 @@
description: Release cadence and process for the project.
---
-# Release process
-
-## Release Process
+# Release Process
We use [Semantic Versioning](http://semver.org/).
-NOTE: As [Semantic Versioning](http://semver.org/spec/v2.0.0.html) states all 0.y.z releases can contain breaking changes in API \(flags, grpc API, any backward compatibility\)
+NOTE: As [Semantic Versioning](http://semver.org/spec/v2.0.0.html) states all 0.y.z releases can contain breaking changes in API (flags, grpc API, any backward compatibility)
-### Cadence
+## Cadence
* We aim to keep the master branch in a working state at all times. In principle, it should be possible to cut a release from master at any time. In practice, things might not work out as nicely. A few days before the pre-release is scheduled, the shepherd should check the state of master. Following their best judgement, the shepherd should try to expedite bug fixes that are still in progress but should make it into the release. On the other hand, the shepherd may hold back merging last-minute invasive and risky changes that are better suited for the next minor release.
* No feature should block release.
-#### Branch management and versioning strategy
-
+### Branch management and versioning strategy
We use [Semantic Versioning](https://semver.org/).
We are a small team and don't have the capacity to maintain patch release branches so will create branches only for major releases: `release-`, e.g. `release-1`, `release-2`.
Note that branch protection kicks in automatically for any branches whose name starts with `release-` so never use names starting with `release-` for branches that are not release branches.
-#### Updating dependencies
-
+### Updating dependencies
A few days before a release, consider updating the dependencies:
-```text
+```
make update-go-deps
git add go.mod go.sum
git commit -m "Update dependencies"
@@ -35,22 +31,24 @@ git commit -m "Update dependencies"
Then create a pull request against the master branch.
-Note that after a dependency update, you should look out for any weirdness that might have happened. Such weirdnesses include but are not limited to: flaky tests, differences in resource usage, panic.
+Note that after a dependency update, you should look out for any weirdness that
+might have happened. Such weirdnesses include but are not limited to: flaky
+tests, differences in resource usage, panic.
-In case of doubt or issues that can't be solved in a reasonable amount of time, you can skip the dependency update or only update select dependencies. In such a case, you have to create an issue or pull request in the GitHub project for later follow-up.
+In case of doubt or issues that can't be solved in a reasonable amount of time,
+you can skip the dependency update or only update select dependencies. In such a
+case, you have to create an issue or pull request in the GitHub project for
+later follow-up.
-## Cutting a release
-
-### Update `CHANGELOG.md`
+# Cutting a release
+## Update `CHANGELOG.md`
Do this in a PR against `master` as this gives others the opportunity to chime in on the release and the changelog changes.
Note:
-
> that `CHANGELOG.md` should only document changes relevant to users of the project, including external API changes, performance improvements, and new features. Do not document changes of internal interfaces, code refactorings and clean-ups, changes to the build process, etc. People interested in these are asked to refer to the git history.
-### Draft the new release
-
+## Draft the new release
On `master` tag the current commit as a new release via the following commands:
```bash
@@ -59,10 +57,10 @@ $ git tag $TAG
$ git push origin $TAG
```
-Once a tag is pushed, the release process is triggered through the CI and it will draft the GitHub release and upload all artifacts. If all looks good click _Publish release_. This will make the release publicly visible and create a GitHub notification.
-
-### Wrapping up
+Once a tag is pushed, the release process is triggered through the CI and it will draft the GitHub release and upload all artifacts.
+If all looks good click _Publish release_. This will make the release publicly visible and create a GitHub notification.
-Announce the release on the communication channels.
- Check out previous announcements for inspiration.
+## Wrapping up
+Announce the release on the communication channels.
+Check out previous announcements for inspiration.
diff --git a/docs/telliot-documentation/setup-and-usage.md b/docs/setup-and-usage.md
similarity index 91%
rename from docs/telliot-documentation/setup-and-usage.md
rename to docs/setup-and-usage.md
index d87e0c6b..69737813 100644
--- a/docs/telliot-documentation/setup-and-usage.md
+++ b/docs/setup-and-usage.md
@@ -4,9 +4,7 @@ description: Here are the nuts and bolts for mining TRB.
# Setup and usage
-## Setup and usage
-
-### Become a Miner
+## Become a Miner
For over a decade now, the Bitcoin network has shown how proof-of-work can incentivize individuals and companies to compete for the honor of finding block rewards and achieving consensus. This phenomenon is global, and anonymous. The network is democratized and decentralized, because the creators have no direct control over who is providing computing power on their network.
@@ -21,7 +19,7 @@ As of now, mining requires you deposit 500 Tellor Tributes. These are a security
The guide that follows assumes that you have access to a suitable machine running linux to use for mining. For information about what constitutes a "suitable machine", we recommend reaching out to the community.
-### Download the Latest telliot
+## Download the Latest telliot
This is the workhorse of the Miner system.
@@ -37,7 +35,7 @@ Depending on your miner setup you may need to give telliot permission to run. If
chmod +x tellor
```
-### Download and Edit config.json
+## Download and Edit config.json
config.json is where you will enter your wallet address and configure telliot for your machine.
@@ -50,7 +48,7 @@ Open config.json and update the following values:
* Set `"nodeURL"` to an Ethereum node endpoint. \(e.g. Infura API endpoint\)
* Set `"publicAddress"` to the public key for the Ethereum wallet you plan to use for mining. Remove the 0x prefix at the beginning of the address.
-### Create .env file
+## Create .env file
Create a file named `configs/.env` \(Note: This step can be skipped in you plan to mine on a pool.\)
@@ -60,7 +58,7 @@ Copy and paste the following into your `.env` file, and edit this to match your
ETH_PRIVATE_KEY="3a10b4bc1258e8bfefb95b498fb8c0f0cd6964a811eabca87df56xxxxxxxxxxxx"
```
-### Download the API Index and Logging Config Files
+## Download the API Index and Logging Config Files
Run the following commands:
@@ -70,7 +68,7 @@ wget https://raw.githubusercontent.com/tellor-io/telliot/master/configs/indexes.
wget https://raw.githubusercontent.com/tellor-io/telliot/master/configs/loggingConfig.json
```
-### Download and Edit the Manual Data Entry File
+## Download and Edit the Manual Data Entry File
Tellor currently has one data point which must be manually created. The rolling 3 month average of the US PCE . It is updated monthly. _Make sure to keep this file up to date._
@@ -91,7 +89,7 @@ The following example shows request ID 4, inputting a value of 9000 with a 1,000
}
```
-### Deposit your Initial Stake
+## Deposit your Initial Stake
You will need 500 TRB to run your own server for mining. Your stake is locked for a minimum of 7 days after you run the command to request withdrawal.
@@ -107,7 +105,7 @@ tellor --config=./configs/config.json stake deposit
If needed, change the name of config.json to match the name of your config file.
-### Run the miner
+## Run the miner
Start the dataServer:
@@ -123,7 +121,7 @@ tellor --config=./configs/config.json mine
After starting the miner, observe the logs it outputs to confirm it's working correctly. In the next section we will look at some configuration options that can help improve performance.
-### Unstaking / Ending Mining Operations
+## Unstaking / Ending Mining Operations
To unstake your tokens, you need to request a withdraw:
@@ -137,7 +135,7 @@ One week after the request, the tokens are free to move at your discretion after
tellor --config=./configs/config.json stake withdraw
```
-### Running the Disputer
+## Running the Disputer
Tellor as a system only functions properly if parties actively monitor the tellor network and dispute bad values. Expecting parties to manually look at every value submitted is obviously burdensome. The Tellor disputer automates this fact checking of values.
@@ -160,9 +158,9 @@ Where 5 and .01 are the defaults, the variables are the amount of time in minute
If the disputer is successful and finds a submitted outside of your acceptable range, a text file containing pertinent information will be created in your working directory \(the one you're running the miner out of\) in the format: `"possible-dispute-(blocktime).txt"`
-## Disclaimer
+# Disclaimer
-If you are building a competing client, please contact us. A lot of the miner specifications are off-chain and a significant portion of the mining process hinges on the consensus of the Tellor community to determine what proper values are. Competing clients that change different pieces run the risk of being disputed by the community.
+If you are building a competing client, please contact us. A lot of the miner specifications are off-chain and a significant portion of the mining process hinges on the consensus of the Tellor community to determine what proper values are. Competing clients that change different pieces run the risk of being disputed by the community.
As an example, request ID 4 is BTC/USD. If the api's all go down, it is the responsibility of the miner to still submit a valid BTC/USD price. If they do not, they risk being disputed and slashed. For these reasons, please contribute openly to the official Tellor miner \(or an open source variant\), as consensus here is key. If your miner gets a different value than the majority of the other miners, you risk being punished!
diff --git a/docs/telliot-documentation/changelog.md b/docs/telliot-documentation/changelog.md
deleted file mode 100644
index 970621d4..00000000
--- a/docs/telliot-documentation/changelog.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
-
-NOTE: As semantic versioning states all 0.y.z releases can contain breaking changes in API \(flags, grpc API, any backward compatibility\)
-
-We use _breaking :warning:_ to mark changes that are not backward compatible \(relates only to v0.y.z releases.\)
-
-## Unreleased
-
-* [\#272](https://github.com/tellor-io/telliot/pull/272) Automated Docker images on every push to master and with every tagged release.
-
-## [v5.2.0](https://github.com/tellor-io/telliot/releases/tag/v5.2.0) - 2020.11.12
-
-* [\#254](https://github.com/tellor-io/telliot/pull/254)
- * Added support for expanding variables in the indexer api url.
- * Added config to specify the `.env` file location. The default is now `configs/.env` so users should either specify a custom location in the `config.json` or move it inside the default config folder.
-
-## [v5.0.0](https://github.com/tellor-io/telliot/releases/tag/v5.0.0) - 2020.11.02
-
-### Added
-
-* Profitability calculations which is set through the `ProfitThreshold`\(in percents\) settings in the config,
-* Docs how to contribute.
-
diff --git a/docs/telliot-documentation/readme.md b/docs/telliot-documentation/readme.md
deleted file mode 100644
index 0abc9999..00000000
--- a/docs/telliot-documentation/readme.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Introduction
-
- [](https://www.tellor.io/)
-
- [](https://twitter.com/WeAreTellor)
-
-> ### ⚠️ Note!
->
-> Telliot docs are synced from the project repository. To edit please visit:
-> [Telliot gitbook space](https://docs.tellor.io/telliot)
-> or
-> [Telliot github repo](https://github.com/tellor-io/telliot/tree/master/docs)
-
-## Telloit
-
-This is the main cli of the project. One if its commands is to run in mining mode\(solve a POW challenge\) and submit values to the tellor oracle contract. It's built on Go and utilizes a split structure. The database piece is a LevelDB that keeps track of all variables \(challenges, difficulty, values to submit, etc.\) and the miner simply solves the PoW challenge. This enables parties to split the pieces for optimization.
-
-The Tellor system is a way to push data on-chain. What pieces of data are pushed are specificied in the `configs/indexes.json`. Note that the data corresponds to a specific API. The tellor mining system is set up to pull api data to generate these values to submit on-chain once a correct nonce is mined. These specific apis are just suggestions. The system is not guarunteed to work for everyone. It is up to the consnesus of the Tellor token holders to determine what a correct value is. As an example, request ID 4 is BTC/USD. If the api's all go down, it is the responsibility of the miner to still submit a valid BTC/USD price. If they do not, they risk being disputed and slashed. For these reasons, please contribute openly to the official Tellor miner \(or an open source variant\), as consensus here is key. If you're miner gets a different value than the majority of the of the other miners, you risk being punished.
-
-A list of all PSR's\(pre specified requests\) and the expected data can be found [here](https://github.com/tellor-io/telliot/tree/f6791d8fb61f7d49051624a70a96b7d6a3f77345/pkg/tracker/psrs.go).
-
-
-
-### Instructions for deployment
-
-* [Telliot Instructions](https://github.com/tellor-io/telliot/tree/f6791d8fb61f7d49051624a70a96b7d6a3f77345/docs/docs/setup-and-usage.md)
-
-### Contributing and building from source
-
-Contributions are very welcome!
- See our [04\_contributing.md](contributing.md) for more information.
-
-### Run with Docker
-
-Available tags: [https://hub.docker.com/u/tellor](https://hub.docker.com/u/tellor) docker run -v $\(pwd\)/.local:/configs tellor/telliot:master mine
-
-### Maintainers
-
-This repository is maintained by the [Tellor team](https://github.com/orgs/tellor-io/people)
-
-#### DISCLAIMER
-
-Mine at your own risk.
-
-Mining requires you deposit 1000 Tellor Tributes. These are a security deposity. If you are a malicious actor \(aka submit a bad value\), the community can vote to slash your 1000 tokens.
-
-Mining also requires submitting on-chain transactions on Ethereum. These transactions cost gas \(ETH\) and can sometimes be signifiant if the cost of gas on EThereum is high \(i.e. the network is clogged\). Please reach out to the community to find the best tips for keeping gas costs under control or at least being aware of the costs.
-
-If you are building a competing client, please contact us. The miner specifications are off-chain and the validity of the mining process hinges on the consensus of the Tellor community to determine what proper values are. Competing clients that change different pieces run the risk of being disputed by the commmunity.
-
-There is no guaruntee of profit from mining.
-
-There is no promise that Tellor Tributes currently hold or will ever hold any value.
-
-#### Copyright
-
-Tellor Inc. 2019
-