Suggested Signaling Process

The intention for this thread is to describe the current signaling process on these forums. It is meant to be descriptive and not prescriptive at this stage.

Thus far it’s mostly been me pushing this process and potential improvements that have been discussed in the past. I want to make it clear that anyone is welcome to start this process (or follow their own if they think they have a better process) on any issues of their choosing.

With all that said, this is the process that I plan to follow for the most recent signaling thread.


Stage 1

Action: Determine if there is a majority for change in some form by asking a general question: ‘Should we change from x’
Justification: The intention behind this is to determine immediately whether there is consensus for the status quo. If there is, the process can end here before lots of effort is expended trying to forge agreement on specifics.

Action: Call for discussion and suggestion on specific options that the community would like to see.
Justification: In the interest of efficiency, specific options can be proposed and discussed before the desire for change has been determined. In addition, opening up the proposal to the community gives everyone a voice on the specific implementation.

Action: Stage 1 lasts for one week.
Justification: This gives enough time for the initial signal to have some weight without unduly delaying the decision making process.

Action: The initial sentiment poll remains open for the duration of the process.
Justification: Some people will not be able to check the forums once a week, this allows them to signal for/against change at any point during the process.


Stage 2

We move to Stage 2 if the initial sentiment poll has a simple majority after 1 week.

Action: Create a multiple-choice poll allowing everyone to signal acceptance for each of the options proposed so far, this poll expires in two weeks.
Justification: A multiple-choice poll lets us most efficiently rank the proposals according to consensus.

Action: Stage 2 lasts for a minimum of 2 weeks.
Justification: Two weeks gives plenty of time for discussion and signalling on the specific options proposed within the first week.

Action: Additional specific proposals are welcomed and encouraged during step 2.
Justification: It’s possible that there will be no majority for any of the initially proposed changes. By allowing additional suggestions after this time we can parallelize the decision process.**

Action: If after the two weeks are over, there is no majority for any of the proposed options, Stage 2 repeats.
Justification: We should not adopt any proposal that does not have majority backing. By repeating stage 2 with a modified set of proposals, we have a better chance of reaching a majority.

Action: Throughout this process, the importance of compromise and building consensus should be emphasized.
Justification: The aim of this process is to find a solution that everyone can accept, rather than a solution that is everyone’s first choice. By emphasizing this, you help remind signallers of this aim.


Stage 3

We move to Stage 3 if a single specific proposal has majority backing.

Action: An on-chain poll is created in the form ‘Specific consensus option, yes or no?’
Justification: This lets MKR Token Holders to ratify the change, and confirm that the change is better for the system than the status quo. I don’t think we need to vote on what the on-chain poll looks like individually for each proposal, so I’m following the vote on the exponential rate stepping proposal.

Action: Currently we’re reliant on the Foundation to create on-chain polls, so Stage 3 involves convincing the Governance Facilitator to create this on-chain poll.
Justification: This is necessary to get the poll on-chain.

Action: The on-chain poll should last for a week.
Justification: By this point, active MKR Token Holders should be aware of the prior proceedings, one week should be sufficient for those who wish to vote to do so.


Misc Thoughts

  • In a ideal situation, the time from proposal to on-chain poll is three weeks, with one week on the on-chain poll, that means total time for a change to occur is one month.
  • With a controversial issue, the process to find consensus could take much longer.
  • If Stage 2 fails to find a consensus option after three iterations, the change should be abandoned for a period not shorter than three months.
  • If the initial sentiment poll drops below 50% and remains there by the time stage 2 ends, the change should be abandoned for a period of not shorter than one month.

As always, feedback is most welcome.

7 Likes

Thanks for this, @LongForWisdom! I’d like to get more involved here.

I understand that we want to approach this in “steps” However, can you share what the process is for creating an on-chain vote? Can anyone do it? Or is some sort of centralized permission required currently?

I am unsure of the entire process, I believe that in order to be included on the front-end @ vote.makerdao.com, something needs to happen that is controlled by the Foundation.

In terms of the on-chain part, anyone can call the appropriate smart contract function on the PollingEmitter: https://etherscan.io/address/0xF9be8F0945acDdeeDaA64DFCA5Fe9629D0CF8E5D#code

Thus far, I don’t believe anyone outside the Foundation has setup a poll. @rich.brown might be able to elaborate on the process and the plans to open this up to those outside the Foundation.

Hello, I was one of the people who worked on the current signaling system so I thought I’d chime in with a few technical details in case they’re useful.

