Practical Guide to the Signaling Process

It’s been a while since the signalling guidelines were last iterated on, and in their initial form, they were rather rough ideals, rather than practical instructions on how to create a good signal. This post aims to act more as a how-to and best practices guide that signals should follow. It is divided into sections of what a signal thread must do, and what a signal thread should do.

I may add more things to this list as they occur to me. Any objections or comments, feel free to leave them as replies and I’ll update.

A signal thread must…

Use the correct category
The #governance:signal-requests category should be used for all signal requests. Using the same category for signal requests allows them to be accessed separately from the rest of the governance threads and helps keep everything organised. It also allows a custom post template which can help point people in the direction of the Signal Request resources.

Have the correct tags
Using the same tag across the forum makes it easy to find all the signaling topics, it helps keep everything organised, it helps the community see if there are things to signal on, etc etc. The two tags that should be attached to a new signal are sig-status-active and signaling.

Be limited to a single issue
This keeps the topic from becoming a confused mess of different conversations. This is not to say that there must be only one poll, only that all the polls should seek signals on the same issue.

Be run and kept up to date by the thread owner
A party needs to both maintain and push a signalling thread to its conclusion. This responsibility falls on the original poster of the polling thread. The original poster does not have to remain neutral on the issue, but does need to run the process in good faith to its conclusion.

Have clear lines of progress provided by the thread owner
The next steps of a signal thread should be communicated by the thread owner whenever anything changes. This can be as simple as a one-line comment explaining what will next happen, and when it will next happen.

Have a title in the form of a neutral question
Giving the topic an appropriate title makes it easy to see what the signal is about. Neutral framing is to ensure that you do not prejudice other community members into voting a particular way. This is vitally important no matter how strongly the author feels about the topic.

Use the following settings for any polls:

  • Results: Visible On Vote
  • Show who voted: Enabled
  • Automatically Close Poll: Disabled

People are susceptible to voting with the majority. Conformity bias is a real thing, hiding the results until after someone votes provides an extra incentive for voters to think critically about the issue for themselves. Making votes public after a vote has been cast allows the thread owner to prod dissenting signals to provide reasons for disagreement. Polls should not be automatically closed as it reduces flexibility.

Include an 'Abstain option
There are several advantages to including an abstain option in a signal request. Firstly, it allows voters to signal ambivalence or protest in a active way. It also allows the Governance Facilitators to check the results of the vote in-progress while remaining neutral.

Have a completed template for the on-chain poll posted by the thread owner
This allows the governance facilitator(s) to post it on-chain without having to re-write or summarize the issue in a way that may induce bias. This avoids the possibility of misinterpretation and allows the debate participants the chance to vet the wording of the poll. PR’s are preferred for those who are familiar with git.

The deadline for submitting a PR for a on-chain poll on any given Monday is end of day on the prior Wednesday.

Be summarized by the owner
This step should only occur after all off-chain polls have been completed and the on-chain poll has been completed. At this point the thread should be considered finished. The active-signal tag should be removed, and a moderator should be pinged to set the thread to close 7 days after the last reply.

A signal thread should...

Last at least two weeks
Anything less than two weeks does not give governance participants a decent chance to signal on the issue. Many participants do not frequent the forum every day, or even every week. In some situations however, the issue is urgent and some signal is better than no signal at all. In these cases, this two week length should be ignored.

Use the following poll settings:

  • Type: Multiple Choice
  • Min: 1
  • Max: Total Number of polling options

Using multiple choice makes it easier to find consensus on options, as everyone can vote for whichever set of options they would be willing to vote for on-chain. It should be used wherever possible. The exception to this is where the polling options are obviously mutually exclusive.

Begin with a summary of the essential information
This should take the form of a advantages/disadvantages, pros/cons, positives/negatives to the area being discussed and should be kept up-to-date as the thread progresses. In order to signal, the community should not need to read through the entire discussion, only the initial post. It is the thread owners responsibility to keep this summary as balanced and succinct as possible.

