The Shimmer Governance Framework (Phase 1 - Discussion)

Governance Proposals Shimmer & IOTA [Phase 1] Discussions
,
5

Edit Notice

After we discovered some new features yesterday in the huge amount of forum settings, I have implemented some small edits to this post:

Phase 1 Discussions

The forum offers an “Auto-close topics” function, so the system will do this automatically instead of requiring a moderator to manually close a topic after 30 days of inactivity. I have adjusted the wording accordingly and removed it as a requirement of manual work for moderators.

Specification parameters under probation

I added the time when a topic gets auto-closed to the “Specification parameters under probation” mentioned here: (The Shimmer Governance Framework (Phase 1 - Discussion))
This allows the moderators to propose a change to this parameter by proposing and getting it approved by a phase 2 poll in the forum.

Added all the “Tasks and Responsibilities” of Governance Forum moderators to the “specification parameters under probation” so that these tasks can be easier adjusted should we discover that adjustments are needed for the workflow of moderator tasks in the forum.

Phase 2 Proposal template

We have discovered that a subcategory can have a pre-implemented template. I, therefore, implemented the proposal template for the Phase 2 posts into the system instead of requiring the proposal submitter to implement it manually.
This means that a post in phase 2 will always show the predefined fields (Simple summary, Motivation, specification, etc) and the submitter just needs to fill in the proposal text in the sections.

Editing of topic posts

The system has a setting that defines how long a post can be edited after publication. This is currently set to 5 minutes. We discovered that this setting is only active for Trust level 1 members and that members with higher trust levels are excluded from this rule. We want this to be still a required feature, so I mentioned that it is also a requirement for members of higher trust levels and they need to follow the same process as a trust level 1 member.

Thanks for your attention!

13 Likes
6

I strongly agree with DLTimes here. Tight decisions form a real threat here.

His first solution -In order for a proposal to go through in phase 3, it needs 70% of all yes votes- appeals to me.

9 Likes
7

I have noticed that certain requirements for proposals to be passed on are stated in nominal values. For example, needs 100 votes in favor of a proposal. For now, this would seem suitable regarding our relatively small user base. But once our community grows, this becomes problematic and proposals are passed too easily in phase 1.

My idea: instead of requirements in nominal values (100 votes/likes) why not use relative values (25% of active forum users e.g.). With this approach, deciding on phase 1 proposals will scale with a growing community base. The current approach will NOT be able to scale.

4 Likes
8

These are parameters that are easily adjustable once the userbase grows through proposals of the moderators. They will monitor this and have the ability to propose changes that do not need to go to a network-wide vote. You can read up here how this is planned to work. Such parameters like % of active users, Average votes of the last five proposals, etc. can be used to distinguish if a change is needed.
We want to try this out for a minimum of 6 months and leave certain adjustments to the moderator team until we have the data available to implement harder requirements.

8 Likes
9

We certainly discussed that. One issue I have read about with another DAO is there were proposals pushed through during obscure times, like “New Years Eve”, where the active participation numbers were very low, and thus a small group was able to reach that 25% easily.

We discussed some method which averages participation over a period of time. This would mitigate such a risk, though it would be hard to start the framework off like this. As the numbers and data accumulates we certainly think we can find a better dynamic value to support growth.

1 Like
10

Considering the only thing you need are 100 votes in favour, which is not that hard to get, the only true limitation on which votes are put up to Firefly, are which topics moderators approve. Even if 500 people vote against it and 100 in favour, it still gets put up to Firefly.

Not to mention the question if it doesn’t make more sense to just leave most of these decissions to the engineers working on it. It is a staging net after all, that eventually when you got an actually decentralized tangle you need ways to handle changing parameters I get, although then it would be up to node owners mainly, but well.

Which brings me to the question, what can you vote for? There is this link: Shimmer-Governance/governance-scope.md at main · iota-community/Shimmer-Governance · GitHub, but how should I read it? Can you vote on everything from TIP-32, or what I think, only the ones listed there? If it is just the ones listed there, then the things which are actually Shimmer network related and you can in the future vote on are:

  1. Shimmer units: Which are purely a UI thing afaik (and you really don’t want to screw around with this later on, would be confusing as hell).
  2. Genesis supply: Which you obviously cannot change after Genesis
  3. VByte Cost: Which you could vote on yes.

And sure I understand it can change in the future. But in the end it is up to IF engineers to decide what is even allowed to be voted on. It seems for now a kinda large framework considering you can only vote on one relevant parameter. Since it is a staging network, can’t IF engineers also just decide on this one?

15 Likes
11

Am I correct in understanding the following?

  1. Voting options will always be a binary “Yes [proposal] or No” after entering Firefly for the public vote?
  2. Phase 2 will only be open for a period of 7 days?

