updated governance docs (#698)

* updated governance docs

* fixing lint checks, added snapshot

docs/validators/governance/best_practices.md

@@ -4,7 +4,7 @@ order: 3
 
 # Best Practices
 
-## Community Outreach
+## General Advice: Community Outreach
 
 Engagement is likely to be critical to the success of a proposal. The degree to which you engage with Evmos community should be relative to the potential impact that your proposal may have on the stakeholders. This guide does not cover all ways of engaging: you could bring your idea to a podcast or a hackathon, host an AMA on [Reddit](https://www.reddit.com/r/evmos) or host a Q&A (questions & answers). We encourage you to experiment and use your strengths to introduce proposal ideas and gather feedback.
 
@@ -23,10 +23,12 @@ You should be able engaging with key stakeholders (eg. a large validator operato
 **Why a large validator?** They tend to be the de facto decision-makers on Evmos, since their delegators also delegate their voting power. If you can establish a base layer of off-chain support, you can be more confident that it's worth proceeding to the next stage.
 
 ::: tip
-**Note:** many will likely hesitate to commit support, and that's okay. It will be important to reassure these stakeholders that this isn't a binding a commitment. You're just canvasing the community to get a feel for whether it's worthwhile to proceed. It's also an opportunity to connect with new people and to answer their questions about what it is you're working on. It will be important for them to clearly understand why you think what you're proposing will be valuable to Evmos, and if possible, why it will be valuable to them as long-term stakeholders.
+**Note:** many will likely hesitate to commit support, and that's okay. It will be important to reassure these stakeholders that this isn't a binding a commitment. You're just canvassing the community to get a feel for whether it's worthwhile to proceed. It's also an opportunity to connect with new people and to answer their questions about what it is you're working on. It will be important for them to clearly understand why you think what you're proposing will be valuable to Evmos, and if possible, why it will be valuable to them as long-term stakeholders.
 :::
 
-If you're already confident about your idea, [skip to Stage 2](#stage-2-your-draft-proposal).
+- If you're just developing your idea, [start at Stage 1](#stage-1-your-idea).
+- If you're already confident about your idea, [skip to Stage 2](#stage-2-your-draft-proposal).
+- If you've drafted your proposal, engaged with the community, and submitted your proposal to the testnet, [skip to Stage 3](#stage-3-your-on-chain-proposal).
 
 ## Stage 1: Your Idea
 
@@ -54,17 +56,17 @@ The next major section outlines and describes some potential elements of draftin
 
 It will be important to balance two things: being detailed and being concise. You'll want to be concise so that people can assess your proposal quickly. You'll want to be detailed so that voters will have a clear, meaningful understanding of what the changes are and how they are likely to be impacted.
 
-Each proposal should contain a summary with key details:
+Every proposal should contain a summary with key details:
 
 - who is submitting the proposal
 - the amount of the proposal or parameter(s) being changed;
 - and deliverables and timeline
 - a reason for the proposal and potential impacts
 - a short summary of the history (what compelled this proposal), solution that's being presented, and future expectations
 
-Assume that many people will stop reading at this point. However it is important to provide in-depth information, a few more pointers for Parameter-change and Community Spend proposals are below.
+Assume that many people will stop reading at this point. However, it is important to provide in-depth information, so a few more pointers for Parameter-Change, Community Spend, and ERC-20 Module proposals are below.
 
-#### Parameter-Change
+#### Parameter-Change Proposal
 
 1. Problem/Value - generally the problem or value that's motivating the parameter change(s)
 2. Solution - generally how changing the parameter(s) will address the problem or improve the network
@@ -73,7 +75,7 @@ Assume that many people will stop reading at this point. However it is important
 3. Risks & Benefits - clearly describe how making this/these change(s) may expose stakeholders to new benefits and/or risks
 4. Supplementary materials - optional materials eg. models, graphs, tables, research, signed petition, etc
 
-#### Community-Spend Proposal
+#### Community Spend Proposal
 
 1. Applicant(s) - the profile of the person(s)/entity making the proposal
    - who you are and your involvement in Cosmos and/or other blockchain networks
@@ -82,7 +84,8 @@ Assume that many people will stop reading at this point. However it is important
    - past work you've done eg. include your Github
    - some sort of proof of who you are eg. Keybase
 2. Problem - generally what you're solving and/or opportunity you're addressing
-   - past, present (and possibly a prediction of the future without this work being done)
+   - provide relevant information about both past and present issues created by this problem
+   - give suggestions as to the state of the future if this work is not completed
 3. Solution - generally how you're proposing to deliver the solution
    - your plan to fix the problem or deliver value
    - the beneficiaries of this plan (ie. who will your plan impact and how?)
@@ -108,12 +111,39 @@ Assume that many people will stop reading at this point. However it is important
      - how can the community provide feedback?
    - how should the quality of deliverables be assessed? eg. metrics
 5. Relationships and disclosures
-   - have you received or applied for grants or funding? for similar work? eg. from the Evmos Foundation
+   - have you received or applied for grants or funding? for similar work? eg. from the [Evmos Grants Program](https://medium.com/evmos/announcing-evmos-grants-78aa28562db6)
    - how will you and/or your organization benefit?
    - do you see this work continuing in the future and is there a plan?
    - what are the risks involved with this work?
    - do you have conflicts of interest to declare?
 
+#### ERC-20 Proposal
+
+1. Applicant(s) - the profile of the person(s)/entity making the proposal
+   - who you are and your involvement in Cosmos and/or other blockchain networks
+   - an overview of team members involved and their relevant experience
+   - brief mission statement for your organization/business (if applicable) eg. website
+   - past work you've done eg. include your Github
+   - some sort of proof of who you are eg. Keybase
+2. Background information - promote understanding of the ERC-20 Module
+   - a mention of the original [blog post](https://medium.com/evmos/introducing-evmos-erc20-module-f40a61e05273) that introduced the ERC-20 Module
+   - a brief explanation of what the ERC-20 Module does
+   - a mention of the [ERC-20 Module documentation](../../modules/erc20)
+3. Solution - generally how ERC-20 Module changes will be made
+   - a brief explanation of what the proposal will do if it passes
+   - a brief explanation of the precautions taken, how it was tested, and who was consulted prior to making the proposal
+   - a breakdown of the proposal's payload, and third-party review
+   - a brief explanation of the risks involved (depending on the direction of IBC Coin, ERC-20)
+   - if this is a `RegisterERC20` proposal, then also ensure the following are both adhered to and documented:
+      - the contracts are verified (either through the [EVM explorer](https://evm.evmos.org) or via [Sourcify](https://sourcify.dev))
+      - the contracts are deployed open-source
+      - the contracts do not extend the `IERC20.sol` interface through a malicious implementation
+      - the contracts use the main libraries for ERC-20s (eg. OpenZeppelin, dapp.tools)
+      - the transfer logic is not modified (i.e. transfer logic is not directly manipulated)
+      - no malicious `Approve` events can directly manipulate users' balance through a delayed granted allowance
+
+Remember to provide links to the relevant [Commonwealth Evmos community](https://commonwealth.im/evmos) discussions concerning your proposal, as well as the [proposal on testnet](#submit-your-proposal-to-the-testnet).
+
 ### Begin with a well-considered draft proposal
 
 The ideal format for a proposal is as a Markdown file (ie. `.md`) in a Github repo or [HackMd](https://hackmd.io/). Markdown
@@ -124,7 +154,7 @@ writing markdown files.
 
 ### Engage the community with your draft proposal
 
-1. Post a discussion in the Commonwealth [Evmos community](https://commonwealth.im/evmos). Ideally this should contain a link to this repository, either directly to your proposal if it has been merged, or else to a pull-request containing your proposal if it has not been merged yet.
+1. Post a discussion in the [Commonwealth Evmos community](https://commonwealth.im/evmos). Ideally this should contain a link to this repository, either directly to your proposal if it has been merged, or else to a pull-request containing your proposal if it has not been merged yet.
 2. Directly engage key members of the community for feedback. These could be large contributors, those likely to be most impacted by the proposal, and entities with high stake-backing (eg. high-ranked validators; large stakers).
 3. Target members of the community in a semi-public way before bringing the draft to a full public audience. The burden of public scrutiny in a semi-anonymized environment (eg. Twitter) can be stressful and overwhelming without establishing support. Solicit opinions in places with people who have established reputations first.
 

docs/validators/governance/community_pool.md

@@ -4,17 +4,16 @@ order: 5
 
 # Community Pool
 
-Evmos token-holders can cast a vote to approve spending from the Community Pool to fund development and projects in the
-Evmos ecosystem.
+Evmos token-holders can cast a vote to approve spending from the Community Pool to fund development and projects in the Evmos ecosystem.
 
 ## Why create a proposal to use Community Pool funds?
 
-There are other funding options, most notably the Evmos Foundation's grant program. Why create a community-spend proposal?
+There are other funding options, most notably the [Evmos Grants Program](https://medium.com/evmos/announcing-evmos-grants-78aa28562db6). Why create a community-spend proposal?
 
-- **As a strategy: you can do both.** You can submit your proposal to the Interchain Foundation, but also consider submitting your proposal publicly on-chain. If the Evmos community votes in favour, you can withdraw your application.
+- **As a strategy: you can do both.** You can submit your proposal to the Evmos Grants Program, but also consider submitting your proposal publicly on-chain. If the Evmos community votes in favor, you can withdraw your application.
 - **As a strategy: funding is fast.** Besides the time it takes to push your proposal on-chain, the only other limiting factor is a fixed 5-day voting period. As soon as the proposal passes, your account will be credited the full amount of your proposal request.
 - **To build rapport.** Engaging publicly with the community is the opportunity to develop relationships with stakeholders and to educate them about the importance of your work. Unforeseen partnerships could arise, and overall the community may value your work more if they are involved as stakeholders.
-- **To be more independent.** The Evmos Foundation may not always be able to fund work. Having a more consistently funded source and having a report with its stakeholders means you can use your rapport to have confidence in your ability to secure funding without having to be dependent upon the foundation alone.
+- **To be more independent.** The [Evmos Grants Program](https://medium.com/evmos/announcing-evmos-grants-78aa28562db6) may not always be able to fund work. Having a more consistently funded source and having a report with its stakeholders means you can use your rapport to have confidence in your ability to secure funding without having to be dependent upon the foundation alone.
 
 ## FAQ
 

docs/validators/governance/overview.md

@@ -5,12 +5,16 @@ title: "Overview"
 
 # Governance Overview
 
-The Evmos has an on-chain governance mechanism for passing
+::: tip
+**Note:** Working on a governance proposal? Make sure to look at the [best practices](./best_practices.md)
+:::
+
+Evmos has an on-chain governance mechanism for passing
 text proposals, changing [chain parameters](./param_change.md), and spending [funds from the community pool](./community_pool.md).
 
 ## On- and off-chain Governance Structure
 
-### Communication
+### Communication Methods
 
 Governance practices and decisions are communicated through different types of documents and design artifacts:
 

docs/validators/governance/param_change.md

@@ -4,7 +4,9 @@ order: 6
 
 # Chain Parameters
 
-The criteria for submitting a parameter-change proposal and the subsequent voting conditions are the same as those for signalling (text-based) proposals and community-spend proposals.
+::: tip
+**Note:** If users are attempting to write governance proposals concerned with changing parameters (such as those of type `ParameterChangeProposal`), refer to [this document](../../validators/governance/best_practices.md#parameter-change-proposal).
+:::
 
 If a parameter-change proposal is successful, the change takes effect immediately upon completion of the voting period.
 

docs/validators/governance/process.md

@@ -19,7 +19,7 @@ In the past, different people have considered contributions amounts differently.
 Deposits are burned when proposals:
 
 1. **Expire** - deposits will be burned if the deposit period ends before reaching the minimum deposit (64 EVMOS)
-2. **Fail** to reach quorum - deposits will be burned for proposals that do not reach quorum ie. 40% of all staked EVMOS must vote
+2. **Fail to reach quorum** - deposits will be burned for proposals that do not reach quorum ie. 40% of all staked EVMOS must vote
 3. **Are vetoed** - deposits for proposals with 33.4% of voting power backing the `NoWithVeto` option are also burned
 
 ## Voting Period
@@ -28,14 +28,14 @@ The voting period is currently a fixed 5-day period. During the voting period, p
 
 ## What do the voting options mean?
 
-1. **Abstain:** indicates that the voter is impartial to the outcome of the proposal.
-2. **Yes:** indicates approval of the proposal in its current form.
-3. **No:** indicates disapproval of the proposal in its current form.
-4. **NoWithVeto:** indicates stronger opposition to the proposal than simply voting 'No'. If the number of 'NoWithVeto' votes is greater than a third of total votes excluding 'Abstain' votes, the proposal is rejected and the deposits are [burned](#burned-deposits).
+1. **`Abstain`**: indicates that the voter is impartial to the outcome of the proposal.
+2. **`Yes`**: indicates approval of the proposal in its current form.
+3. **`No`**: indicates disapproval of the proposal in its current form.
+4. **`NoWithVeto`**: indicates stronger opposition to the proposal than simply voting `No`. If the number of `NoWithVeto` votes is greater than a third of total votes excluding `Abstain` votes, the proposal is rejected and the deposits are [burned](#burned-deposits).
 
-As accepted by the community in [Proposal 6](https://ipfs.io/ipfs/QmRtR7qkeaZCpCzHDwHgJeJAZdTrbmHLxFDYXhw7RoF1pp), voters are expected to vote `NoWithVeto` if a proposal leads to undesirable outcomes for the community. It states “if a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos community, voters should vote *NoWithVeto*.”
+As accepted by the community in [Proposal 6](https://ipfs.io/ipfs/QmRtR7qkeaZCpCzHDwHgJeJAZdTrbmHLxFDYXhw7RoF1pp), voters are expected to vote `NoWithVeto` if a proposal leads to undesirable outcomes for the community. It states “if a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos community, voters should vote `NoWithVeto`.”
 
-Voting 'NoWithVeto' provides a mechanism for a minority group representing a *third* of the participating voting power to reject a proposal that would otherwise pass. This makes explicit an aspect of the consensus protocol: it works as long as only up to [a third of nodes fail](https://docs.tendermint.com/v0.35/introduction/what-is-tendermint.html). In other words, greater than a third of validators are always in a position to cause a proposal to fail outside the formalized governance process and the network's norms, such as by censoring transactions. The purpose of internalizing this aspect of the consensus protocol into the governance process is to discourage validators from relying on collusion and censorship tactics to influence voting outcomes.
+Voting `NoWithVeto` provides a mechanism for a minority group representing a *third* of the participating voting power to reject a proposal that would otherwise pass. This makes explicit an aspect of the consensus protocol: it works as long as only up to [a third of nodes fail](https://docs.tendermint.com/v0.35/introduction/what-is-tendermint.html). In other words, greater than a third of validators are always in a position to cause a proposal to fail outside the formalized governance process and the network's norms, such as by censoring transactions. The purpose of internalizing this aspect of the consensus protocol into the governance process is to discourage validators from relying on collusion and censorship tactics to influence voting outcomes.
 
 ## What determines whether or not a governance proposal passes?
 
@@ -45,8 +45,8 @@ There are four criteria:
    - anyone may contribute to this deposit
    - the deposit must be reached within 14 days (this is the deposit period)
 2. A minimum of 40% of the network's voting power (quorum) is required to participate to make the proposal valid
-3. A simple majority (greater than 50%) of the participating voting power must back the 'Yes' vote during the 14-day voting period
-4. Less than 33.4% of participating voting power votes `'NoWithVeto'`
+3. A simple majority (greater than 50%) of the participating voting power must back the `Yes` vote during the 14-day voting period
+4. Less than 33.4% of participating voting power votes `NoWithVeto`
 
 Currently, the criteria for submitting and passing/failing all proposal types is the same.
 
@@ -56,7 +56,7 @@ Voting power is determined by stake weight at the end of the 14-day voting perio
 
 Inactive validators can cast a vote, but their voting power (including the backing of their delegators) will not count toward the vote if they are not in the active set when the voting period ends. That means that if I delegate to a validator that is either jailed, tombstoned, or ranked lower than 125 in stake-backing at the time that the voting period ends, my stake-weight will not count in the vote.
 
-Though a simple majority 'Yes' vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass, a 'NoWithVeto' vote of 33.4% of participating voting power or greater can override this outcome and cause the proposal to fail. This enables a minority group representing greater than 1/3 of voting power to fail a proposal that would otherwise pass.
+Though a simple majority `Yes` vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass, a `NoWithVeto` vote of 33.4% of participating voting power or greater can override this outcome and cause the proposal to fail. This enables a minority group representing greater than 1/3 of voting power to fail a proposal that would otherwise pass.
 
 ### How is quorum determined?