add suggestions from review

Co-Authored-By: Gabriele Vernetti <[email protected]>

src/docs/index.md

@@ -29,7 +29,7 @@ They can further distribute jobs to a Mining Proxy (or Proxies) via the Job Dist
 
 ### Template Providers
 
-Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation.
+Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job Declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation.
 
 ## Sub-Protocols
 
@@ -56,4 +56,4 @@ Used to get information about the next block out of Bitcoin Core. This protocol
 
 ### Job Distribution Protocol
 
-Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job declaration protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets.
+Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Declaration Protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets.

src/features.md

@@ -98,11 +98,11 @@ Miners can choose their own work and mine their chosen transaction set in Sv2, f
 
 Job Selection by end-miners is an optional component of Stratum V2, separate from the main mining protocol. In fact, this is actually done by three sub-protocols:
 
-1. Job declaration Protocol
+1. Job Declaration Protocol
 2. Job Distribution Protocol
 3. Template Distribution Protocol.
 
-Job selection is a declaration process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a negotiated template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions.
+Job selection is a declaration process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a declared template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions.
 
 #### Motivation & Impact
 

src/getting-started.md

@@ -259,10 +259,10 @@ Eventually, the Translation Proxy log output will show sucessful share, which me
 ```
 
 
-## Config D: SV1 firmware > Translation Proxy JN (job declarator) > SV2 Pool
+## Config D: SV1 firmware > Translation Proxy JD (Job Declarator) > SV2 Pool
 
-This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **job declarator (JN)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JN**. 
-In the following guide a Template Provider is installed locally on the same machine, to provide block templates to the JN.
+This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **Job Declarator (JD)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JDS (Job Declarator Server)**. 
+In the following guide a Template Provider is installed locally on the same machine, to provide block templates to the JD.
 
 ![Config2](/assets/config-d.svg)
 
@@ -389,10 +389,10 @@ If the pool properly starts you should see the following log lines:
 > cargo run -p pool_sv2 -- -c [your-custom-config.toml]
 > ```
 
-### 3. Start **Translator (tProxy) JN**
+### 3. Start **Translator (tProxy) JD**
 
 Once the SV2 pool is running, let's run the tProxy that will facilitate communication between the pool and a SV1 miner.
-Differently from the Config C, in this case the **tProxy** will be acting as a **job declarator (JN)**, so it will select transactions locally and send them to the **Pool-side JN**
+Differently from the Config C, in this case the **tProxy** will be acting as a **Job Declarator (JD)**, so it will select transactions locally and send them to the **Pool-side JDS**
 ```
 cd stratum/roles/translator/
 ```