Meta Governance: Signal Requests

As some of you have probably noticed, I’m big on organization and clarity. I think efficient and effective communication is going to be an absolute requirement of any decentralized governance effort.

It’s possible for any user to run polls in Discourse. Polls can be a useful tool for signalling around certain ideas or proposals.

With these two things in mind, I propose the following:

Anybody that wants to collect signals for some opinion or course of action should create a topic in the governance category titled Signal Request: <polling question>.

The top level post should always contain a summary of advantages and disadvantages for that issue, collated by the original poster as the discussion takes place in the topic.

The ‘signaling’ tag should be applied to such topics so they can be easily filtered.

The Advantages:

  • It makes it very easy to see when someone is attempting to gather signals without having to read every topic.
  • It makes signal requests easier to find using the search function.
  • Having the top level post summarize the arguments of both sides makes it easier for Governance to form a balanced view of the issue before voting.

The Disadvantages:

  • It adds to the institutional knowledgebase (the list of things governance needs to know to properly participate.)
  • There is some ongoing responsibility of the original poster to keep the summary up-to-date.
  • There is a requirement that the original poster be ‘honest’ and not misrepresent arguments they disagree with.
  • There is no way of telling the MKR holdings of the participants, anyone with a forum account can participate.
  • This polling method is vulnerable to Sybil attacks.

  • Yes, I agree with the proposal.
  • No, I disagree with the proposal.

0 voters

1 Like

An additional disadvantage is that anyone could register and vote, you don’t know who is actually an MKR holder.

I will add this to the disadvantages, but I don’t think it’s not a reason to use the forum polls for signalling. If we need to decide anything important, we will still use MKR-based polls using the governance dashboard, likewise, if it appears that a forum poll has been Sybil-attacked, we can re-run it on the governance dashboard and get an outcome with more authority.

It’s my hope that we can use the polls to create effective discussion of the issues, and identify issues that are fairly non-controversial and that can be easily confirmed using the governance dashboard.

Perhaps we can make the distinction between Community and Governance?

The forum polls collect signals from the Community, which are then fed into the Governance polls which collect signals from the MKR token holders?

I like this idea of a signalling pipeline:

general chatting and debate -> forum poll -> governance call discussion -> governance poll -> executive vote

3 Likes

I think that this distinction is useful, but I don’t believe that forum activity in the Governance and Risk categories should be classified under ‘Community.’

The assumption should be that if you are in these parts of the forum that you are actively taking part in governing the system. Anyone that is taking part in the governance of the system should be referred to as governance. Debate and discussion of governance issues is just as much a part of governance as voting on said issues with MKR. To call participants the community implies that they are not governing, which they are, even if they own no MKR.

There is danger here of course: anyone without a stake in the system does not have right incentive alignment. This is why we need an easy way of communicating with signed messages similar to https://reporters.chat/. In the meantime, we can make do and judge everyone’s statements as ‘possibly malicious.’ The problem is that discussion and debate is an integral part of governance and some participants without stake but with malicious intentions could influence those with MKR.

In terms of a signalling pipeline, I think that this is too hierarchical.

This setup privileges one location for discussion (the governance call) over another (the forum). We shouldn’t do this generally, but especially because the call is not an effective location in which to gather consensus (you have to be available at the correct time, participants speak off-the-cuff, it is time limited).

In addition, forum polls should be part of the discussion from the beginning. They are a cheap and efficient method for measuring consensus. It is possible to change your vote at any time, so if a new point comes up in the discussion that sways you to change your mind, you can update your vote in seconds. Ideally a forum signal poll should show the current distribution of opinions on the topic discussed and should naturally vary throughout the discussion.

I feel that the process would be more effective as something like this:

  1. Debate in all venues with the aim of generating consensus.
  2. Acceptance that all relevant points have been considered. Evidenced by no new points raised / discussion stalled / general consensus among participants that this is ready to go to a Governance Poll).
  3. On-Chain Governance Poll
  4. On-Chain Executive Vote (if changing system parameters)
2 Likes

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.

1 Like

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.