Workflows for pre-propose approver, dao roles, storage-items, distribution methods

docs/dao-governance/proposals/proposal-approver.md

@@ -0,0 +1,45 @@
+---
+sidebar_position: 5
+---
+
+# Adding a pre-proposal approver
+## What is It?
+A pre-proposal approver is an assigned address that must approve proposals before they can be voted on. This may be useful for a DAO that expects many members with very fluid ownership, and would like to offset the risk of malicous proposals by requiring consensus from a 3rd party (quite possibly another DAO).
+
+## Workflow
+
+### A. From A New DAO
+When creating a new DAO, an approver can be enabled in the advanced configurations available. An address, profile or DAO name may be specified as the approver. 
+
+![Advnaced Settings](/img/quickstart/create-dao-advanced-approval.png)
+<!-- :::warning
+Improperly configuring the approver may result in a DAO being unable to recieve proposals.
+::: -->
+
+### B. With An `UpdatePreProposeInfo` Proposal
+If a DAO already exists and requires deposits to submit proposals, by default a single pre-propose contract exists. A proposal is required to update the existing pre-proposal contract to the new pre-proposal approver contract. 
+
+To update the pre-propose requirements, a DAO can call a the proposal module entry point `UpdatePreProposeInfo`. This function creates and associates the new pre-proposal contract to that specific proposal module. 
+
+#### Proposal JSON
+```json
+{"update_pre_propose_info":{"info":{"module_may_propose":{"info":{"code_id" 420, "msg": "<base64-msg-for-encoding>","admin": "<you-dao-here>","funds":[], "label":"<your-dao-pre-proposal-approver-single>"}}}}}
+```
+
+### 2. Approving Proposals
+Any DAO delegated as a proposal approver is able to make use of the **apps tab**, located in their DAOs home page. 
+
+First, copy and paste the [DAO DAO link](https://daodao.zone) into the apps URL browser. 
+
+
+We can now navigate to the proposal requiring our decision as the approval DAO, and create a proposal to broadcast the decision.
+![Advnaced Settings](/img/quickstart/proposal-approver.png)
+
+Alternatively, a custom [execute smart contract proposal](../dao-governance/actions/cosmwasm) from the approval DAO may be proposed to manually broadcast the decision.
+```json
+## approve 
+{"extension": {"msg": {"approve": {"id": <proposal-id>}}}}
+
+## reject
+{"extension": {"msg": {"reject": {"id": <proposal-id>}}}}
+```

docs/dao-management/workflows/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Example Workflows",
+  "position": 9
+}

docs/dao-management/workflows/apps.md

