guide: remove refences to Fisherman

roadmap/implementers-guide/src/node/availability/README.md

@@ -1,3 +1,3 @@
 # Availability Subsystems
 
-The availability subsystems are responsible for ensuring that Proofs of Validity of backed candidates are widely available within the validator set, without requiring every node to retain a full copy. They accomplish this by broadly distributing erasure-coded chunks of the PoV, keeping track of which validator has which chunk by means of signed bitfields. They are also responsible for reassembling a complete PoV when required, e.g. when a fisherman reports a potentially invalid block.
+The availability subsystems are responsible for ensuring that Proofs of Validity of backed candidates are widely available within the validator set, without requiring every node to retain a full copy. They accomplish this by broadly distributing erasure-coded chunks of the PoV, keeping track of which validator has which chunk by means of signed bitfields. They are also responsible for reassembling a complete PoV when required, e.g. when an approval checker needs to validate a parachain block.

roadmap/implementers-guide/src/protocol-overview.md

@@ -8,7 +8,6 @@ First, it's important to go over the main actors we have involved in this protoc
 
 1. Validators. These nodes are responsible for validating proposed parachain blocks. They do so by checking a Proof-of-Validity (PoV) of the block and ensuring that the PoV remains available. They put financial capital down as "skin in the game" which can be slashed (destroyed) if they are proven to have misvalidated.
 1. Collators. These nodes are responsible for creating the Proofs-of-Validity that validators know how to check. Creating a PoV typically requires familiarity with the transaction format and block authoring rules of the parachain, as well as having access to the full state of the parachain.
-1. Fishermen. These are user-operated, permissionless nodes whose goal is to catch misbehaving validators in exchange for a bounty. Collators and validators can behave as Fishermen too. Fishermen aren't necessary for security, and aren't covered in-depth by this document.
 
 This implies a simple pipeline where collators send validators parachain blocks and their requisite PoV to check. Then, validators validate the block using the PoV, signing statements which describe either the positive or negative outcome, and with enough positive statements, the block can be noted on the relay-chain. Negative statements are not a veto but will lead to a dispute, with those on the wrong side being slashed. If another validator later detects that a validator or group of validators incorrectly signed a statement claiming a block was valid, then those validators will be _slashed_, with the checker receiving a bounty.
 

roadmap/parachains.md

@@ -20,11 +20,11 @@ This section contains various sub-projects and the features that make them up.
 
 Category: Networking
 
-Validators assigned to a parachain need a way to discover and connect to collators in order to get fresh parachain blocks to validate.
+Validators assigned to a parachain (backing group) need a way to discover and connect to collators in order to get fresh parachain blocks to validate.
 
 Collators need to discover and connect to validators in order to submit parachain blocks.
 
-Fishermen need to talk to validators and collators to fetch available data and circulate reports.
+Approval checkers need to talk to validators and collators to fetch available data and circulate reports.
 
 Some connections are long-lived, some are just for a single request.
 
@@ -74,7 +74,7 @@ For each potential, considered parachain block, perform an erasure-coding of the
 
 Category: Networking
 
-A black-box networking component for validators or fishermen on a parachain to obtain the PoV block referenced by hash in an attestation, for the purpose of validating. When fetching "current" PoV blocks (close to the head of the chain, or relating to the block currently being built), this should be fast. When fetching "old" PoV blocks, it should be possible and fall back on recovering from the availability erasure-coding.
+A black-box networking component for validators on a parachain to obtain the PoV block referenced by hash in an attestation, for the purpose of validating. When fetching "current" PoV blocks (close to the head of the chain, or relating to the block currently being built), this should be fast. When fetching "old" PoV blocks, it should be possible and fall back on recovering from the availability erasure-coding.
 
 #### *Parathread Auction Voting*
 
@@ -155,7 +155,7 @@ Runtime logic for paras to open and close channels by putting down a deposit. Th
 
 Category: Runtime
 
-In Polkadot, a bad parachain group can force inclusion of an invalid or unavailable parachain block. It is the job of fishermen to detect those blocks and report them to the runtime. This item is about the report handler
+In Polkadot, a bad parachain group can force inclusion of an invalid or unavailable parachain block. It is the job of approval checkers to detect those blocks and report them to the runtime. This item is about the report handler
 
 The W3F-research writeup on availability/validity provides a high-level view of the dispute resolution process: [Availability and Validity — Research at W3F](https://research.web3.foundation/en/latest/polkadot/Availability_and_Validity.html)
 
@@ -173,7 +173,7 @@ Runtime handlers that take two conflicting votes as arguments and slash the offe
 
 Category: Node
 
-This code-path is also taken by validators who self-select based on VRF [Availability and Validity — Research at W3F](https://research.web3.foundation/en/latest/polkadot/Availability_and_Validity.html). Validators and fishermen will select parachain blocks to re-validate. In these steps:
+This code-path is also taken by validators who self-select based on VRF [Availability and Validity — Research at W3F](https://research.web3.foundation/en/latest/polkadot/Availability_and_Validity.html). Validators will select parachain blocks to re-validate. In these steps:
 * Attempt to recover the PoV block, falling back on the erasure-coding. If not available, issue report.
 * Attempt to validate the PoV block. If invalid, issue report.