If so I have a few thoughts.

Binary only votes:
Binary decisions/the limit to only one option, can be quite problematic and the enemy of nuance depending on how robust the level debate happening in Phases 1-2 of crafting a proposal is.

Similar to how omnibus bills are terrible but unfortunately common in national governance today, binary voting enables and even facilitates the incentive to gloss over nuanced discussion on secondary and tertiary elements of a proposal so long as the primary goal is more highly desired.

This leads to subtle perversion and decay over time similar to “death by a thousand cuts” where little inconveniences run the risk of being ignored until they compound or become bigger problems.

I think this framework does a good job of laying out guiding principles that help with this, but I think it’s worth calling out to stress the importance of guiding principles and a constitution that keeps the ideals of decentralization core to future proposals (after the network has evolved past the IOTA Foundations incubation phase).

One final thought on this topic is before the final voting phase, some sort of a Phase 1 & 2 vote on individual components of a proposal will be a good way to avoid omnibus-like proposals that can sneak one undesirable element into a largely good proposal.

My proposal is to introduce some sort of “filtration by sub-element” process into Phases 1 & 2 to make sure only the most valuable and highly desired sub-components make their way into a final Phase 3 vote.

Phase 2 - 7 day limit
My thoughts tie in a lot with the themes mentioned above, but I see this as a potentially problematic in that it may be too short a period to have enough robust discussion and debate on the nuances of a proposal.

We can assume that proposal interest will pick up exponentially as it progresses to each new phase. Only the most die-hard niche of the community will be involved in crafting and debating Phase 1 ideas, and it’s likely that many people will only be interested in participating in proposals that gained enough validation to enter Phase 2 (since it will likely be too time consuming to not filter like this). That group who enters at Phase 2 will still be quite small versus the broader voting pool, but may contain a lot of key contributors who provide valuable input.

By limiting this second phase to 7 days we run the risk of missing out on a lot of valuable input from “time-strapped” contributors and having sub-par proposals get accelerated through the voting process.

I propose we set a minimum time on this phase to 7 days with a “per-proposal” option to keep Phase 2 open as long as is seen fit. The goal being to give adequate time and attention before an item enters the Firefly voting phase

4 Likes
12

You are correct, IF Engineers determine what cannot be voted on by this framework. Of course, the IF engineers will use the TIP-32 process for technical changes.

This framework I think is more intended to use for community interactive (non-technical) decisions. Primarily I think it will be used to develop and create the Shimmer Treasury Governance Framework. The small community groups that are building the Treasury or other things, will now have some defined parameters to put those difficult decisions where a real community consensus is needed.

2 Likes
13

Wow…Holy Shit Batman. Ask a bunch of computer-loving crypto geeks to create a government and our constitution looks like PYTHON CODE of course! You all put A LOT of time and effort into this. THANK YOU. The complexity of this system is a significant barrier to entry for most Shimmer Community Members and while I did see a few abstracts and summaries, may I make a suggestion? Write Dummy’s Guide HOW-TO participate step-by-step for community members 1. looking to propose something and 2. looking the be involved in a vote. In doing so you may make some discoveries about the process and how it may be simplified, improved, or at minimum how to explain the process succinctly. GOAL: fit it into one Tweet

5 Likes
14

Every proposal should listen to the opinions of the majority in the early stage. Moreover, some of the proposals we are discussing now have different ideas and seek improvement, so we need to give time for the community to further discuss and improve. I think 1. The time for community discussions in Phase 1 and Phase 2 should be extended. 2. Before entering Phase 3, 1.) The weekly or monthly voting day should be fixed uniformly, and all proposals will be voted on on the voting day, because wallet users are not always online. 2.) After the voting date is determined, all proposals that need to be voted should be announced in the wallet in advance, giving time for wallet users to review and think about how to vote

2 Likes
15

:laughing: Absolutely. Thanks for the comments. How-to guides are worked on at the moment, and I am also going to do daily (if I find the time every day) tweet threads explaining the single topics one by one.
It has grown into a pretty detailed and complex thing over the last 12 weeks. The entry barrier is an issue, but we wanted to have a first working solution ready for the network launch that works, has no flaws, and can then be adjusted and improved.

16

Thank you for the input.

I see what you are addressing here, and it may be a good idea to define a minimum time for the [Phase 1 - Discussions] period.
All potential changes and additions must be brought forward and implemented in phase 1, so it may be good to define a minimum of 2 weeks for this.

After this, it should be up to the proposal submitter how much additional time is needed to discuss the proposal. This can be many more weeks because it is up to the proposal submitter when the proposal will be moved to the next stage and not happen automatically.

