Style nits

nep-0000-template.md

@@ -58,11 +58,11 @@ See example above -->
 
 [This technical section is required for Protocol proposals but optional for other categories. A draft implementation should demonstrate a minimal implementation that assists in understanding or implementing this proposal. Explain the design in sufficient detail that:
 
-- Its interaction with other features is clear.
-- Where possible, include a Minimum Viable Interface subsection expressing the required behavior and types in a target programming language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
-- It is reasonably clear how the feature would be implemented.
-- Corner cases are dissected by example.
-- For protocol changes: A link to a draft PR on nearcore that shows how it can be integrated in the current code. It should at least solve the key technical challenges.
+* Its interaction with other features is clear.
+* Where possible, include a Minimum Viable Interface subsection expressing the required behavior and types in a target programming language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
+* It is reasonably clear how the feature would be implemented.
+* Corner cases are dissected by example.
+* For protocol changes: A link to a draft PR on nearcore that shows how it can be integrated in the current code. It should at least solve the key technical challenges.
 
 The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.]
 
@@ -84,15 +84,15 @@ The section should return to the examples given in the previous section, and exp
 
 ### Positive
 
-- p1
+* p1
 
 ### Neutral
 
-- n1
+* n1
 
 ### Negative
 
-- n1
+* n1
 
 ### Backwards Compatibility
 
@@ -102,9 +102,9 @@ The section should return to the examples given in the previous section, and exp
 
 [Explain any issues that warrant further discussion. Considerations
 
-- What parts of the design do you expect to resolve through the NEP process before this gets merged?
-- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
-- What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?]
+* What parts of the design do you expect to resolve through the NEP process before this gets merged?
+* What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
+* What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?]
 
 ## Changelog
 
@@ -118,8 +118,8 @@ The section should return to the examples given in the previous section, and exp
 
 > List of benefits filled by the Subject Matter Experts while reviewing this version:
 
-- Benefit 1
-- Benefit 2
+* Benefit 1
+* Benefit 2
 
 #### Concerns
 

neps/nep-0514.md

@@ -32,6 +32,7 @@ The number of validating nodes on `testnet` is somewhere in the range of
 them are chunk-only producers. [Grafana](https://nearinc.grafana.net/goto/7Kh81P7IR?orgId=1).
 
 `testnet` configuration is currently the following:
+
 * `"num_block_producer_seats": 100,`
 * `"num_block_producer_seats_per_shard": [ 100, 100, 100, 100 ],`
 * `"num_chunk_only_producer_seats": 200,`
@@ -40,9 +41,10 @@ It's evident that the 100 block producer seats significantly outnumber the
 validating nodes in `testnet`.
 
 An alternative solution to the problem stated above can be the following:
+
 1. Encourage the community to run more `testnet` validating nodes
 1. Release owners or developers of features start a lot of validating nodes to
-2. ensure `testnet` gets some chunk-only producing nodes.
+1. ensure `testnet` gets some chunk-only producing nodes.
 1. Exercise the unique code paths in a separate chain, a-la `localnet`.
 
 Let's consider each of these options.
@@ -124,16 +126,16 @@ of the number of `testnet` validating nodes.
 
 ### Positive
 
-- Chunk-only production gets tested in `testnet`
-- Development of State Sync and other features related to chunk-only producers accelerates
+* Chunk-only production gets tested in `testnet`
+* Development of State Sync and other features related to chunk-only producers accelerates
 
 ### Neutral
 
-- `testnet` block production becomes more centralized
+* `testnet` block production becomes more centralized
 
 ### Negative
 
-- Any?
+* Any?
 
 ### Backwards Compatibility
 
@@ -153,8 +155,8 @@ with the protocol versions containing the implementation of this NEP.
 
 > List of benefits filled by the Subject Matter Experts while reviewing this version:
 
-- Benefit 1
-- Benefit 2
+* Benefit 1
+* Benefit 2
 
 #### Concerns