tip and styles updates

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

@@ -1,4 +1,4 @@
-# Core Definitions and Concepts
+# Definitions and Concepts
 
 ## Proposal Types
 
@@ -11,9 +11,9 @@ On-chain governance refers to all protocol level execution of proposals using Co
 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. 
 
 
-<Callout type="warning" emoji="⚠️">
+:::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.
-</Callout>
+:::
 
 ---
 
@@ -85,9 +85,9 @@ Special Initiatives and Projects are DAO-funded projects with a set budget and "
 | `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/)| 
 
-<Callout type="warning" emoji="⚠️">
+:::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. 
-</Callout>
+:::
 
 ---
 
@@ -98,9 +98,9 @@ Emergency and Network Upgrade Proposals are exempt from following the Proposal L
 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. 
 
 
-<Callout type="warning" emoji="⚠️">
+:::tip
 Proposal Identification Tags are only required for Governance, Workstream (subDAO), and Community Treasury Related Proposals Only
-</Callout>
+:::
 
 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.**
 

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

@@ -1,4 +1,8 @@
-# The Evmos Community Proposal Lifecycle
+import ContentTimeline from '/src/components/ProposalSteps';
+
+# Proposal Lifecycle
+
+<ContentTimeline step={4} />
 
 ## **Phase 1**: Discussion & Ideation
 
@@ -11,6 +15,7 @@ The purpose of this phase is to vet ideas with the active Evmos community member
 
 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 />
 
@@ -25,7 +30,7 @@ Phase 2 is where the idea is formalized into an ECP that includes all of the cri
 **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]`

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

@@ -1,6 +1,4 @@
-
-
-# Proposal Submission for Voting
+# Submission Guidelines
 
 ## Preparing the Proposal Payload
 
@@ -50,12 +48,13 @@ At the end of the on-chain proposal, provide the IPFS hash or IPNS link to the p
 ### Community Pool
 
 For community pool spend proposals, there are five components:
-
-1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals
-2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal
-3. **Recipient** - the Evmos (bech32-based) address that will receive funding from the Community Pool
-4. **Amount** - the amount of funding that the recipient will receive in atto-EVMOS (`aevmos`)
-5. **Deposit** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal
+<ol>
+  <li>1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals</li>
+  <li>2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal</li>
+  <li>3. **Recipient** - the Evmos (bech32-based) address that will receive funding from the Community Pool</li>
+  <li>4. **Amount** - the amount of funding that the recipient will receive in atto-EVMOS (`aevmos`)</li>
+  <li>5. **Deposit** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal</li>
+</ol>
 
 **Community Pool Spend Payloads**
 
@@ -92,13 +91,15 @@ Changes to the `gov` module are different from the other kinds of parameter chan
 
 For parameter-change proposals, there are seven components:
 
-1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals
-2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal
-3. **Subspace** - the Evmos module with the parameter that is being changed
-4. **Key** - the parameter that will be changed
-5. **Value** - the value of the parameter that will be changed by the governance mechanism
-6. **Denom** - `aevmos` (atto-EVMOS) will be the type of asset used as the deposit
-7. **Amount** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal
+<ol>
+  <li>1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals</li>
+  <li>2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal</li>
+  <li>3. **Subspace** - the Evmos module with the parameter that is being changed</li>
+  <li>4. **Key** - the parameter that will be changed</li>
+  <li>5. **Value** - the value of the parameter that will be changed by the governance mechanism</li>
+  <li>6. **Denom** - `aevmos` (atto-EVMOS) will be the type of asset used as the deposit</li>
+  <li>7. **Amount** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal</li>
+</ol>
 
 **ParamChange Proposal Example**
 
@@ -133,27 +134,30 @@ The deposit `denom` is `aevmos` and `amount` is `20100000000000000000`. Therefor
 
 For information on how to use `evmosd` binary to submit an on-chain proposal through the governance module.
 