Once the submitter feels confident and thinks the proposal is ready to be decided, it can be submitted as a phase 2 poll. I am not sure if a longer time for the poll in phase 2 is needed, but we will discuss this. We have seen that 80% of the votes in polls have been coming in in the first 2-3 days, and then it usually slows down and dies out, so I don’t know if the second week of polling will be beneficial.

If you take the current proposal, It may seem a bit overwhelming. It will probably be the most complex and extended proposal that will be brought forward in Governance for a long time. And therefore, we have also spent nearly three months discussing it publicly. The text has been publicly shared with the community, and we have received very much good input to arrive at this current form.

Once the Framework is in place, I believe most proposals will focus on a single parameter or aspect and therefore be much easier to understand and discuss than this extensive document here.

Again, thanks for your comment.

Lets see what people here in the forum think about it:

Should we set a minimum required length of 2 weeks for a Phase 1 Discussion? (instead of currently no defined minimum length)
  • Yes, set 2 weeks minimum length for discussions
  • No, don’t set a minimum length for discussions
  • I am not sure

0 voters

1 Like
17

Hey,

Thank you for your input.

The voting theory is an interesting topic, and we have had extensive discussions in the community about this. It was widely discussed if we choose a simple majority or set a higher requirement of majority for our governance votes during the months of discussions that have been going on for the First BUILD vs. BURN vote.

During these discussions in 2021, several hundred community members who participated in those discussions and meetings agreed that the simple majority is the way to go in our community governance and therefore defined the rules for the treasury vote like this.

image
image1560×1303 291 KB

So, we are following here established community consent.

We have discussed these topics again during the last 12 weeks in the governance meetings working on this framework document. Still, as far as I remember, no one has brought up the idea of changing the established majority rule for the Shimmer governance framework.
We have discussed and decided to implement changes to the minimum quorum rule of 5% and shorten the counting period for the phase 3 vote in Firefly from 10 to 7 days. But, no interest was there to touch the established simple majority rule.

I have mainly one concern with implementing a 70% rule here.
We rely on token-based voting, which has its flaws as all voting schemes have (I don’t need to go into details here), but it is sybill protected and the game-theoretical right approach here.

Going with a 70% majority would have the effect that it will make every decision harder, as you have described. So it may be more difficult for a small group of large token holders to enforce a proposal they brought forward.

On the other hand, this also works the other way around:
A 70% majority requirement allows a minority of token holders (30%) to enforce their will on the bigger majority.

Because with only 30% of the votes, you can block and halt any proposal that goes against your own interests.

Meaning that a small group of large token holders could hold the community hostage and decline every proposal they do not like.
Leading, in the end, to a situation where we are stuck with decision-making and can not move forward in any regard if we do not propose something that suits this minority of “blockers”.

So you see, it has two sides here, and I think we should start with a simple majority to have a better balance in our process.

A very interesting approach has been used in the Polkadot governance (though they are currently changing it again) called Adaptive Quorum Biasing
I like this approach from Polkadot, but it is also, again, very complex. It may be worth to look into such methods in the future, and I am always open to discussing such things.

I also favor adjusting things if we see a need for it. However, this would be better suited as an individual governance proposal that seeks to change the majority rule and lets the community decide on it once the framework is implemented. The framework is made exactly for these kinds of proposals and adjustments.

Should the established simple majority rule (50% +1 vote) for governance votes in Firefly be changed to require a 70% majority?
  • Yes - change it to 70% majority required.
  • No - keep the current used simple majority (50%+1 of all votes decide)
  • I am not sure

0 voters

6 Likes
18

Yes, mainly well observed.
Firefly (token holders) is, of course, the only thing to make binding decisions in the network. The forum does not have perfect sybill protection, so it can’t serve as a final decision-making tool for essential things.
The 100 votes in the poll must come from Trust level 1 members, so not everyone can participate in these polls.
And yes, correctly, only the parameters that are part of this GitHub file are currently possible to vote on. So the framework is a comprehensive tool for not much to decide on the protocol level at Mainnet launch.
It is also important to see that engineering will open other things for governance once they are specced out (like inflation), so more stuff will become available for the community.
Core protocol parameters in Shimmer will primarily stay under the control of engineering, where they belong. Nevertheless, we are prepared to move towards more decentralization with this framework; therefore, I think it serves its purpose very well.

I think a big part of governance proposals in the near future will circle around the community Treasury and other “non-code” decisions that interest the community.

4 Likes
19

Hey Sefear. Thanks a lot for your comments!

In regards to your questions:

1. We propose to allow a vote to contain a maximum of 2 Options and the option “Make no changes”, so not a pure binary vote is enforced (of course, it can be if the proposal submitter wants this).

