Update EIP-5247: Move to Review

Merged by EIP-Bot.

EIPS/eip-5247.md

@@ -4,7 +4,7 @@ title: Smart Contract Executable Proposal Interface
 description: An interface to create and execute proposals.
 author: Zainan Victor Zhou (@xinbenlv)
 discussions-to: https://ethereum-magicians.org/t/erc-5247-executable-proposal-standard/9938
-status: Stagnant
+status: Review
 type: Standards Track
 category: ERC
 created: 2022-07-13
@@ -19,7 +19,7 @@ function calls including the target contract address, ether value to be transmit
 
 It is oftentimes necessary to separate the code that is to be executed from the actual execution of the code.
 
-A typical use case for this EIP is in a Decentralized Autonomous Organization (DAO). A proposer will create a smart proposal and advocate for it. Members will then choose whether or not to endorse the proposal and vote accordingly (see [EIP-1202](./eip-1202.md)). Finallym when consensus has been formed, the proposal is executed.
+A typical use case for this EIP is in a Decentralized Autonomous Organization (DAO). A proposer will create a smart proposal and advocate for it. Members will then choose whether or not to endorse the proposal and vote accordingly (see `ERC-1202`). Finallym when consensus has been formed, the proposal is executed.
 
 A second typical use-case is that one could have someone who they trust, such as a delegator, trustee, or an attorney-in-fact, or any bilateral collaboration format, where a smart proposal will be first composed, discussed, approved in some way, and then put into execution.
 
@@ -65,7 +65,7 @@ interface IERC5247 {
 
 ## Rationale
 
-* Originally, this interface was part of part of [EIP-1202](./eip-1202.md). However, the proposal itself can potentially have many use cases outside of voting. It is possible that voting may not need to be upon a proposal in any particular format. Hence, we decide to *decouple the voting interface and proposal interface*.
+* Originally, this interface was part of part of `ERC-1202`. However, the proposal itself can potentially have many use cases outside of voting. It is possible that voting may not need to be upon a proposal in any particular format. Hence, we decide to *decouple the voting interface and proposal interface*.
 * Arrays were used for `target`s, `value`s, `calldata`s instead of single variables, allowing a proposal to carry arbitrarily long multiple functional calls.
 * `registeredProposalId` is returned in `createProposal` so the standard can support implementation to decide their own format of proposal id.