-1. `evmosd` is the command-line interface client that is used to send transactions and query Evmos
-2. `tx gov submit-proposal param-change` indicates that the transaction is submitting a parameter-change proposal
-3. `--from mykey` is the account key that pays the transaction fee and deposit amount
-4. `--gas 500000` is the maximum amount of gas permitted to be used to process the transaction
+<ol>
+  <li>1. `evmosd` is the command-line interface client that is used to send transactions and query Evmos</li>
+  <li>2. `tx gov submit-proposal param-change` indicates that the transaction is submitting a parameter-change proposal</li>
+  <li>3. `--from mykey` is the account key that pays the transaction fee and deposit amount</li>
+  <li>4. `--gas 500000` is the maximum amount of gas permitted to be used to process the transaction
    - the more content there is in the description of your proposal, the more gas your transaction will consume
    - if this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail
-   - the transaction will only use the amount of gas needed to process the transaction
-5. `--gas-prices` is the flat-rate per unit of gas value for a validator to process your transaction
-6. `--chain-id evmos_9001-2` is Evmos Mainnet. 
-   - the testnet chain ID is `evmos_9000-4`. For current and past testnet information, please look at the [testnet repository](https://github.com/evmos/testnets)
-7. `--node` is using a full node to send the transaction to the Evmos Mainnet
-
+   - the transaction will only use the amount of gas needed to process the transaction</li>
+  <li>5. `--gas-prices` is the flat-rate per unit of gas value for a validator to process your transaction</li>
+  <li>6. `--chain-id evmos_9001-2` is Evmos Mainnet. 
+   - the testnet chain ID is `evmos_9000-4`. For current and past testnet information, please look at the [testnet repository](https://github.com/evmos/testnets)</li>
+  <li>7. `--node` is using a full node to send the transaction to the Evmos Mainnet</li>
+</ol>
 
 ### Testnet Submission
 
 You may want to submit your proposal to the testnet chain before the mainnet for a number of reasons:
 
-1. To see what the proposal description will look like
-2. To signal that your proposal is about to go live on the mainnet
-3. To share what the proposal will look like in advance with stakeholders
-4. To test the functionality of the governance features
+<ol>
+<li>1. To see what the proposal description will look like</li>
+<li>2. To signal that your proposal is about to go live on the mainnet</li>
+<li>3. To share what the proposal will look like in advance with stakeholders</li>
+<li>4. To test the functionality of the governance features</li>
+</ol>
 
 Submitting your proposal to the testnet increases the likelihood that you will discover a flaw before deploying your proposal on mainnet. A few things to keep in mind:
 

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

@@ -1,13 +1,11 @@
-
-# Standardized Proposal Templates
+# Formatting & Templates
 
 The Evmos Governance Framework allows for various different types of proposals, both on-chain and off-chain. This section serves as a basic guide for the necessary components of proposals. Depending on the proposal type, certain components may be required. Use this table as a reference sheet for which of the following components are required for your type. 
 
 ## A. Universal Components
 
 All proposals must include the following **Proposal Components**. 
 
-
 <p style={{ fontSize: '0.9rem'}}>**Title** - Short and sweet, with the [correct tags](/governance/proposals/definitions#proposal-phase--identification-tags) prefixed.</p>
 
 <p style={{ fontSize: '0.9rem'}}>**Author(s)** - List of authors and contributors involved in the writing of the proposal.</p>
@@ -133,4 +131,4 @@ What amount is required for the workstream to achieve the initial target, and ho
 
 ## F. Protocol (ParamChange) Proposals
 
-Refer to the [official Evmos documentation](https://docs.evmos.org/users/governance/param_change.html) for protocol and `ParamChange` proposals.
+Refer to the [official Evmos documentation](https://docs.evmos.org/users/governance/param_change.html) for protocol and `ParamChange` proposals.

docs/articles/governance/Workstreams/index.mdx

@@ -1,4 +1,4 @@
-# DAO Workstreams (aka Sub-DAOs, Teams)
+# Sub-DAO Workstreams
 
 ## Definition and Purpose
 
@@ -10,11 +10,13 @@ Workstreams are the sub-units of how Evmos DAO advances its purpose. A workstrea
 
 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.
-- The specific KPI that the sub-DAO will focus on driving success in
-- The actual work that the sub-DAO will undertake to drive toward the KPI
-- Propose clear budgets and timelines for producing outcomes and all in line with the budget proposal flow.
+<ul>
+    <li>Have a clear objective that aligns with Evmos' values and objectives as listed in the [Constitution](/constitution).</li>
+    <li>Distinguish itself from or explicitly state its improvements on existing workstreams.</li>
+    <li>The specific KPI that the sub-DAO will focus on driving success in</li>
+    <li>The actual work that the sub-DAO will undertake to drive toward the KPI</li>
+    <li>Propose clear budgets and timelines for producing outcomes and all in line with the budget proposal flow.</li>
+</ul>
 
 ## Workstream Formation Process
 
@@ -28,7 +30,9 @@ A great way to build trust within the community is to operate informally first.
 
 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.
+<ul>
+    <li>**Informal:** The workstream is not funded by the DAO, and has not made a formal proposal with its goals and a budgetary request.</li>
+    <li>**Proposed:** The workstream has made a formal proposal to the DAO for a working budget.</li>
+    <li>**Active:** The workstream is active and funded by the DAO. </li>
+    <li>**Inactive:** The workstream has been discontinued and is no longer being funded by the DAO.</li>
+</ul>

docs/articles/governance/index.md

@@ -16,16 +16,14 @@ While the governance module in Cosmos SDK is sufficient for on-chain governance,
 
 # Governance Overview
 
-:::tip
-**Note:** Working on a governance proposal? Make sure to look at the [best practices](./best-practices).
-:::
-
 Evmos has an on-chain governance mechanism for passing
 text proposals, changing [chain parameters](./chain-parameters),
 and spending [funds from the community pool](./community-pool).
 
 ## On- and off-chain Governance Structure
-
+:::tip
+**Note:** Working on a governance proposal? Make sure to look at the [best practices](./best-practices).
+:::
 ### Communication Methods
 
 Governance practices and decisions are communicated through different types of documents and design artifacts:
@@ -53,8 +51,4 @@ involvement from members in the extended community occurs organically.
 - **[Telegram (@EvmosOrg)](https://t.me/EvmosOrg)**
     - General Evmos Telegram group
 - **[Twitter (@EvmosOrg)](https://twitter.com/EvmosOrg)**
-    - Official Evmos Twitter
-
-## Future Plans
-
-WIP
+    - Official Evmos Twitter

docs/articles/governance/voting.md

@@ -1,5 +1,4 @@
-# Governance Voting
-
+# Voting and Delegations
 
 ## Voting Period
 
@@ -18,12 +17,14 @@ Voting `NoWithVeto` provides a mechanism for a minority group representing a *th
 
 There are four criteria:
 
-1. A minimum deposit of 192 EVMOS is required for the proposal to enter the voting period
+<ol>
+   <li>1. A minimum deposit of 192 EVMOS is required for the proposal to enter the voting period
    - anyone may contribute to this deposit
-   - the deposit must be reached within 3 days (this is the deposit period)
-2. A minimum of 33.4% 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 5-day voting period
-4. Less than 33.4% of participating voting power votes `NoWithVeto`
+   - the deposit must be reached within 3 days (this is the deposit period)</li>
+   <li>2. A minimum of 33.4% of the network's voting power (quorum) is required to participate to make the proposal valid</li>
+   <li>3. A simple majority (greater than 50%) of the participating voting power must back the `Yes` vote during the 5-day voting period</li>
+   <li>4. Less than 33.4% of participating voting power votes `NoWithVeto`</li>
+</ol>
 
 Currently, the criteria for submitting and passing/failing all proposal types is the same.