Worked on more pages, removed blog, and updated root path.

docs/configuration/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Configuration",
+  "position": 4
+}

docs/configuration/proposal-submission.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 2
+---
+
+# Proposal submission
+
+Proposal submission parameters are initially set when you create a DAO. Of
+course you can always modify them later with a [governance
+proposal](/definitions/proposals) containing the `Update Proposal Submission
+Config` action from the `DAO Governance` category.
+
+If you have multiple choice proposals enabled, you will instead see two
+different actions, one labeled `Update Single Choice Proposal Submission Config`
+and the other labeled `Update Multiple Choice Proposal Submission Config`.
+
+The various parameters are described below.
+
+## Proposal deposit
+
+This is a required deposit someone must put down to create a proposal. This can
+be the DAO's governance token, if it exists, or any other token on the chain. By
+default, this is disabled.
+
+### Refunding proposal deposits
+
+There are three ways to handle proposal deposits:
+
+1. `Always` refund proposal deposits, regardless of whether the proposal passes
+   or fails.
+2. `Only passed proposals` refund proposal deposits.
+3. `Never` refund proposal deposits.
+
+:::tip
+
+You may want to enable this if you are worried about spam.
+
+:::
+
+## Proposal submission policy
+
+This determines who is allowed to submit proposals to your DAO. The options are:
+
+- Only members
+- Anyone
+
+It defaults to `Only members`.

docs/configuration/staking.md

@@ -0,0 +1,23 @@
+---
+sidebar_position: 3
+---
+
+# Staking
+
+Token-based and NFT-based DAOs can configure the parameters of their staking
+process.
+
+Staking parameters are initially set when you create a DAO. Of course you can
+always modify them later with a [governance proposal](/definitions/proposals)
+containing the `Update Staking Config` action from the `DAO Governance`
+category.
+
+## Unstaking duration
+
+After someone stakes tokens in a DAO, those tokens cannot be immediately
+unstaked. The unstaking duration is how long they remain locked after deciding
+to unstake. During the unstaking process, they do _not_ count towards your
+voting power, and you cannot transfer them.
+
+This adds a time cost to staking and ensures a greater level of participatory
+commitment from members.

docs/configuration/voting.md

@@ -0,0 +1,103 @@
+---
+sidebar_position: 1
+---
+
+# Voting
+
+Voting parameters are initially set when you create a DAO. Of course you can
+always modify them later with a [governance proposal](/definitions/proposals)
+containing the `Update Voting Config` action from the `DAO Governance` category.
+
+If you have multiple choice proposals enabled, you will instead see two
+different actions, one labeled `Update Single Choice Voting Config` and the
+other labeled `Update Multiple Choice Voting Config`.
+
+The various parameters are described below.
+
+## Passing threshold and quorum
+
+The **_passing threshold_** is the `Yes` threshold needed to pass a proposal. It
+defaults to majority (i.e. any votes above 50%). It sounds simple, but it gets
+trick very fast because it works differently depending on whether or not the
+quorum is enabled.
+
+The **_quorum_** is the proportion of all voting power that must vote for a
+proposal to be **passable**. It defaults to 20%. For single choice proposals,
+quorum can be disabled.
+
+### Multiple choice proposals
+
+Multiple choice proposals use quorum in the same way, but they do not have a
+passing threshold. Instead, as long as the quorum is met, whichever option
+received more votes (i.e. the plurality of votes) wins. You cannot disable
+quorum for multiple choice proposals.
+
+Read on to understand how passing threshold and quorum affect each other for
+single choice proposals.
+
+### With quorum enabled
+
+If your DAO has a quorum set, the passing threshold is only calculated among
+**those who voted**.
+
+For example, with a quorum of 40% and a passing threshold of 75%, a proposal
+could pass with only 30% of the total voting power having voted `Yes` if exactly
+40% of voters vote. Imagine: 40% of the total voting power votes on the
+proposal. Quorum is met. Of those who voted, 75% vote `Yes`. The rest of the
+votes are split between `Abstain` and `No`. `Yes` will have won the vote with a
+75% threshold of quorum, even though only 30% of the _total_ voting power voted
+`Yes`.
+
+Setting quorum to 0% means that any single voter can pass a proposal by
+themself. _This is different from disabling quorum._
+
+:::tip
+
+Enabling a quorum helps when there is a risk of low participation in a DAO.
+Large token-based DAOs likely face this risk as membership is fluid and
+attention is finite. Setting a quorum low enough ensures that the DAO cannot be
+locked due to lack of sufficient participation. However, setting a quorum too
+low can lead to proposals passing that do not represent enough member's
+preferences (if not enough people are paying attention).
+
+:::
+
+### With quorum disabled
+
+If your DAO has no quorum set, the passing threshold is calculated among **all
+possible voters**. This is considered an absolute threshold.
+
+For example, with a passing threshold of 67%, a proposal will pass if 67% of the
+total voting power voted `Yes`.
+
+:::caution
+
+Threshold and quorum can be very confusing. Please be careful and check your
+understanding with others before making any changes.
+
+:::
+
+## Only members execute
+
+If enabled, only members may execute passed proposals. If disabled, anyone can.
+This defaults to enabled.
+
+## Voting duration
+
+This is the maximum time proposals remain open for voting.
+
+## Allow revoting
+
+If enabled, votes can be changed before the voting duration ends. This defaults
+to disabled.
+
+:::tip
+
+When this is enabled, proposals always remain open for their entire duration.
+This is because the proposal outcome cannot be determined if votes can be
+changed.
+
+When this is disabled, proposals will pass or fail early if sufficient voters
+cast votes to determine an outcome.
+
+:::

