This is an informal guide on how to participate in the signaling process at MakerDAO by starting a signal request. Signal requests and their role in the governance process are described here.
This post covers the considerations before starting a signal request, how to construct a signal request, what the author is expected to do during the signal request and steps to follow after a signal request is concluded.
Consider starting a discussion on the forum and/or use an informal poll to gauge the community’s sentiment before starting a signal request. This step is not necessary for all issues and should always be skipped for urgent issues.
Ensure that you have sufficient time for signalling. The signal request should last at least two weeks after going live. 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 with appropriate justification and subsequent approval from GovAlpha.
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.
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.
When you create a signaling 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.
The title, post content and poll options must all be framed in neutral language. Emotional or rhetorical language should not be used. 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. For example, the poll option “No, we should not change the PPG process” is good. On the other hand, “No, the PPG process is perfect the way that it is.” is bad.
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.
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. Note that you need to add the
sig-status-active tag first or else the
signaling tag will not work
If your signal request is related to an existing discussion or to a previous signal request, add a link for readers to give them context. If your signal request is related to frequently adjusted governance parameters, then you must add a link to the Governance Parameter Documentation here (look for the appropriate parameter on the left panel).
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.
Creating a poll in the forum requires you to follow these steps. It is quite easy to create a poll that does not conform to the signal request guidelines so please follow these steps carefully.
Insert a poll using the grey gear icon highlighted in the red box in the screenshot
Next, you will see the image below. Click on the gear icon again as highlighted
You can now create a poll. The following settings are required for any signal request poll:
- Set up a
Multiple Choicepoll unless your poll only has Yes, No and Abstain as options.
- Add a neutral
Poll titlethat does not contradict with the thread title.
- Add the polling options and include an
- Ensure that each poll option says a single thing and is phrased neutrally.
- Ensure that the
Min Choicesis set to 1 and the
Max Choicesis set to the number of polling options (excluding the
Limit voting to these groupsto
- Ensure that
Show Results...is set to
Only after voting.
- Enable the
Show who votedcheckbox.
- Disable the option to
Automatically close poll.
These choices are made for the following reasons:
- There are several advantages to including an
Abstainoption 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.
- Multiple choices allow voters to back more than one option that they would be happy to support in an on-chain poll.
- Restricting voting to
trust_level_2users ensures that the signal request is not brigaded and manipulated with new accounts.
- Showing results only after voting ensures that confirmation bias is avoided. People are susceptible to voting with the majority and 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.
Before inserting your poll, check to see if all the highlighted red boxes in the screenshot below are as shown.
The markdown you see in your thread should be as below
[poll type=multiple results=on_vote min=1 max=2 public=true chartType=bar groups=trust_level_2]
# Poll Title
* Polling Option 1
* Polling Option 2
- (Optional) Has there been an informal poll and/or discussion about the issue on the forum?
- Is the signal requested limited to a single issue?
- Is the question phrased in neutral language?
- Is there a summary of essential information?
- Are you using the governance:signal-requests category?
- Have you added the sig-status-active and signaling tags in that order?
- Have you added appropriate links including to governance parameter documentation, if applicable?
- Have the lines of progress been included at the end of the signal request post?
- Poll settings
- Is the type of poll (
Multiple Choice) chosen correctly?
- Is the poll title neutral and not in contradiction with the thread title?
- Are the poll options neutrally phrased and refering to only one thing?
- Is there an
Abstainoption that voters can select?
Min Choicesset to 1?
Max Choicesset to the total number of polling options (excluding
Limit voting to these groupsset to
Automatically close poll: Xselected and no date/time given?
Show Results...set to
Only after voting?
- Is the checkbox for
Show who votedchecked?
- Is the type of poll (
If you’ve answered yes to all the questions in the checklist, congratulations! Your signal request is ready to go live.
Facilitating discussion and engagement in good faith: It is important to encourage people to participate in the signaling process and seek out opinions from both sides. Keeping the discussion going and engaging with all who participate is essential and this responsibility belongs to the thread starter. The thread starter does not have to remain neutral on the issue, but does need to run the signaling process in good faith to its conclusion.
Moving on-chain: A signal request cannot move on-chain until there is a majority for a polling option. The aim of the signaling process is to gather consensus and 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.
Note that thread starters cannot close an active signal request thread once it has gone live.
If a signal request moves on-chain, it should be summarized after all the off-chain and on-chain polls are complete. At this point the thread should be considered finished. The sig-status-active tag should be removed, and a member of GovAlpha should be pinged to set the thread to close 7 days after the last reply.
If a signal request fails to achieve consensus after two weeks, the thread will be closed by GovAlpha.
Consider also posting your question on RocketChat where any community member can help.