We have one organization identifier, it is usually a u32.
The shares modules sometimes use each other but they are intended to be used separately such that
shares-membership (flat share group Vec<AccountId> shape) =>vote-petition
shares-atomic (weighted share group Vec<(AccountId, Shares)> shape) =>vote-yesno
In practice, vote-yesno also inherits shares-membership and uses it instead of shares-atomic for certain 1P1V vote configurations.
vote-yesno gives us the power to create flat and share-weighted votes with both a support threshold and a turnout threshold
vote-petition gives us the power to create flat votes that empower groups to veto decisions for some time after they are approved (NOTE: I need to refactor this module to reflect this new clear purpose, it is a bit too much like vote-yesno)
So, here is a big enum that reflects some of the governance structures that we can support; there are three basic patterns here if you look more closely.
#[derive(PartialEq, Eq, Clone, Encode, Decode, RuntimeDebug)]
/// These are all the vote configs planned to be supported
/// TODO: we have n = 1, 2 so do it with AccountId, up to `12`, one day somehow
pub enum VoteConfig<AccountId, OrgId, ShareId, BlockNumber> {
/// Only one supervisor approval is required but everyone has veto rights, for BlockNumber after approval
OneSupervisorApprovalWithFullOrgShareVetoRights(AccountId, OrgId, ShareId, BlockNumber),
/// Two supervisor approvals is required but everyone has veto rights, for BlockNumber after approval
TwoSupervisorsApprovalWithFullOrgShareVetoRights(AccountId, AccountId, OrgId, ShareId, BlockNumber),
/// Only one supervisor approval is required but everyone can vote to veto must reach threshold, for BlockNumber after approval
OneSupervisorApprovalWith1P1VCountThresholdVetoRights(AccountId, OrgId, ShareId, u32, BlockNumber),
/// Two supervisor approvals is required but everyone can vote to veto must reach threshold, for BlockNumber after approval
TwoSupervisorsApprovalWith1P1VCountThresholdVetoRights(AccountId, AccountId, OrgId, ShareId, u32, BlockNumber),
/// Only one supervisor approval is required but everyone can vote to veto must reach share weighted threshold, for BlockNumber after approval
OneSupervisorApprovalWithShareWeightedVetoRights(AccountId, OrgId, ShareId, u32, BlockNumber),
/// Two supervisor approvals is required but everyone can vote to veto must reach share weighted threshold, for BlockNumber after approval
TwoSupervisorsApprovalWithShareWeightedVetoRights(AccountId, AccountId, OrgId, ShareId, u32, BlockNumber),
/// Warning: Dictatorial and Centralized Governance, some say _practical_
OnePersonOneVoteThresholdWithOneSupervisorVetoRights(OrgId, ShareId, u32, AccountId, BlockNumber),
OnePersonOneVoteThresholdWithTwoSupervisorsVetoRights(OrgId, ShareId, u32, AccountId, AccountId, BlockNumber),
ShareWeightedVoteThresholdWithOneSupervisorVetoRights(OrgId, ShareId, u32, AccountId, BlockNumber),
ShareWeightedVoteThresholdWithTwoSupervisorsVetoRights(OrgId, ShareId, u32, AccountId, AccountId, BlockNumber),
/// 1 person 1 vote, u32 threshold for approval, but everyone has veto rights, for BlockNumber after approval
OnePersonOneVoteThresholdWithFullOrgShareVetoRights(Org, ShareId, u32, BlockNumber),
/// 1 person 1 vote, u32 threshold; only the second share group has veto rights (also must be flat!), for BlockNumber after approval
OnePersonOneVoteThresholdANDVetoEnabledGroup(Org, ShareId, u32, ShareId, BlockNumber),
/// ShareWeighted vote, u32 threshold for approval, but everyone has veto rights, for BlockNumber after approval
ShareWeightedVoteThresholdWithFullOrgShareVetoRights(Org, ShareId, u32, BlockNumber),
/// ShareWeighted vote, u32 threshold for approval, but everyone has veto rights, for BlockNumber after approval
ShareWeightedVoteThresholdANDVetoEnabledGroup(Org, ShareId, u32, ShareId, BlockNumber),
}
We have one organization identifier, it is usually a
u32
.The
shares
modules sometimes use each other but they are intended to be used separately such thatshares-membership
(flat share groupVec<AccountId>
shape)=>
vote-petition
shares-atomic
(weighted share groupVec<(AccountId, Shares)>
shape)=>
vote-yesno
In practice,
vote-yesno
also inheritsshares-membership
and uses it instead ofshares-atomic
for certain 1P1V vote configurations.vote-yesno
gives us the power to create flat and share-weighted votes with both a support threshold and a turnout thresholdvote-petition
gives us the power to create flat votes that empower groups to veto decisions for some time after they are approved (NOTE: I need to refactor this module to reflect this new clear purpose, it is a bit too much likevote-yesno
)So, here is a big enum that reflects some of the governance structures that we can support; there are three basic patterns here if you look more closely.