@@ -0,0 +1,13 @@
+---
+sidebar_position: 1
+---
+
+# Making Use of DAO Apps
+
+DAO Apps is a tab in all DAOs for members to interact with web-applications and propose for actions to broadcasted as a DAO.
+
+![DAO Tabs](/img/quickstart/dao-apps-tab.png)
+
+## Why use DAO Apps?
+- **Familiar UX:** Navigating through apps as a DAO provides a very close experience to interacting with apps as a single wallet, from your browser.
+- **Pre Propose Approver:** [Explained in detail here](../../dao-governance/proposals/proposal-approver#2-approving-proposals), a DAO serving as a pre-proposal approver can use DAO apps for the approver workflow.

docs/dao-management/workflows/dao-roles.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 5
+---
+
+# Making Use of CW721-Roles
+
+CW721-Roles are non-transferrable NFT's that associate its owner with a specific role and weight.  
+
+## Examples of CW721-Roles In Use
+- **Creative Gaming / On-Chain Simulations**: MRPG (multi-role-playing-games), an other on-chain simulations can make use of roles.
+- **Internal Management App**: a DAO could limit access of content to members with specific roles. A DAO might even decide conditions that require a role and also a minimum voting power in order to access content.
+- **Custom Payroll & Distribution Contracts:** DAOs making use of smart contract to automate distributions to their roles. 
+
+## Workflow 
+
+### 1. Prepare Roles 
+Decide what roles are needed, as well as any weight distribution for the roles. 
+
+### 2. Instantiate & Mint Proposal 
+
+Define the following in a smart contract instantiation proposal:
+- `name` - name of your DAO roles collection
+- `symbol` - collection symbol
+- `minter` - minter of collection *set-as-DAO*
+<!-- - `withdraw_address` -  *set-as-DAO* -->
+
+![Init Roles](/img/quickstart/cw721-roles-init.png)
+The minter is the only address with the ability to transfer, burn, or modify the state of the contracts.
+
+To propose minting new role tokens:
+- `token_id`
+- `owner`
+- `token_uri`
+- `extension` - Metadata extension for the `role` & `weight`
+
+![Mint Roles](/img/quickstart/cw721-roles-mint.png)
+
+:::info
+ If a DAO has not yet assigned roles, all tokens can be minted to the DAO treasury, until roles are assigned with a nft-transfer proposal.
+:::
+
+### 3. Implement Roles Into Custom UI 
+With the roles collection contract known, ownership queries can be made by clients and other contracts to power features that make use of the DAOs role tokens.

docs/dao-management/workflows/distribution.md

@@ -0,0 +1,87 @@
+---
+sidebar_position: 5
+---
+
+# Distribution to DAO Members
+
+## A. Rewards Distributor
+A DAO may want to emit rewards to stakers or its members automatically during predefined intervals. This can happen with the use of the [rewards distributor](https://github.com/DA0-DA0/dao-contracts/blob/development/contracts/distribution/dao-rewards-distributor/README.md), configured to reflect distribution accurately in response to voting power changes.
+
+### Workflow 
+
+### 1. Create Contract 
+To create a new rewards distributor, the DAO is set as the contract owner to propose admin-level features.
+
+### 2. Register Reward Denom
+To register the token to be sent to DAO members, provide the DAOs `voting_power` module address, a cw20 or native token `denom` to be provided, along with the `emission_rate` defined by an `amount` and `duration` between distribution intervals *(e.g. 0.5udenom per hour)*. 
+
+#### Hook Caller
+Also, an optional `hook_caller` can be provided that is allowed to call voting power change hooks.  Often, as in `dao-voting-token-staked` and `dao-voting-cw721-staked` the `vp_contract` calls hooks for power change events, but sometimes they are separate. For example, the `cw4-group` contract is separate from the `dao-voting-cw4` contract and since the `cw4-group` contract fires the membership change events, it's address would be used as the `hook_caller`.
+
+### 3. Fund Contract
+:::warning
+Be sure to fund the contract by calling the `Fund` entry point, unless your deposit of funds will not be recognized and they will be frozen inside the contract. 
+:::
+
+### 4. Claim As DAO Member
+To claim any available rewards, a DAO member can simply call the distribution contracts `Claim` entry point. If there are no rewards available, the contract will error. Otherwise, there is no limit to calling this entry point during the distributions claimable timeframe.
+
+![Reward Distributor Claim](/img/quickstart/rewards-distributor-claim.png)
+### 5. Shutdown 
+A distribution can be shut down by an admin. This withdraws all future staking rewards
+back to the treasury. Members can claim whatever they earned until this point.
+<!-- 
+Bulk TX Workflow:
+- init2 
+- fund contract
+-->
+
+## B. Fund Distributor 
+
+Sending tokens to current DAO members is made simple with use of the [cw-fund-distributor contract](https://github.com/DA0-DA0/dao-contracts/tree/development/contracts/distribution/cw-fund-distributor).
+
+### Workflow 
+
+### 1. Create & Fund Contract 
+
+A smart contract instantiate proposal can create the fund distributor by defining:
+    - `distribution_height` - the height used for snapshotting voting power.
+    - `funding_period` - a time duration that should suffice to move the funds to be distributed into the distributor contract. 
+    - `voting_contract` - the DAOs voting contract for calculating distribution ratios
+
+![Init Fund Distributor](/img/how-to/fund-distributor-init.png)
+
+There are two contract entry points to fund a distribution: 
+- `FundNative` for native tokens 
+- `Recieve` for cw20 tokens.
+
+### 2. DAO Members Claim Tokens
+
+After the `funding_period` expires, the funds held by distributor contract become available for claims. Funding the contract is no longer possible at this point.
+
+There are three contract entry points for choosing how to claim tokens: 
+- `ClaimNative` 
+- `ClaimCw20` 
+- `ClaimAll`
+
+A DAO member can use the accounts builder component to claim their distribution :
+
+![Claim Fund Distributor](/img/how-to/fund-distributor-claim.png)
+
+### 3. Fund Redistribution 
+Considering it is more than likely that not every user would claim its allocation, it is possible to redistribute the unclaimed funds. 
+
+The redistribution method finds all the claims that have been performed and subtracts the amounts from the initially funded balance. The respective allocation ratios for each DAO member remain the same; any previous claims are cleared.
+
+Only the `cw_admin` can call the method.
+
+
+<!-- 
+Bulk TX Workflow:
+- init2 
+- fund contract
+-->
+
+## C. Royalty Splits
+
+### Workflow

docs/dao-management/workflows/making-use-of-storage-items.md

@@ -0,0 +1,12 @@
+---
+sidebar_position: 4
+---
+
+# Making Use of Storage Items
+
+Storage items are key-value pairs that are stored through the DAO governance process. These are designed to provide a source of truth for any content a DAO might want. 
+
+## Example of Storage Items In Use 
+- **Address Authentication**: wallet or contracts may be verified through DAO governance and stored as an item to create an easy retrieval of potential crucial address or contracts.
+- **Record Keeping**: storage items can be made of use as a journal or sorts, logging entries chronologically.
+- **Experimental**: get creative with your DAOs storage! 

docs/introduction/technical-breakdown.md

@@ -13,13 +13,17 @@ with CosmWasm and thus run on blockchains that support CosmWasm:
 - [Neutron](https://www.neutron.org/)
 - [Migaloo](https://twitter.com/migaloo_zone)
 
+### Developer Wiki
+Further technical documentation can be found in the [contracts Github wiki](https://github.com/DA0-DA0/dao-contracts/wiki).
+
 ## What is CosmWasm?
 
 CosmWasm is a [WebAssembly](https://webassembly.org/) virtual machine that runs
 in a [Cosmos SDK](https://docs.cosmos.network/) module.
 
 In practice, CosmWasm smart contracts (like DAO DAO's) are written in Rust.
 
+
 ## What is Rust?
 
 [Rust](https://www.rust-lang.org/) is a performant, memory-safe, and thread-safe
@@ -36,3 +40,4 @@ our contracts, which in turn protects your DAOs from common attacks.
 As the UI is the primary entrypoint for users interacting with DAO DAO DAOs, its
 security is as important as the smart contracts themselves. TypeScript increases
 the likelihood that bugs are detected earlier, during development.
+