lint: lint markdown files

.markdownlint.yaml

@@ -0,0 +1,3 @@
+---
+line-length: false
+no-hard-tabs: false

CONTRIBUTING.md

@@ -1,3 +1,5 @@
+# How to Contribute
+
 ## Discussion
 
 Long-term discussion and bug reports are maintained via [GitHub Issues].
@@ -55,7 +57,7 @@ All files should have `gofmt` executed on them and code should strive to have fu
 We follow a rough convention for commit messages that is designed to answer two questions: what changed and why.
 The subject line should feature the what and the body of the commit should describe the why.
 
-```
+```git
 scripts: add the test-cluster command
 
 this uses tmux to setup a test cluster that you can easily kill and
@@ -66,7 +68,7 @@ Fixes #38
 
 The format can be described more formally as follows:
 
-```
+```git
 <subsystem>: <what changed>
 <BLANK LINE>
 <why this change was made>

README.md

@@ -57,10 +57,10 @@ For more information read [CONTRIBUTING.md].
 In order to compile the project, the [latest stable version of Go] and knowledge of a [working Go environment] are required.
 
 ```sh
-$ git clone git@github.com:chihaya/chihaya.git
-$ cd chihaya
-$ go build ./cmd/chihaya
-$ ./chihaya --help
+git clone git@github.com:chihaya/chihaya.git
+cd chihaya
+go build ./cmd/chihaya
+./chihaya --help
 ```
 
 [latest stable version of Go]: https://golang.org/dl
@@ -79,14 +79,14 @@ The following will run all tests and benchmarks.
 Removing `-bench` will just run unit tests.
 
 ```sh
-$ go test -bench $(go list ./...)
+go test -bench $(go list ./...)
 ```
 
 The Chihaya executable contains a command to end-to-end test a BitTorrent tracker.
 See
 
 ```sh
-$ chihaya --help
+chihaya --help
 ```
 
 ### Configuration

docs/architecture.md

@@ -1,6 +1,6 @@
 # Architecture
 
-### Overview
+## Overview
 
 BitTorrent clients send Announce and Scrape requests to a _Frontend_.
 Frontends parse requests and write responses for the particular protocol they implement.
@@ -11,6 +11,6 @@ After all PreHooks have executed, any missing response fields that are required
 PostHooks are asynchronous tasks that occur after a response has been delivered to the client.
 Because they are unnecessary to for generating a response, updates to the Storage for a particular request are done asynchronously in a PostHook.
 
-### Diagram
+## Diagram
 
-![](https://user-images.githubusercontent.com/343539/52676700-05c45c80-2ef9-11e9-9887-8366008b4e7e.png)
+![architecture diagram](https://user-images.githubusercontent.com/343539/52676700-05c45c80-2ef9-11e9-9887-8366008b4e7e.png)

docs/frontend.md

@@ -62,6 +62,7 @@ Frontends may provide runtime metrics, such as the number of requests or their d
 Metrics must be reported using [Prometheus].
 
 A frontend should provide at least the following metrics:
+
 - The number of valid and invalid requests handled
 - The average time it takes to handle a single request.
   This request timing should be made optional using a config entry.
@@ -70,6 +71,7 @@ Requests should be separated by type, i.e. Scrapes, Announces, and other protoco
 If the frontend serves multiple transports or networks, metrics for them should be separable.
 
 It is recommended to publish one Prometheus `HistogramVec` with:
+
 - A name like `chihaya_PROTOCOL_response_duration_milliseconds`
 - A value holding the duration in milliseconds of the reported request
 - Labels for:

docs/storage/redis.md

@@ -59,7 +59,7 @@ All the InfoHashes (swarms) are also stored in a redis hash, with IP family as t
 
 Here is an example:
 
-```
+```yaml
 - IPv4
   - IPv4_S_<infohash 1>: <modification time>
   - IPv4_L_<infohash 1>: <modification time>
@@ -73,15 +73,14 @@ Here is an example:
   - <peer 3 key>: <modification time>
 ```
 
-
 In this case, prometheus would record two swarms, three seeders, and one leecher.
 These three keys per address family are used to record the count of swarms, seeders, and leechers.
 
-```
+```yaml
 - IPv4_infohash_count: 2
 - IPv4_S_count: 3
 - IPv4_L_count: 1
 ```
 
-Note: IPv4_infohash_count has a different meaning compared to the `memory` storage:
+Note: `IPv4_infohash_count` has a different meaning compared to the `memory` storage:
 It represents the number of infohashes reported by seeder, meaning that infohashes without seeders are not counted.