Meta Governance: Signal Requests

I think we’re talking about the same thing.

We now have a forum that is intensely valuable as a tool to surface signals and have deep debate. It is my hope that most of what we call ‘Governance’ will happen here. But, because we cannot determine if anyone in the forum is a MKR Token Voter with any absolute certainty, it is convenient to assume that the discussions, polls, manifestos that we see here are generated by the Community.

This is the venue where everyone who has an interest can influence the debate and help shape the decisions that are raised up to Polls and put before the ‘Voters’. These Polls and Votes will, once we have the freedom to worry about more than just the stability fee every week, become one of the primary segments of the governance calls where we will surface them and debate relative merits. This puts them into a public record (social media, video, audio, transcripts, translations) and is generally just a nice way for people to stay engaged.

But, as I never get tired of repeating, the the governance calls are fundamentally not a place for making decisions. It’s a tiny window of time, set up in a North American TZ, held in English. The only way decisions happen are through Polls and Votes.

2 Likes

I can see the logic there. I still disagree though, and would prefer to refer to forum discussions/consensus as generated by Governance for the reasons I outlined above. I can go along with referring to forum discussions/participants as the Community though, it’s more valuable to have consistent terminology, even if I think it’s sub-optimal.

The governance calls are enjoyable and useful to watch, and I’m glad they take place. My last post wasn’t intended as an attack on them, only to clarify the point that discussion in a governance call shouldn’t be a requirement to trigger an on-chain poll.

My hope is that we will (eventually) have a system where anyone can create on-chain polls at any time, and that they will always be overwhelmingly leaning in one direction because consensus has been formed beforehand. Admittedly I have an optimistic view.

I have updated the post with the requirement to include the ‘signaling’ tag to signaling topics. This seems non-controversial, but if anyone wishes to change their signal, this is your heads up.

Copying in some stuff from the debt ceiling thread. My view is votes should be public, but only after your vote has been cast. I believe there is an option for this. This is the best option in my mind because:

  • It allows participants to invest in their own decision before seeing the majority opinion.
  • It allows participants to follow others (Foundation employees or whomever) if they want to, but encourages them to have their own opinion first.
  • It allows us to see who is voting against consensus and ask them to explain their point of view. This is essential to scientific governance and consensus seeking. If you are signalling for a thing, you should be able to explain your reasons for signalling for that thing and either convince others, or be convinced yourself.

My take on this topic (i believe i mostly echo LFW):

  1. I think informal communication (chat rooms), while very useful and important, should not be a prerequisite for governance people to attend/follow. Ideas/requests/input should be always formalized on this forum, since it takes significant time and (cognitive) effort to express ideas and arguments in a formal (written) language.

  2. Governance and Community distinction is important.
    I would expect Governors (is this even a word?) are, or will be, quite a small subset of Community.
    Community is broader category: users, translators, advocates, investors etc.
    I agree with LFW that Governance and Risk category should not be classified under ‘Community’.

  3. signalling pipeline should be:
    forum and forum polls -> governance poll -> executive vote
    Centralized discussion location is a must.

  4. purpose of chat rooms is to ask questions, throw ideas, quick debates etc.
    That is, informal communication between (segment of) members of the community.
    It is not about speaking to the general community.

  5. purpose of government calls is to talk about current topics, weekly commentary,
    current issues/problems, future plans etc. And not about reaching consensus.
    Live calls with more than a handful of people are also not a good format for
    debating hard topics
    . Good example is 39th meeting when mrabino opened a potential problem with DSR and SF calculation, and the debate got quickly quite hectic. Only after LFW created post on mkrgov reddit " Is anything wrong with the DSR and Stability Rate calculations as planned for MCD?", my understanding got better.

  6. I also agree with LFW about votes being public only after vote has been cast.

1 Like

Thanks for adding your thoughts, very clear and easy to read.

Regarding point 5 and meeting 39, I’m not quite sure I’ve ‘done a good’ here. As it turns out, Matt R was putting forward a related yet distinct problem from what I posted about in Is anything wrong with the DSR and Stability Rate calculations as planned for MCD?

Ironically, we clarified matters somewhat between us in the chat sometime afterwards, which is a good example of why chat-rooms are less than ideal for this sort of thing, as it never made it to the forum or r/mkrgov.

