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

docs/workflows/_category_.json

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

docs/workflows/dao-roles.md

@@ -0,0 +1,37 @@
+---
+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.  
+
+## When Might A DAO use CW721-Roles?
+In a scenario of a DAO with an internal management app that would want to limit access to only those assigned by the dao. A DAO might even decide conditions require a role and also a minimum voting power in order to access content in there application.
+
+## Workflow 
+
+### 1. Prepare Roles 
+Decide what roles are needed, as well as any weight distribution for the roles. 
+
+### 2. Instantiate & Mint Proposal 
+Propose to create the roles collection by defining:
+- `name` - name of your dao roles collection
+- `symbol` - collection symbol
+- `minter` - minter of collection *set-as-DAO*
+<!-- - `withdraw_address` -  *set-as-DAO* -->
+
+The minter is the only address with the ability to transfer, burn, or modify the state of the contracts.
+
+Propose to mint:
+- `token_id`
+- `owner`
+- `token_uri`
+- `extension` - Metadata extension for the `role` & `weight`
+
+:::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](../dao-governance/actions/nfts#transfer-nft).
+:::
+
+### 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 *(e.g. a dao with a moderator role needs to restrict access to a specific analytic page in their web-app)*.

docs/workflows/distribution.md

@@ -0,0 +1,88 @@
+---
+sidebar_position: 5
+---
+
+# Distribution to DAO Members
+
+## A. Rewards Distributor
+A DAO may want to emit rewards to stakers or it 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` 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 your rewards:
+```json
+{"claim":"<expected-denom-to-claim>"}
+```
+
+### 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 
+
+Be sure to specify the following:
+
+    - `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
+
+![Create proposal button](../../static/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`
+
+### 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/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/workflows/proposal-approver.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 2
+---
+
+# 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.
+
+## 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>}}}}
+```