vote.makerdao.com currently only shows polls created by approved addresses. These addresses are, at the moment, associated with wallets controlled by members of the foundation. Specifically, we run an off-chain cache configured to only track information on polls where creator is in authorizedAddressList (eg [<0x1>, <0x2>, <0xabc>, ...]).

If someone were to fork our frontend and run their own instance of our backend cache, they could configure it differently. So, for example, they could pick their own set of addresses to filter by, or they could remove the filter completely — as @LongForWisdom says, there is nothing in the PollingEmitter contract that limits who can call createPoll. Really the signaling system was designed to be open in this way from the beginning and at some point i’d love to write more about how community members could create their own dashboards or cryptographically verify the foundation’s.

There’s more to say about how it all works, but i’ll leave it there for now unless there are specific questions :slight_smile:

5 Likes

Thanks for clarifying this @jparklev. I believe I’ve been told how this works before, but I can never remember the details :roll_eyes:.

I had a couple of questions.

  1. I assume that the authorizedAddressList is built to be modifiable, that addresses can be added and removed?
  2. Is the plan to relax the white-list at a later date? Or is the emphasis more on: ‘If you want open polling, build a third-party dashboard?’

I’d love to read anything you have time to write about it. It would be great to have a canonical topic about how the system works, basically the information here but in a new topic that we can link to. It could also include more detail about third-party dashboards and the options for expansion.

I think that would help to forestall future questions of this nature.

I’m digging through the archives looking for something else and found this thread. I can answer these for you:

It is modifiable.

I’m on the list currently as the Interim Governance Facilitator. Once more community members step up and formally take the reins for facilitator related tasks they will also be added to the list.

It will be up to the community to figure out how exactly they want to coordinate the custodianship I think, and how they will go about electing the people to move the proposals into the system.

Open polling is certainly an option but it’s my hope that people will choose to engage with the community and work with the processes people are building here for signalling, debate, consensus seeking etc.

We’re still trying to understand how to build the social and procedural layers of this system (I had to check the forums today to make sure I’m posting a proposal correctly) how will governance work if proposals just show up on chain without context or discussion?

This seems like a lot of work, and a lot of thought that you have put into this. Much appreciated. I don’t know where we are from community involvement perspective. Meaning do we have too many ideas people like to draw attention to and put up for serious consideration or too few? I think despite the fact that community is small there are too many ideas. I see things get mentioned in chats and forums, and that is as far as most things go today. We need some sort of an automated system where somehow the top 10 (or n) ideas each week get recognized and get in the “Signal Section” If there are too few ideas , we can lax the standards, and if there are too many ideas, we can use some sort of popularity meter, and as a last resort tie breaker, MKR holdings. At this point I think most people don’t even know how to go about getting their ideas heard or how to lobby for them. I don’t think anyone has ever solved this problem. For 5000 years governance has been pyramidal.

1 Like

I have updated the name of this process to ‘Suggested Signalling Process’ over ‘Current Signalling Process’ Having run it a few times, my feelings about it are pretty positive.

It’s a lot of work, but so far it’s produced reasonable (imo) outcomes.

Very belatedly responding to @PatrickDehkordi’s point:

I don’t believe automated systems can adequately handle this sort of process in its current form. We’ve talked about automation in relation to several processes in the org so far. In most cases the counter-argument has been: We need to figure out the process before we can even think about automating it. Put briefly, I don’t think we are there yet.

2 Likes

The signalling process so far has been useful in clarifying important issues and initiating important discussions but seems to be getting more unwieldy as the MakerDAO system is growing. I have heard mentions of looking to best-practices elsewhere for inspiration for open-source governance in the weekly governance calls.

The vTaiwan process is something that I think is worth looking into to learn from. I think it would be useful to try tease out which aspects might be most worth testing our for the current MakerDAO governance process.

One specific tool that they employ is pol.is, which is used with the goal of identifying consensus statements around complex issues. It strikes me as something which could help address some of the issues that have been coming up with the current signalling process:

  • identifying what is the rough consensus amongst the group
  • helps discuss small edge cases related to a larger issue
  • helps with the urge to repeatedly refine signalling polls and have ideas pushed on by a single person in a forum

Full disclosure: I was fascinated by the vTaiwan process after I learned a bit from a friend a few years ago, but I can’t claim to know much beyond what I can google. I’ve played around with pol.is as a tool to help with the consultation process through a civictech project with some others.

1 Like

Hello @internautderek and Welcome to MakerDAO!!!

Tell us about yourself in the Official Thread here :

If anything, you can always contact any of the Moderators, they will greatly answer your question!!!

Here for the Feedback : https://forum.makerdao.com/c/site-feedback