Not sure if @mrabino1 wants to make a separate topic on this forum about his points and some explanation around this, but the most succinct explanation of the problem we were able to agree on was:

Accurately managing the Risk Premium of collateral packages to be risk free with time presents systemic challenges at scale given the requirement of decentralisation: requiring MKR Holders to watch over the risk parameters of each collateral-package to ensure that excess DAI minted from out-of-date parameters is not removed using the DSR.

And if I had to generate an ELI5 version:

Risk Premiums can go out of date as the risk of the collateral changes, which can introduce risky Dai to the system that can be hidden by the use of the DSR to mop up excess supply.

2 Likes

Since the launch of DAI, the price has been "motivated’ my monetary policy in form of a stability fee. However, in MCD, we are morphing to bifurcate risk policy (the risk premium of a given collateral package and what pricing do we assign to derisk the collateral (probably to the 95% threshold)) and monetary policy (how much supply is out there and what can do we do to motivate more or less supply, e.g. the DSR… and using it to bring supply and demand into harmony…

as a community there will be significant steps needed that require rough consensus to navigate until we have multiple collateral packages with assign Risk Premiums.

at some point (sooner than we realize), the quantity of collateral packages make moderating the risk associated to any one given package unmanageable as a community…

how risk-teams are formed / how their collective decisions are implemented is one of many points. but the broader point is the main theme to digest… the community shouldnt be voting on a given RP for a collateral package X… as the community as a whole does not have the same risk expertise as a risk expert (I most certainly do not have this skill… nor do I want the job)…

if we do not price the RP correctly… (e.g. assigning 10bps to collateral that has serious risk, we allow the Risk to be subsidized by the entire system)… the DSR will mop up excess supply… it is blind to how it was created, after all DAI is fungible.

whole point is more or less agreeing on where we want to be in 10 years… 5 years… 2 years… 6 months… and then gaining consensus on how to do it…

the debt ceiling is one of many open items that need consensus…

so in my eyes, we need to get a proposal on where want to be …and how to navigate these waters… a place to start… and then iterate on what would make it better… (“when no one wants the credit, it will be amazing at what we can accomplish”)

We all want multi-collateral dai sooner than later… that said, I for one do not know how we can reasonably launch without a plan on how to handle the steps…

Can we hash out some guidelines for future signaling polls, a non exhaustive list of points in no particular order:

  • Determining options and wording
  • Duration, start and end weekday & time
  • Results hidden, visible or visible after poll closes
  • Single choice, multiple choice or numerical rating/value

Some points are probably clear based on the context, others may not have a concrete answer (i.e. result visibility)

Overall the goal at the signaling stage should be maximum utility?

Any takeaways from Augur’s reporters.chat ? Is it worthwhile for MakerDAO forum users to take a closer look at it?

Having a set of guidelines is a good call, if we can get some more feedback, I’m happy to collate them and post them as a new topic. Here are mine.

I like signalling/consensus seeking in the following form:

  • Proposing a solution to a single problem.
  • Including an honest list of advantages and disadvantages to this solution.
  • Poll options of Agree/Disagree/(Undecided?)
  • The proposal can change in response to input and discussion on the thread, onus is on those participating to keep their signals up to date with the current proposal, and to explain their perspective if they disagree.
  • Polls don’t close ever (or closed manually once the on-chain poll/executive happens)
  • Results are hidden until you’ve voted.
  • Votes open to change at any time (not sure that it’s possible to turn this off anyway)
  • ‘Show who voted’ turned on so that you can see who is disagreeing and get them to put forward their point of view.

Any poll can be expressed this way, I think. The focus is more on consensus-building than on majority-rules under these guidelines. The idea is to listen to everyone, and hopefully get everyone on board with an acceptable solution, even if it isn’t everyone’s first choice.

There are occasions where multiple poll options may be more efficient though, such as in the debt-ceiling case. In that situation I think ‘Multiple Choice’ is actually more effective, letting everyone vote yes or no to every proposed option. For example, in the debt ceiling poll I prefer an 20mil raise, but I would also vote (on-chain) for a 50mil raise. In a ‘Single Choice’ poll, this information is lost unless I comment.