Maybe let me explain the thought process:

Having too many options available will be very difficult for a casual community member to decide. Presenting 6 or 7 different options in Firefly may be overwhelming and potentially lead to the voter not making any decision.

All your points here are very valid, and we have discussed this. Still, to have more than 2 “positive” options to choose from seemed too much for us.

We believe that a proposal needs the discussion phase [Phase 1] to refine an idea until it does not have too many open options available.
A bit like I just did it today with the comments we received, where I did include individual polls for such a topic.
It may be helpful to use these polls on sub-topics in the forum to make decisions on such parameters, leading to a more refined proposal, especially if there is a complex proposal like the current one.
We require that if such comments lead to changes in a proposal in phase 1, it will be reposted again to get a final clarifying opinion for the final version, which will move (after it receives enough likes/upvotes) to the Poll in [Phase 2]. Also, the idea of enforcing a minimum time of 2 weeks, as suggested by some other commenter, will be a very good way to make sure enough input is received.
With most polls in this forum, we have (until now) seen a similar behavior: More than 80% of the final votes are received in the first 2-3 days. After that, it flats out quickly, and not much happens anymore.

2. The good thing is that the moderators can adjust all those timings quite simply, should we see that we need more time. This is then the moderators’ job to act on demand if we see that the data from the forum use points in this direction. Therefore these parameters have been set “under probation” for six months to allow flexible adjustments without too much burden. As defined here

One thing that you could clarify is your proposal:

I propose we set a minimum time on this phase to 7 days with a “per-proposal” option to keep Phase 2 open as long as is seen fit.

I don’t exactly understand how you mean this.

Again thanks for your valuable input!

4 Likes
20

I think also it is a balance at times. Having a larger majority ensures a greater consensus of the community; however, the consequence is that it will take longer to pass proposals. For example, Kappy’s proposal would not have passed. Now, I’m sure if the proposal was edited, changed a bit, then maybe, just maybe, it would have passed rraching a higher majority requirement, yet it would have taken several months. So then we have to ask ourselves, do we want to extend governance and developmental progress in regards to time to ensure a greater consensus? I think there is a fine balance to be found.

Truly I don’t think neither one is necessarily better than the other, that each has its own pro’s and cons. I do think we should try to analyze the first initial proposal votes if this framework is chosen by the community. Then we can assess and change the parameters accordingly. The great thing is, if the community sees a higher majority % as a better option, we can submit a proposal to enact that change within the framework.

3 Likes
21

Note, in regards to the binary option for “Phase II”, a proposer can set a multi-answer poll in Phase I in order to gain the communities agreement of the best option.

Yet when it comes to Phase II, which would be Firefly essentially, it is easier not only with the UX to have a binary option, but also we discussed how multiple choice options could change the vote outcome.

So the idea in this framework is to have that discussion and interaction about getting the community consensus in Phase I. I also agree also, not everyone will pay attention to Phase I; however, that will be up to us to really communicate publicly important proposals.

Saying all of that, I do think, especially in Phase I we should have a minimum 2 week time set to ensure the community discussions have time to take place. We did write within the Framework that the community, moderators, and admins can change these variables in the first year without a major Firefly vote. Things won’t be perfect on day 1, we can learn as the process takes place, and then make adjustments together as a community.

4 Likes
22

I agree with maybe creating a minimum time for Phase 1. In Phase 2, even though the actual voting time is two weeks, there is then a one week hold period before a firefly vote. So Phase 2 is really like two weeks. I believe Phylo made a set schedule for Phase 2 and Firefly votes. This way busy people know when to look out for the votes in Firefly.

3 Likes
23

Lol… ya, it really amazed me that once we started discussing about and developing a framework it became apparent that we all were going down the rabbit hole. It is one thing to build this type of process for a small company, but for a global community around the world there was so much to think about and little nuances that needed to be consider to ensure everyone has the best access and ability to be heard. All while trying to have some method of spam protection and mitigations to limit gaming. It will be good to see how to’s and create TLDr’s.

1 Like
24

Thanks for the detailed replies Phylo and Deep_Sea. I think the current sub-polls being implemented in this thread solve for much of the “binary” options concerns raised, and a minimum of 2 weeks in Phase 1 does a good job in achieving the same idea I was hoping to raise with the 7 day minimum for Phase 2 as well. Some sort of ranked choice voting process (like these sub-polls) being ingrained into the early phases of future proposals will be a good way to keep discussion lively and focused

The guidelines and moderation rules the committee has laid out so far are a great starting point to this process and will naturally evolve over time as we find out what works and doesn’t as a community.

Thanks for all the hard work of everyone involved in this Governance Framework!

2 Likes