[Discussion/Feedback] Improving Clarity Regarding Signal Request Outcomes

This post is a follow-up to some concerns that were raised in this Signal Request thread and on Discord regarding Signal Request Outcomes.

Introduction

To summarise, this Signal Request asked whether we should gradually increase over time (lerp) the Surplus Buffer and, if so, how much it should grow by each week.

The day before the Signal Request was due to finish, two options favouring lerping the Surplus Buffer had received 48.3% of the non-abstain votes, and the option for “no lerp” had received 32.2% of the non-abstain votes. However, none of the options favouring lerp met the 50% threshold for inclusion in an on-chain poll. This result would have led to no lerp option being included on-chain, despite Maker Governance having preferred this outcome.

Once GovAlpha became aware of this potential outcome, an internal discussion occurred where we decided to highlight this discrepancy to Maker Governance both on Discord and on the Forum. By doing this, we felt that we were providing Governance participants with the required information to make an informed decision on this Signal Request. Ultimately, the vote distribution changed, and two options in favour of lerp proceeded on-chain.

Signal Request Overview

Signal Requests fall into two categories:

  • Binary polls where the question can be answered with yes, no, or abstain. Binary Signal Request Example.
  • Non-Binary polls where multiple options are presented to Governance and voters may choose multiple options. This is a form of Approval Voting where voters vote for all the outcomes they deem acceptable. Recent Non-Binary Signal Request Example.

Whichever form the poll takes, only options that receive more than 50% of the non-abstain votes will proceed to an on-chain vote. In the case of a non-binary poll, multiple options may cross this threshold, and in this situation, an instant-runoff vote will occur on-chain.

This threshold helps reduce on-chain overhead and attempts only to introduce votes on-chain where Governance has expressed a clear majority preference for one or more of the potential outcomes.

If none of the options reaches 50%, the Signal Request is considered to have failed, and none of the options proceed to an on-chain vote.

Improving Clarity Surrounding Signal Requests

Following a discussion at the weekly GovAlpha Core Unit Meeting, we feel that the 50% threshold for on-chain inclusion is appropriate, and we would like to keep this in place. However, we concede that communication regarding these issues could have been better and will be looking to improve things going forwards.

Current suggestions for improvement in this area include:

  • Early on in the course of a non-binary Signal Request, a GovAlpha CU member will highlight what will happen if none of the options reaches 50%. In this example, we would have highlighted earlier in the thread that if none of the lerp options reached 50% of non-abstain votes, there would be no lerp option on-chain.
  • Approximately halfway through a Signal Request, a GovAlpha CU member will summarise the current non-abstain votes on the Signal Request to allow voters to make more informed decisions and change their votes if they wish.
  • At the end of a Signal Request, a GovAlpha CU member will summarise the non-abstain votes and explain what options are proceeding to an on-chain vote. Example of such a post.

We hope that improving our communication on these Signal Requests will provide greater clarity surrounding the Signal Request process and empower Governance to make more informed decisions. We will strive to remain neutral in Signal Requests as per the GovAlpha mandate.

Points for Discussion

Do you agree with the above suggestions?

Are there any other changes you would like to see regarding the Signal Request process?

Do you have any other concerns about Signal Requests that you would like to raise?

cc: @GovAlpha-Core-Unit @Davidutro @JustinCase

4 Likes

I think this is a good temporary solution, but it’s not very scalable. If nothing else we should eventually switch to having a bot do this so it doesn’t require a bunch of manual labor.

1 Like

A bot would be great. I’m not sure if a bot will be able to parse a Signal Request and figure out what would happen in the event no option reaches 50%, but it would be really helpful for helping to tabulate votes!

1 Like