Anyone else want to contribute to info on guidelines here? Rich mentioned this in the call this week. It would be great to be able to get more input into a solid set of guidelines for future signal requests.

Should anyone be allowed to start signalling poll? Or should this be tied to reaching some forum level Trust Level?

Probably it makes no sense to put any barriers at this early stage.

Unless we start seeing spam, I would be hesitant to lock it to any trust level. Your level of participation in the forum doesn’t necessarily have any bearing on whether you have good or well supported ideas.

If the volume of posts/requests picks up significantly, maybe we limit them on something else, but I don’t think it’s anything to worry about yet.

1 Like

Assuming multiple polls interface is available, what criteria determines if/when forum signalling poll is being put to on chain polling vote?

  • poll prerequisites should be met
  • threshold number of votes or sufficient time passed
  • is some minimal support percentage expected (qualitative polls)?

Good questions, here’s my thoughts on when a forum poll should be moved to a on-chain poll. We should move to on-chain when any of the following are true.

  • Consensus >90% with reasonable participation.
  • Consensus >75% with reasonable participation and no valid objections have been presented by those voting against.
  • Consensus >50% with reasonable participation and discussion has stagnated (no new points of view) for two weeks.

The elephant in the room with these is how to define ‘reasonable participation’. In my opinion this should depend on how many people are actively using the forum, and how many people have signalled in comparison to other signalling topics. A signalling topic that has more votes and discussion than any of the others would have reasonable participation, even if the total votes is say ~30.

As the actively participating community grows, this threshold should grow. At a minimum signals should be on the forum for a week and brought up in the governance call to raise awareness before moving on-chain.

1 Like

We **very ** much need a delegation structure for Maker… there is almost a dislocation between those that are active on these collaboration tools (forum / chat / etc) and those that vote… then again, that is my perception…

Spam or on-chain polls matter… but the influence of a known party that has been granted delegated authority should also disproportionally matter.

Your proposal (and percentages) seem reasonable to me.
I also agree that ‘reasonable participation’ should be defined relatively - based on recent forum usage.

How do we count votes which are not yes/no, but “other” - undecided or have no opinion etc.
What is consensus percentage of 11 people vote: 9 for yes, 1 no, 1 other? 9/11 or 9/10?
I would say it’s 9/11.

I would say this might depend on how important the poll is. In general, consensus is defined as a course of action that everyone can accept, even if it isn’t their first choice. By this definition, ‘no opinion’ would be counted as a consensus vote (if you have no strong opinion, then you can accept the proposal). Explicit votes for ‘Undecided’ or ‘Other’ would probably be counted against consensus.

It gets a bit complicated, but I think that common sense on a case by case basis goes a long way here. The onus is on dissenting opinions to make themselves known; if something passes that you don’t like because you didn’t express how strongly you were against it, that’s pretty much your own fault.

I’d like for us to give some deep thought to the idea before we start implementing thresholds. It is going to be awhile before we see anything like real engagement with voting and/or the forums and every friction we add to the system is going to subdivide an already small group of stakeholders.

I’m concerned that we are going to be hobbled be engagement numbers. And, if systems administration has taught me anything, when you create thresholds you’ve given people a map to gaming a system.

I’m in the camp of ‘if you don’t think your vote matters, then the system will controlled by those who do’.

It’s a question of which meme will win:

“Get out to vote because things are going to happen with or without you.”

vs

“Not enough people voted so nothing is going to happen. Better vote next time.”

I did not understood LFW’s proposal as some kind of ‘hard’ threshold rules, it’s just that we need to start with some kind of simple heuristics. Sometimes you just need to start doing things, learn by mistake and adjust. ‘Deep thinking’ before starting to dig your first trench, seems inefficient and naive to me.

Currently we are relatively small ‘tribe’ and imo we should not think too far in advance. We just need be aware that this might change in the future and then we will need to behave differently.

Yep, I don’t think of them as hard and fast rules, but we need some interim heuristic to work from, as jernejml said. The problem is that the lack of participation can always be used as an argument not to do anything, but if give weight to that argument, nothing will ever get done.

Simple heuristics that we update as the community grows, mainly around the evolution of the phrase ‘reasonable participation’

For any signal request we could create a secondary poll with the title ‘Is this ready to move to an on-chain poll?’ Then we can explicitly gather that information.

1 Like