docs/definitions/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Definitions",
+  "position": 3
+}

docs/governance-proposals.md → docs/definitions/proposals.md

@@ -1,14 +1,29 @@
 ---
-sidebar_position: 3
+sidebar_position: 1
 ---
 
-# Governance proposals
+# Proposals
 
-Governance proposals are how DAOs take action. You can think of proposals as the
-nervous system of the DAO—members submit and vote on proposals, and if passed,
-the DAO _does something_. Proposals are composed of three components: a title, a
+Proposals are how DAOs take action. You can think of proposals as the nervous
+system of the DAO—members submit and vote on proposals, and if passed, the DAO
+_does something_. Proposals are composed of three components: a title, a
 description, and actions.
 
+:::note
+
+When you create a proposal, the voting distribution of members at the time of
+proposal creation is snapshotted and used for the proposal. This means that if
+you were not a member when a proposal was created, you will not be able to vote
+on it.
+
+This is a security measure that prevents an attacker from purchasing a DAO's
+governance tokens if it's listed on an exchange, manipulating a vote, and then
+selling tokens immediately afterward. It also ensures that a DAO members knows
+_to whom_ they are making a proposal: the people who have voting power at the
+moment the proposal goes live.
+
+:::
+
 Actions are where things get interesting. They are software instructions that
 get executed on the blockchain after a proposal is passed. As a simple example:
 an action could pay a contributor by transferring money from the DAO's treasury
@@ -70,9 +85,13 @@ too](https://github.com/DA0-DA0/dao-dao-ui/wiki/Adding-an-action-to-DAO-DAO)!
 
 ## Multiple choice proposals
 
-The default proposal type is single choice, meaning voters only have the option
-to vote `Yes` or `No`, and thus a proposal either passes or fails. You can also
-create multiple choice proposals if they have been enabled.
+The default proposal type is `single choice`, meaning voters only have the
+option to vote `Yes` or `No`, and thus a proposal either passes or fails.
+Multiple choice proposals, on the other hand, allow many options to be voted on.
+
+If your DAO does not have multiple choice proposals enabled, ensure the DAO is
+at least on [version 2](/upgrading/v2), and then [enable them with a
+proposal](#enable-multiple-choice-proposals).
 
 ### How do they work?
 

docs/subdaos/_category_.json → docs/definitions/subdaos/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "SubDAOs",
-  "position": 6
+  "position": 2
 }

docs/definitions/subdaos/act-on-behalf-of-subdao.md

@@ -0,0 +1,28 @@
+---
+sidebar_position: 3
+---
+
+# How to act on behalf of a SubDAO
+
+As discussed in [What are SubDAOs?](/definitions/subdaos/what), the admin (or
+parent DAO) can execute any action on behalf of the SubDAO. Follow this guide to
+learn how.
+
+
+
+In the parent DAO, create a new proposal and add the `DAO Admin Execute` action
+from the `DAO Governance` category.
+
+![DAO Governance category](/img/definitions/subdaos/dao-governance-category.png)
+
+Then, select the SubDAO you want to act on behalf of.
+
+![DAO Admin Execute action](/img/definitions/subdaos/dao-admin-execute.png)
+
+Then simply choose the action(s) you want to execute!
+
+![DAO Admin Execute with Manage Members
+action](/img/definitions/subdaos/dao-admin-execute-manage-members.png)
+
+Once you pass and execute the proposal, your action(s) will be executed on
+behalf of the SubDAO.