Aim to create consensus
When you create a signalling thread, you are trying to gather consensus around a specific proposal, be aware that the proposal may need to compromise to suit as much of the community as possible. The aim is consensus rather than majority-rule, if there is irreconcilable disagreement, the proposal needs to change.

Aim to follow the process laid out here
This process is not always fully applicable, but it provides a start-to-end set of suggested steps for going from ‘We have no information about consensus on this issue’ to ‘We know exactly where consensus lies on this issue.’

Not move on-chain until there is a majority for a polling option
The aim of the signalling process is to gather consensus, if it fails to do so then it has not achieved its aim. That said, it is difficult to argue against the poll moving on-chain if a polling option has a majority voting for it.

Garnering significantly greater than a 50% majority should always be an aim for the thread owner. The closer the thread is to consensus in the polling stage, the more likely it will pass on-chain.

In rare cases a plurality may be sufficient for a poll to move on-chain, however this should only be done if there is a clear reason of urgency

Discussion: WBTC-B collateral type, backed by B.Protocol with x10 leverage
MIP24: Respuesta de Emergencia
MIP24: Emergency Voting System (Replaces MIP 5)
MIP24: Emergency Voting System (Replaces MIP 5)
[Signal Request]Increase Risk Premium for USDC as risk increased due to over collateralization
What are Signal Requests?
[Agenda/Discussion] Scientific Governance and Risk #109 - Thursday, September 10 16:00 UTC
MakerDAO Standard Governance Processes
[Signal Poll] Use multiple stablecoin (e.g. USDC) vaults with different LR/DC combinations to manage value/price/risk exposure
[Informal Poll] Should we take Emergency action to fix the peg by changing USDC-B vault instead of USDC-A?
[Informal Poll]: Print 30m unbacked dai and use to buy and burn MKR. Pay back once peg is restored through SF income
[Informal Poll] Offering DAI borrowers MKR to increase borrowing
[Signal Request] Dai is at 1.04, going towards 1.05. Should we fix the peg with an emergency vote to lower stablecoin LR and increase stablecoin DC?
Liquidations 1.2 Parameter Analysis
Emergency / Urgent Governance Process
Signal Request: Add a DC Trigger for planned raises
Governing Debt Ceilings
Signal Request: Should we fast track MIP10c9-SP6: yEarn ETH/USD OSM Whitelisting?
Signal Request: Should we fast track MIP10c9-SP6: yEarn ETH/USD OSM Whitelisting?
[Signal Request] Public Commitment to Restoring PEG
[Poll] Should MakerDAO print unbacked DAI to solve the peg issue?
Signal Request: Add ETH-B Vault
TUSD Update (Forum Poll): Concerns Surrounding the TUSD Collateral Type
[Signal Request] Should we raise WBTC Debt Ceiling?
Emergency Debt Ceiling Raises
[Signal Request] Increase duration of governance security module?
[Agenda/Discussion] Scientific Governance and Risk - Thursday, May 28 9AM PST (4:00 PM UTC)
[Signal Request] Change Monetary Policy Votes to Ranked Choice
[Signal Request] Change Monetary Policy Votes to Ranked Choice
Signaling Guidelines (Old)
Signaling Guidelines (Old)
Should mkr agressively expand onto to other platforms
MIP4c2-SP11: MIP24 Amendments
MIP4c2-SP11: MIP24 Amendments
Maker Stability Module, inspired by Aave and Synthetix

Added the requirement to include an abstain option. This is a relatively costless improvement, and it makes my life much easier as I can see the results without having to vote.


Should it be mentioned that you need to submit the poll’s github pull request by Friday if you want it to be included in the next week’s governance poll?


Yep good call, I’ll add that soon, thanks.

1 Like

Added: “The deadline for submitting a PR for a on-chain poll on any given Monday is end of day on the prior Wednesday.”

Thanks again for the reminder @Jiecut

For clarity’s sake. The deadline is set to the prior Wednesday as that allows for:

  • Review from stakeholders on Thursday, followed by any changes.
  • Submission into the frontend on Friday for
  • deployment on Monday.

This avoids the Governance Facilitators having to do the submission process during the weekend, which is not ideal.

1 Like

Updated to reference new signal request category.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.