Fix typos in 3 files in Implementers Guide

docs/contributor/CONTRIBUTING.md

@@ -79,7 +79,7 @@ All Pull Requests must contain proper title & description, as described in [Pull
 Template](./PULL_REQUEST_TEMPLATE.md). Moreover, all pull requests must have a proper `prdoc` file attached.
 
 Some Pull Requests can be exempt of `prdoc` documentation, those must be labelled with
-[`R0-silent`](https://github.com/paritytech/labels/blob/main/ruled_labels/specs_polkadot-sdk.yaml#L89-L91).
+[`R0-silent`](https://github.com/paritytech/labels/blob/main/ruled_labels/specs_polkadot-sdk.yaml#L95-L97).
 
 Non "silent" PRs must come with documentation in the form of a `.prdoc` file.
 

polkadot/roadmap/implementers-guide/src/node/availability/availability-recovery.md

@@ -1,7 +1,7 @@
 # Availability Recovery
 
 This subsystem is responsible for recovering the data made available via the
-[Availability Distribution](availability-distribution.md) subsystem, neccessary for candidate validation during the
+[Availability Distribution](availability-distribution.md) subsystem, necessary for candidate validation during the
 approval/disputes processes. Additionally, it is also being used by collators to recover PoVs in adversarial scenarios
 where the other collators of the para are censoring blocks.
 
@@ -180,5 +180,5 @@ As a last resort, do `FetchChunks`.
 Collators currently only use `FetchChunks`, as they only attempt recoveries in rare scenarios.
 
 Moreover, the recovery task is specially configured to not attempt requesting data from the local availability-store
-(because it doesn't exist) and to not reencode the data after a succcessful recovery (because it's an expensive check
+(because it doesn't exist) and to not reencode the data after a successful recovery (because it's an expensive check
 that is not needed; checking the pov_hash is enough for collators).

polkadot/roadmap/implementers-guide/src/node/backing/statement-distribution.md

@@ -131,7 +131,7 @@ on the node side is purely an optimization, as it will be done in the runtime
 as well.
 
 We use the state of the relay parent to check whether a validator is disabled
-to avoid race conditions and ensure that disabling works well in the presense
+to avoid race conditions and ensure that disabling works well in the presence
 of re-enabling.
 
 ## Messages

polkadot/roadmap/implementers-guide/src/runtime-api/candidate-pending-availability.md

@@ -4,7 +4,7 @@ Get the receipt of a candidate pending availability. This returns `Some` for any
 `availability_cores` and `None` otherwise.
 
 ```rust
-// Deprectated.
+// Deprecated.
 fn candidate_pending_availability(at: Block, ParaId) -> Option<CommittedCandidateReceipt>;
 // Use this one
 fn candidates_pending_availability(at: Block, ParaId) -> Vec<CommittedCandidateReceipt>;