Merge pull request #20 from cheeky-gorilla/patch-11

Grammar + consistency changes - 6-guidelines-for-regular-operation.md

Author: tvanepps

docs/6-guidelines-for-regular-operation.md

@@ -2,40 +2,40 @@
 
 What follows is an outline for how we plan to start, recommendations, and guidelines for regular operation scenarios.
 
-The Guild should transition to Regular Operation before the end of the Initial Pilot but only after the summary report has made meaningful progress in assessing the Guild's evolving characteristics. Activities during Regular Operation should map directly to the obligations described in **3. Roles & Expectations**. Some things will change regularly, like the current set of sponsors at a specific time, or the membership over time.
+The Guild should transition to regular operations before the end of the initial pilot, but only after the summary report has made meaningful progress in assessing the Guild's evolving characteristics. Activities during regular operations should map directly to the obligations described in **3. Roles & Expectations**. Some things will change regularly, like the current set of sponsors at a specific time, or the membership over time.
 
 ## 6.1 Comms
-- broadcasting to the community and prospective sponsors when vests are set to start and end
+- Broadcast to the community and prospective sponsors when vesting periods are set to start and end
 
 ## 6.2 Parameter Setting
 
-  - length of each new vesting period
-  - how much of a raise to target for each vesting pool
-  - number of months contributing needed ahead of inclusion
-  - number of multisig signers, whether it should be proportional to number of members
-  - how often signers should be required to prove address control
-  - how frequently membership will be updated
+  - Length of each new vesting period
+  - How much of a raise to target for each vesting pool
+  - Number of months contributing to core development before being eligible for membership
+  - Number of multisig signers, whether it should be proportional to number of members
+  - How often signers should be required to prove address control
+  - How frequently membership will be updated
 
 ## 6.3 Weighting
 
 Antifragility and non-gameability emerge from simple frameworks. This limits the time spent deciding appropriate categories, the methods for collecting and verifying  as well as the time spent weighting contributors. Additionally, this should limit cases of ambiguity gaming that might come up in complicated weighting schemes. Based on member feedback, we've settled on these guidelines: SQRT((`eligibleMonths` - `monthsOnBreak`) * `timeWeighting`)
 
-  - historic contributions are considered in weightings
+  - Historic contributions are considered in weightings
   - `timeWeighting` can be either 1.0 for full-time or .5 for part-time contributors
-  - existing contributors get "diluted" as newcomers come in
-  - continuing contributors get additional weight per month they are active. This means historic contributors don't maintain their split weighting if they leave protocol development
-  - anyone who stops contributing is removed from the split via periodic Curation Reviews
+  - Existing contributors get "diluted" as newcomers come in
+  - Continuing contributors get additional weight per month they are active. This means historic contributors don't maintain their split weighting if they leave protocol development
+  - Anyone who stops contributing is removed from the split via periodic curation reviews
 
-## 6.4 Proposing and discussing new members
+## 6.4 Proposing and Discussing New Members
 
-If current members believe that the set should be expanded to include another contributor, they should propose them well enough in advance of a Membership Update. This would mean at least a week. The process would look something like this:
+If current members believe that the set should be expanded to include another contributor, they should propose them well enough in advance of a membership update. This would mean at least a week. The process would look something like this:
 
-1. an existing member (akin to an EIP champion) should send this info in the `proposed-members` channel.
+1. An existing member (akin to an EIP champion) should send this info in the `proposed-members` channel.
 
 - Name / Identifier
 - Team / Project
 - Discord handle
-- Link to relevant work, eg. github, research
+- Link to relevant work, eg. GitHub, research
 - Summary of their work and eligibility
 
 2. Discussion should be open for at least a few days to give members time to review and contribute to the discussion. This can be either with reacts on the proposal 👍 / 👎, ideally along with some written thoughts on why you think the proposed member fits the eligibility or not. Deliberations should strive to end in rough consensus, resorting to formal voting procedures only in rare extreme situations.
@@ -48,15 +48,15 @@ We are exploring tools and methods to make this process more transparent, potent
 
 ## 6.5 Onboarding new members
 
-Eligible and confirmed members should be given an onboarding form link to be added to the split contract at the next quarterly update. They should also be added to the Stateful Works discord and given the proper `Guild Member` / Team roles.
+Eligible and confirmed members should be given an onboarding form link to be added to the split contract at the next quarterly update. They should also be added to the Stateful Works Discord and given the proper `Guild Member` / Team roles.
 
 When introducing the concept to potential members or onboarding accepted ones, it should be noted that the submitted address should refer to an individual's personal wallet and *not* their employer's. If teams were the atomic unit, all team members would have to agree on whether to accept or decline membership, likely decreasing the number of participants.
 
 ## 6.6 Guild Contact
 
-It may be the case that there should be a Guild Contact for each team. The backstop is each team/project, who only need to confirm when a contributor has been added or removed. One member of each team/project (eg. Lighthouse) should agree to be the point of contact responsible for ensuring other members are aware of any significant developments like:
+It may be the case that there should be a Guild Contact for each team. The backstop is each team/project, who only need to confirm when a contributor has been added or removed. One member of each team/project (e.g. Lighthouse) should agree to be the point of contact responsible for ensuring other members are aware of any significant developments like:
 
-- explaining membership obligations to new team members
-- collecting addresses and signatures for inclusion in the eligible set
-- migration to a new smart contract
-- a change to the weighting scheme
+- Explaining membership obligations to new team members
+- Collecting addresses and signatures for inclusion in the eligible set
+- Migration to a new smart contract
+- A change to the weighting scheme