Merge pull request #37 from lmedury/main

Governance Content Integration

docs/articles/governance/Proposals/definitions.en.mdx

@@ -0,0 +1,107 @@
+# Definitions and Concepts
+
+## Proposal Types
+
+### On-Chain Governance
+
+On-chain governance refers to all protocol level execution of proposals using Cosmos SDK's `gov` module. Anyone who holds or stakes EVMOS can participate in these votes, regardless of the voter's validator choices. 
+
+### Off-Chain Governance
+
+Off-chain governance refers to all community decisions that do not require an on-chain protocol-level change. These types of decisions include a wide variety of topics and concepts, from passing meta-governance proposals to the formation of special task forces or workstreams. 
+
+
+:::tip
+All proposals are assumed to be `On-Chain Proposals` until the necessary infrastructure and toolings for `Off-Chain Voting` is established. Cosmos SDK's `TextProposal` will be used for `Off-Chain Proposals` for the time being.
+:::
+
+---
+
+## Proposal Types by Category
+
+### Protocol Proposals
+
+| Module         | Codebase     | Parameters                                                                        | Description     |  
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `auth`         | `cosmos-sdk` | `MaxMemoCharacters` `TxSigLimit` `TxSizeCostPerByte` `SigVerifyCostED25519` `SigVerifyCostSecp256k1` | The auth module is responsible for specifying the base transaction and account types for an application. [Ref.](https://docs.cosmos.network/v0.46/modules/auth/06_params.html) |
+| `bank`         | `cosmos-sdk` | `SendEnabled` `DefaultSendEnabled`          |The bank module is responsible for handling multi-asset coin transfers between accounts and tracking special-case pseudo-transfers which must work differently with particular kinds of accounts. [Ref.](https://docs.cosmos.network/v0.46/modules/bank/05_params.html)| 
+| `distribution` | `cosmos-sdk` | `communitytax` `baseproposerreward` `bonusproposerreward` `withdrawaddrenabled` |This simple distribution mechanism describes a functional way to passively distribute rewards between validators and delegators. [Ref.](https://docs.cosmos.network/v0.46/modules/distribution/07_params.html) | 
+| `governance`   | `cosmos-sdk` | `min_deposit` `max_deposit_period` `voting_period` `quorum` `threshold` `veto`  | The module enables Cosmos-SDK based blockchain to support an on-chain governance system. [Ref.](https://docs.cosmos.network/v0.46/modules/gov/06_params.html) | 
+
+Additional Protocol Proposals: `slashing`, `staking`, `transfer`, `feemarket`, `claims`, `inflation`
+
+---
+
+### Community Proposals
+
+Proposals that only require to be posted as a `TextProposal` on the Cosmos SDK - *Most commonly used for meta-governance proposals.*  
+
+---
+
+### Workstream & Special Initiatives
+
+Proposals that requests any type of funding from the `CommunityPool` or the DAO's treasury to form an in-house workstream (team, squad, sub-DAO, guild) or project with the direct purpose of benefiting the Evmos ecosystem. 
+
+#### **Workstreams** 
+
+Workstreams are typically DAO-funded teams with a recurring budget with no termination date (i.e., Community Outreach, Marketing & Creative Services, etc). More information on workstreams can be found on the [DAO Workstreams page.](/governance/workstreams/index)
+
+Workstreams are the sub-units of how Evmos DAO advances its purpose. A workstream is a group of people actively working on tasks that align with Evmos' Constitutional Values and community run initiatives. As such, ratifying workstreams sets boundaries on what is and isn't in scope for Evmos DAO's governance.
+
+Anyone may start a workstream and gather momentum behind it by posting on Commonwealth. Until a formal proposal for a budget is made, this workstream is considered “informal.” A workstream can be as broad or narrow as its initiators like, but workstream proposals must satisfy the following criteria:
+
+- Have a clear objective that aligns with Evmos' values and objectives as listed in the [Constitution](/constitution).
+- Distinguish itself from or explicitly state its improvements on existing workstreams.
+- Propose clear budgets and timelines for producing outcomes and all in line with the budget proposal flow.
+
+Workstreams have five potential states. Each of the five states and the requirements for a workstream in each state are outlined below:
+
+- **Informal:** The workstream is not funded by the DAO, and has not made a formal proposal with its goals and a budgetary request.
+- **Proposed:** The workstream has made a formal proposal to the DAO for a working budget.
+- **Active:** The workstream is active and funded by the DAO. 
+- **Inactive:** The workstream has been discontinued and is no longer being funded by the DAO.
+
+#### **Special Initiatives / Projects** 
+
+Special Initiatives and Projects are DAO-funded projects with a set budget and "completion" goal or date (i.e., Governance Tooling Project, Event Sponsorships, etc.)  
+
+---
+
+### Protocol Incentives + Evmos Specific Proposals
+
+| Module         | Codebase     | Parameters                                        | Description                                     |  
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `revenue`     | `evmos`      | `EnableFeeSplit` `DeveloperShares` `AddrDerivationCostCreate` |[reference](https://docs.evmos.org/modules/feesplit/07_parameters.html)     | 
+| `incentives`   | `evmos`      | `EnableIncentives` `AllocationLimit` `IncentivesEpochIdentifier` `rewardScaler`  |[reference](https://docs.evmos.org/modules/incentives/07_parameters.html)     | 
+| `erc20`        | `evmos`      | `register_coin` `register_erc20`  |[reference](https://docs.evmos.org/modules/erc20/07_parameters.html)      | 
+| `evm`        | `evmos`      | `ExtraEIPs` `ChainConfig`  |[reference](https://docs.evmos.org/modules/evm/08_params.html)      | 
+
+---
+
+### Network Upgrades & Security
+
+| Module         | Codebase     | Parameters                                        | Description                                     |  
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `crisis`       | `cosmos-sdk` | `ConstantFee` |The crisis module halts the blockchain under the circumstance that a blockchain invariant is broken. [Ref.](https://docs.cosmos.network/v0.46/modules/crisis/04_params.html)| 
+| `upgrade`       | `cosmos-sdk` | `MsgSoftwareUpgrade` | `x/upgrade` is an implementation of a Cosmos SDK module that facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version.  [Ref.](https://docs.cosmos.network/v0.46/modules/upgrade/)| 
+
+:::tip
+Emergency and Network Upgrade Proposals are exempt from following the Proposal Lifecycle Framework. The community is expected to do its due dilligence when such proposals are uploaded. 
+:::
+
+---
+
+## Proposal Phase & Identification Tags
+
+**You do not need to know the proposal phase and identification naming conventions! A Governance Council member will assist -- the content below is for reference.** 
+
+Proposal Phases are denoted as: `[IDEATION]`, `[PRE-PROPOSAL]`, `[PROPOSAL]`, `[VOTING]` for the 4-phases, and `[PASSED]`, `[REJECTED]`, `[DEFERRED]` for proposals in the other stages. Refer to the [Proposal Lifecycle](/governance/proposals/lifecycle) page for more information on proposal lifecycle phases. 
+
+
+:::tip
+Proposal Identification Tags are only required for Governance, Workstream (subDAO), and Community Treasury Related Proposals Only
+:::
+
+The `ECP-#` tag will be assigned and added by a Governance Council member in the `Phase 2: ECP Formalization` or `Phase 3: ECP Signaling` phase. **You do not have to worry about adding in the tag yourself.**
+
+These tags are for internal tracking and organization purposes. Make sure to check the [Proposal Submission Guidelines](/governance/proposals/submission) for more information on how to properly prepare your proposal for on-chain voting.

docs/articles/governance/Proposals/index.mdx

@@ -0,0 +1,22 @@
+# Proposals Framework
+
+## Evmos Community Proposals (ECPs)
+
+ECPs are standardized proposals subject to voting that (once enacted) regulate and define the behavior of the Evmos DAO's Governance system, and provides a funding mechanism for special projects and workstreams. 
+
+## The Evmos Community Proposal Framework
+
+The Evmos Community Proposal (ECP) Framework sets the guideline for all subsequent ECPs to follow. This ECP is the foundational ECP that provides the necessary templates, processes, and guidelines for working within the framework and defines the key roles required for the operation and enforcement of the ECP process.
+
+### ECP Framework Components
+
+[**1. Definitions of the ECP Framework**](/governance/proposals/definitions) - *Defines core concepts of the ECP Framework and the different types of proposals.*
+
+[**2. The ECP Lifecycle**](/governance/proposals/lifecycle) - *Defines the formal stages in the lifecycle of proposals from conception to approval, rejection, or deferral.*
+
+[**3. ECP Standards and Templates**](/governance/proposals/templates) - *Defines the processes, rules, and components required for all proposals before going to vote.*
+
+[**4. ECP Submission Guidelines**](/governance/proposals/submission) - *Defines the proposal submission procedures and guidelines for on-chain voting.*
+
+[**5. Evmos Governance Council**](/governance/workstreams/current#governance-council-wip) - *Defines the responsibilities and enforcement powers reserved to the Governance Council of Evmos DAO.*
+

docs/articles/governance/Proposals/lifecycle.en.mdx

@@ -0,0 +1,77 @@
+import ContentTimeline from '/src/components/ProposalSteps';
+
+# Proposal Lifecycle
+
+<ContentTimeline step={4} />
+
+## **Phase 1**: Discussion & Ideation
+
+The purpose of this phase is to vet ideas with the active Evmos community members. Each idea for a proposal should have its own Commonwealth thread, and discussions should be as narrowly focused as possible. Anyone can participate and is encouraged to provide feedback in this phase of governance. The goal of Phase 1 discussion is to gain a rough community consensus, and refine the idea so that it can be formalized. The thread author should make an effort to address all comments and take them into consideration.
+
+- **Minimum Duration:** 48 hours
+- **Forum Tag:** `[IDEATION]`
+
+## **Phase 2**: ECP Formalization
+
+Phase 2 is where the idea is formalized into an ECP that includes all of the criteria specified in the ECP Template. It must be a clear and complete description of the proposed enhancement. All ECPs must have the following core components, **with additional/varying sections for certain proposal types (refer to the [templates page](/governance/proposals/templates))**:
+
+:::tip
+<p style={{ fontSize: '1.2rem', marginTop: 0, fontWeight: 600 }}>Title: Short and sweet, with the [correct tags](/governance/proposals/definitions#proposal-phase--identification-tags) prefixed.</p>
+<hr />
+
+**Summary** - A brief, high-level summary of what changes are being suggested. Summary should be a single sentence, or a bulleted list.
+
+**Authors** - List of authors and contributors involved in the writing of the proposal.
+
+**Abstract** - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the motivation and specification sections. Someone should be able to read only the abstract to get the gist of what this specification does.
+
+**Motivation** - The motivation section should describe the "why" of this proposal. What problem does it solve? What benefit does it provide to the Evmos network?
+
+**Proposal Type Specific Content**
+
+Make sure to double check your proposal type to see what [additional information or details are required](/governance/proposals/templates). **Especially for funding proposals!**
+:::
+
+- **Minimum Duration:** 72 hours (3 days)
+- **Forum Tag:** `[PRE-PROPOSAL]`
+
+
+## **Phase 3**: ECP Signaling (Temperature Check)
+
+At any point during Phase 2, the author may finalize the ECP by initiating a community temperature check. To do this, the author must change the tag of the forum post to `[PROPOSAL]`, and add a forum poll to gauge the community sentiment.
+
+Proposals should only move to Phase 3 once the author has considered all community comments, responded to all concerns and questions, and believes that the proposal is ready to go on-chain for a final network-wide vote. Proposals in Phase 3 should not be edited further with the exception of minor mistakes. 
+
+**Forum Tag:** `[PROPOSAL]`
+
+
+## **Phase 4**: On-Chain Voting
+
+If the signaling polls in Phase 3 show an overall positive sentiment and no major issues are brought up, the proposal may be submitted on-chain for the formal voting. Submission guidelines [are listed here](/governance/proposals/submission).
+
+**Forum Tag (Depending on Outcome):** `[VOTING]`, `[PASSED]`, `[REJECTED]`, `[VETO]`
+
+## Proposal Lifecycle Flowchart
+
+![Proposal Lifecycle](/img/lifecycle-flowchart.png)
+
+## Other ECP Statuses
+
+- **Withdrawn:** Assigned when a member withdraws their proposal, or if the proposal is abandoned with no activity. **Forum Tag:** `[WITHDRAWN]`
+- **Deferred:** Assigned when a proposal has been deemed as not ready or not a priority but can be re-proposed at a later date. This status can be assigned during Phase 3 with a failed forum poll or signaling. **Forum Tag:** `[DEFER]`
+
+## Governance Council & Core Devs
+
+**Governance Council** 
+
+The Evmos DAO Governance Council may "fast-track" a proposal onto on-chain voting for time-sensitive and urgent matters. The Council must provide the community a post-mortem on why the Council deemed it was necessary to forego the Proposal Lifecycle. If the community deems that the decision was made in bad faith, the Community is encouraged to engage in discussions and hold the responsible parties responsible through disciplinary actions or even the removal of Council members through an on-chain vote.
+
+**Core Developers**
+
+Core developers are not bound to the ECP Framework for network and protocol related proposals. It is expected, however, that thorough testing and due diligence is performed by the developers for all network upgrades. It should be noted, however, that network upgrades must still go through the process of on-chain voting.
+
+## Assistance & Review
+
+All proposers are welcome to approach the Governance Workstream for assistance in any part of the Proposal Lifecycle. In addition, proposers may request a formal review of the proposal before going on chain.
+
+