Fix typos across documentation

contracts/core/Allo.md

@@ -220,7 +220,7 @@ sequenceDiagram
 * **Strategy** Smart contracts implementing fund allocation and distribution logic for each pool. Strategies can be custom or cloneable and determine how funds are managed within a pool.
 
 
-In summary, the "Allo" smart contract provides a framework for creating and managing pools with customizable fund allocation and distribution strategies. It leverages access controls, mappings, and functions to enable various actions within the protocol. The contract is designed to support a  ecosystem, enhancing the efficiency and transparency of fund management in Ethereum-based applications.
+In summary, the "Allo" smart contract provides a framework for creating and managing pools with customizable fund allocation and distribution strategies. It leverages access controls, mappings, and functions to enable various actions within the protocol. The contract is designed to support an ecosystem, enhancing the efficiency and transparency of fund management in Ethereum-based applications.
 
 ## User Flows
 
@@ -304,4 +304,4 @@ In summary, the "Allo" smart contract provides a framework for creating and mana
 ### Distribute Funds to Recipients
 
  * Users can distribute funds to recipients using a pool's distribution strategy by calling the `distribute` function.
- * The function requires the `_poolId`, `_recipientIds`, and `_data` as parameters, and it passes the data to the strategy for distribution.
+ * The function requires the `_poolId`, `_recipientIds`, and `_data` as parameters, and it passes the data to the strategy for distribution.

contracts/core/interfaces/IStrategy.sol

@@ -93,7 +93,7 @@ interface IStrategy {
     /// @return The ID of the strategy
     function getStrategyId() external view returns (bytes32);
 
-    /// @notice Checks whether a allocator is valid or not, will usually be true for all strategies
+    /// @notice Checks whether an allocator is valid or not, will usually be true for all strategies
     ///      and will depend on the strategy implementation.
     /// @param _allocator The allocator to check
     /// @return Whether the allocator is valid or not

contracts/strategies/SpecTemplate.md

@@ -25,7 +25,7 @@ Explain the logic for determining how recipients are added to the strategy's poo
     - What criteria determine the eligibility of a recipient to register in this strategy? Are there any specific requirements or conditions?
     - Are there any additional custom functions or conditions for verifying recipient eligibility?
 - **Recipient information**
-    - How does a recipient identify themselves? Is it through an address like msg.sender, do they need an profile registered at the `Registry` contract, or another mechanism? 
+    - How does a recipient identify themselves? Is it through an address like msg.sender, do they need a profile registered at the `Registry` contract, or another mechanism? 
         - If through the Registry, can the pool creator set a custom registry?
         - Which address is returned by `registerRecipient` and represents the `recipientId`?
         - Can the address that receives the funds be different from the recipient's profile?

contracts/strategies/_poc/donation-voting-custom-registry/Spec.md

@@ -31,7 +31,7 @@ In this strategy, recipients must submit an application and be approved by pool
   - prospective recipients must provide the projects address as `recipientId`, which serves as the unique identifier for their registration
 - **Recipient eligibility**
   - Pool manager has the option to enable two separate eligibility requirements on this contract:
-    - Requiring recipients to have an registry profile in order to apply
+    - Requiring recipients to have a registry profile in order to apply
     - Requiring recipients to submit answers to questions, stored in metadata
       - This metadata may include information for the front end on required / optional questions, but the contract only needs to check for whether metadata has been submitted
       - The pool manager should have a function that enables them to edit the pool metadata, which is callable at any point

contracts/strategies/_poc/micro-grants/README.md

@@ -186,7 +186,7 @@ Only in `MicroGrantsStrategy.sol`:
 
 ### Allocating to a Recipient 
 
-* Valid Allocator initiates a allocation request
+* Valid Allocator initiates an allocation request
 * An allocator can vote only once for a recipientId
 * An allocator can choose to: accept/reject a recipient
     * If the allocator accepts the recipient, we check to see if the recipient has approvals which are equal to the approvalThreshold, then the funds are distributed to the recipient
@@ -197,4 +197,4 @@ Only in `MicroGrantsStrategy.sol`:
 * Verifies if sender is authorized to withdraw funds.
 * Checks if the pool is inactive.
 * Decreases the pool amount by the requested withdrawal amount.
-* Transfers the requested amount to the sender.
+* Transfers the requested amount to the sender.

contracts/strategies/_poc/qv-hackathon/Spec.md

@@ -16,7 +16,7 @@ In this strategy, recipients do not need to apply — they are automatically add
         - update metadata for this pool
 
 ### Allocation logic
-In this strategy, only wallets that hold a specific NFT are eligible to allocate. Allocations can only be submitted during a allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. 
+In this strategy, only wallets that hold a specific NFT are eligible to allocate. Allocations can only be submitted during an allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. 
 - **Allocator Eligibility**
     - Wallets are only eligible if they hold a specific NFT.
         - Pool managers must have the ability to configure which NFT is required in order to vote. 

contracts/strategies/_poc/qv-nft-tiered/Spec.md

@@ -32,7 +32,7 @@ In this strategy, recipients must submit an application and be approved by pool
         - If a recipient's current status is `Accepted`, then their application info is updated and their status is changed to `Pending` (global and local)
 
 ### Allocation logic
-In this strategy, pool managers are able to set multiple NFTs as their eligibility gates for allocators. As long as a wallet holds at least one of those NFTs they are marked as `eligible`. Allocations can only be cast during a allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The budget of voice credits is dictated by the NFT(s) that the allocator holds. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. 
+In this strategy, pool managers are able to set multiple NFTs as their eligibility gates for allocators. As long as a wallet holds at least one of those NFTs they are marked as `eligible`. Allocations can only be cast during an allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The budget of voice credits is dictated by the NFT(s) that the allocator holds. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. 
 - **Allocator Eligibility**
     - Pool managers need a function to indicate which NFTs will be used to determine eligibility in the pool.
         - As part of this, they need to be able to indicate how many voice credits each NFT is worth. For example, a wallet holding `NFT-A` may get 100 credits, while a wallet holding `NFT-B` may get 250 credits. 

test/utils/MockStrategy.sol

@@ -80,7 +80,7 @@ contract MockStrategy is BaseStrategy {
         return PayoutSummary(_recipientId, 0);
     }
 
-    // simply returns whether a allocator is valid or not, will usually be true for all
+    // simply returns whether an allocator is valid or not, will usually be true for all
     function _isValidAllocator(address _allocator) internal view override returns (bool) {
         surpressStateMutabilityWarning;
         return _allocator == address(0) ? false : true;