Apply suggestions from code review

Co-authored-by: SwayStar123 <46050679+SwayStar123@users.noreply.github.com>

SRCs/src-14.md

@@ -13,8 +13,8 @@ We seek to standardize proxy implementation to improve developer experience and
 [This OpenZeppelin blog post](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades#proxies-and-implementations) is a good survey of the state of the art at this time.
 
 Proxy designs fall into three essential categories:
-1. immutable proxies which are lightweight clones of other contracts but can't change targets
-2. upgradable proxies such as [UUPS](https://eips.ethereum.org/EIPS/eip-1822) which store a target in storage and delegate all calls to it
+1. Immutable proxies which are lightweight clones of other contracts but can't change targets
+2. Upgradable proxies such as [UUPS](https://eips.ethereum.org/EIPS/eip-1822) which store a target in storage and delegate all calls to it
 3. [Diamonds](https://eips.ethereum.org/EIPS/eip-2535) which are both upgradable and can point to multiple targets on a per method basis
 
 This document falls in the second category. We want to standardize the implementation of simple upgradable passthrough contracts.
@@ -44,7 +44,7 @@ This method SHOULD implement access controls such that the target can only be ch
 
 ## Rationale
 
-This standard is meant to provide simple upgradability, it deliberately is minimalistic and does not provide the level of functionality of diamonds.
+This standard is meant to provide simple upgradability, it is deliberately minimalistic and does not provide the level of functionality of diamonds.
 
 Unlike in UUPS, this standard requires that the upgrade function is part of the proxy and not its target.
 This prevents irrecoverable updates if a proxy is made to point to another proxy and no longer has access to upgrade logic.