Merge branch 'brent/update-govdata-doc' (#380)

Small misc governance updates

packages/docs/pages/users/governance/governance-actions.mdx

@@ -70,13 +70,19 @@ namada client query-proposal-result --proposal-id $ID
 <Callout type="info">
 If the proposal has not passed, it will be rejected, and the code will not be executed.
 
-Another important note is that the voting period differs between validators and non-validators. The validators have a shorter voting period than the delegators. This is to ensure that the non-validators have enough time to vote on the proposals (so that the validators cannot vote in the last block against the non-validators preference). See the specs for more information.
+Another important note is that the voting period differs between validators and non-validators.
+Validators have a shorter voting period than delegators.
+This ensures that, if a delegator would like to vote differently than the validator to which they are delegated, there is a period during which they can change their vote to their own, rather than let the validator vote using their voting power.
+This prevents validators from voting in the last block of the voting period against the true preferences of their delegators.
+See the specs for more information.
+
+The output of `namadac query-proposal-result` will detail the latest epoch in which validators can vote on a given proposal.
 </Callout>
 
 ### Tally types
 The governance mechanism defines different criteria depending on proposal type in order for the proposal to pass:
 
-**Default proposals** require at least 2/3 of the total active voting power to have voted AND the `yay` voting power must be at least 2/3 of the combined `yay + nay` voting power.
+**Default proposals** require at least 40% of the total active voting power to have voted AND the `yay` voting power must be at least 2/3 of the combined `yay + nay` voting power.
 
 **PGF steward proposals** require at least 1/3 of the total active voting power to have voted AND the `yay` voting power must be larger than the `nay` voting power.
 

packages/docs/pages/users/governance/proposal-structure.mdx

@@ -31,18 +31,22 @@ Now, we need to create a json file `proposal.json` holding the content of our pr
         "voting_end_epoch": <Number>,
         "activation_epoch": <Number>
     },
-    "data": "TODO-ADD-DATA-IF-NEEDED"
+    "data": "TODO-ADD-DATA-IF-NEEDED" // optional field to contain serialized wasm code
 }
 ```
 
-Most of the fields within `"content"` are self-explanatory. The `requires` field references an id in quotations of another proposal that must be passed before this proposal can be executed. The `created` field must contain the creation time in the format `YYYY-MM-DDTHH:MM:SSZ`.
+Most of the fields within `"content"` are self-explanatory.
+The `requires` field references an id in quotations of another proposal that must be passed before this proposal can be executed (i.e. `requires: "2"` mandates that proposal 2 must pass for this proposal to pass).
+The `created` field must contain the creation time in the format `YYYY-MM-DDTHH:MM:SSZ`.
 
 
 A proposal author should manually set the following fields in the `proposal.json`:
 
 - `author`: the `tnam` address of `my-new-acc`;
 - `voting_start_epoch`: a future epoch in which you want the voting to begin.
-- `voting_end_epoch`: an epoch that is at least `min_proposal_voting_period` epochs further into the future than `voting_start_epoch` at which point no more votes are accepted.
+- `voting_end_epoch`: an epoch that is at least `min_proposal_voting_period` epochs further into the future than `voting_start_epoch`, at which point no more votes are accepted.
 - `activation_epoch`: an epoch that is at least `min_proposal_grace_epochs` epochs further into the future than `voting_end_epoch`, at which any associated WASM code will be executed.
 
-The `data` field and its contents are dependent on the [type of proposal](./proposal-types.mdx) being submitted. In a default proposal, data is optional, but if included then it is a vector of bytes corresponding to WASM code. In a PGF-related proposal, the data contents take another form.
+The `data` field and its contents are dependent on the [type of proposal](./proposal-types.mdx) being submitted.
+In a default proposal, data is optional, but if included then it is a vector of bytes corresponding to WASM code.
+In a PGF-related proposal, the data contents take another form.