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...

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 signaling and active-signal.

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.

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.

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