Proof read - 3

roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md

@@ -88,12 +88,12 @@ pub struct Participation {
 	recent_block: Option<(BlockNumber, Hash)>,
 }
 ```
-New candidate is added for processing by calling `fn queue_participation`. The function either starts
+New candidate is added for processing by calling `fn queue_participation()`. The function either starts
 processing immediately or queues the request. `Participation` uses another internal module `Queues` which
 provides prioritisation of the disputes. It guarantees that important disputes will be processed first. The
 actual decision how important is a given dispute is performed by the `ordering` module.
 
-The actual participation is performed by `fn participate`. First it sends
+The actual participation is performed by `fn participate()`. First it sends
 `AvailabilityRecoveryMessage::RecoverAvailableData` to obtain data from the validators. Then gets the
 validation code and stores `AvailableData` with `AvailabilityStoreMessage::StoreAvailableData` message.
 Finally Participation module performs the actual validation and sends the result as `WorkerMessage` to the
@@ -130,16 +130,16 @@ pub struct SpamSlots {
 }
 ```
 
-It's worth noting that `SpamSlots` provides an interface for adding entries (`fn add_unconfirmed`) and
-removing them (`fn clear`). The actual spam protection logic resides in the main subsystem, in
-`fn handle_import_statements`. It is invoked during `DisputeCoordinatorMessage::ImportStatements` message
+It's worth noting that `SpamSlots` provides an interface for adding entries (`fn add_unconfirmed()`) and
+removing them (`fn clear()`). The actual spam protection logic resides in the main subsystem, in
+`fn handle_import_statements()`. It is invoked during `DisputeCoordinatorMessage::ImportStatements` message
 handling (there is a dedicated section for it below). Spam slots are indexed by session id and validator
 index. For each such pair there is a limit of active disputes. If this limit is reached - the import is
 ignored.
 
 Spam protection is performed only on invalid vote statements which are not included in any chain, not
 confirmed, not local and the votes hasn't reached the byzantine threshold. This check is performed by
-`Ordering` module ().
+`Ordering` module.
 
 Spam slots are cleared when the session window advances so that the `SpamSlots` state doesn't grow
 indefinitely.
@@ -184,7 +184,7 @@ statement is not issued. A list of these is passed to the main loop.
 
 ### The main loop
 
-Just after the subsystem initialisation the main loop (`fn run_until_error`) runs until
+Just after the subsystem initialisation the main loop (`fn run_until_error()`) runs until
 `OverseerSignal::Conclude` signal is received. Before executing the actual main loop the leaf and the
 participations, obtained during startup are enqueued for processing. If there is capacity (the number of
 running participations is less than `MAX_PARALLEL_PARTICIPATIONS`) participation jobs are started
@@ -218,7 +218,7 @@ Performs cleanup of the finalized candidate.
 
 ### On `DisputeCoordinatorMessage::ImportStatements`
 
-Import statements by validators are processed in `fn handle_import_statements`. The function has got three
+Import statements by validators are processed in `fn handle_import_statements()`. The function has got three
 main responsibilities:
 * Initiate participation in disputes.
 * Persist all fresh votes in the database. Fresh votes in this context means votes that are not already
@@ -242,7 +242,7 @@ response.
 
 ### On `DisputeCoordinatorMessage::IssueLocalStatement`
 
-Executes `fn issue_local_statement` which performs the following operations:
+Executes `fn issue_local_statement()` which performs the following operations:
 
 * Deconstruct into parts `{ session_index, candidate_hash, candidate_receipt, is_valid }`.
 * Construct a [`DisputeStatement`][DisputeStatement] based on `Valid` or `Invalid`, depending on the
@@ -256,7 +256,7 @@ Executes `fn issue_local_statement` which performs the following operations:
 
 ### On `DisputeCoordinatorMessage::DetermineUndisputedChain`
 
-Executes `fn determine_undisputed_chain` which performs the following:
+Executes `fn determine_undisputed_chain()` which performs the following:
 
 * Load `"recent-disputes"`.
 * Deconstruct into parts `{ base_number, block_descriptions, rx }`