Signal Request: Precedent for on-chain polling

In this week’s governance call we began a discussion about the idea of Foundation proposals requiring a signal thread in the forums before heading on-chain.

Mariano brought up the proposal of including an SCD GSM solution into next week’s polling while Derek proposed changing executives to include a 1 month expiration starting with this weeks executive.

Both of these proposals were implied to not require a signal/proposal thread before being acted upon.

This begs the question; should Foundation proposals require signal threads before creating on-chain polling? So far we do not have precedent for changes made to the system proposed by Foundation members.

Currently, in order for community members to enact a change to the system they must: Create a signal/discussion thread on their topic. Determine consensus. Draft a proposal and have Rich post it on a Polling Monday. Have that pass and be included in Friday’s executive.

Should we skip signal threads for urgent changes only? Should every change to the system require a signal thread regardless of who is proposing it or what it is? Hopefully we can have some discussion on the merits of any of these questions/ideas and I will also include a poll with some of these options below.

What should the precedent be for on-chain poll proposals?

  • Foundation members are not required to post a signal request/forum thread before posting on-chain
  • Foundation members must post a forum thread explaining the proposal (not a signal thread/vote) before posting on-chain.
  • Foundation members must always follow the same precedent as community members
  • Foundation members may only post on-chain first if deemed urgent
  • Foundation members may only post on-chain first when the changes are of a specific nature (technical, risk, etc.). Another poll may be required to determine parameters.
  • Disagree with options provided
  • Other

0 voters

This is by no means the final poll on this matter. Unless there is clear consensus here, leading to an on-chain ratification of precedent (if required), we can continue these discussions. Let me know if I missed an option. The idea here is to create a clear precedent so we don’t have to question our procedure when a new change comes up every week. I also understand that there may still be edge cases but hopefully this will bring some clarity to our decision making process.

Thank you.

It’s too early to add more bureaucratic red tape for the foundation. I’d like to see more changes (improvements) happening faster. Deliberation is a good thing, but let’s not go overboard.

2 Likes

Don’t see why giving special status to general foundation members is warranted. It reduces transparency and increases social stratification. In this specific situation, with the SCD gov delay, the signaling process could of easily started weeks ago (or even earlier, but I believe the darkfix mechanism was the missing piece), better yet lets nail down SCD shutdown so we can stop thinking about it and the scary backdoor migration attack. To be clear I’m for getting the delay in asap, just that conveniently circumventing the established process should only happen if the foundation has a strong argument for urgent action.

If we want to give someone special permissions we should leverage the signaling process and vote on it.

Emergencies/highly urgent situations should have a different process anyways (non foundation people could catch a critical issue, right now their only effective recourse is notifying the foundation. ).

1 Like

I think all proposals must be treated the same whether coming from users or from the Foundation members. That includes technical proposals which most MKR holders probably don’t understand. For that reason - people who make a proposal must write a signal request / summary which will be linked directly on the poll/exec vote page so that voters can make an educated decision. The summary would include:

  • reasoning behind the proposal
  • benefits
  • risks
  • link to more info (roadmap, specification, discussions…)
  • voting

I would allow only serious bugs / governance attacks that could cause loss of funds to be treated differently (no signal/poll, but with the same summary as above except no voting). Maybe we could think od other serious problems that require quick action i.e. off the peg by >3% caused by some technical error…

I also don’t like to see yes/no polls (i.e. increase DC to XXX: YES/NO). It would be better to offer several options (i.e. increase DC to XXX, increase DC to YYY, leave DC as it is…) where applicable.

I agree, which I why I think foundation holders shouldn’t have to post signalling threads / polls to submit executives. We’re really lucky to have a great community here that collaborates in open discussion, but the truth is that there is nothing stopping anyone from submitting an executive at any point.

If I wanted I could (as an individual or with a team) create a contract as a spell to act on the system, deploy it, put up a website to advertise it, and solicit votes, with or without a poll on this forum. Maybe there are more actions that need to be taken to ensure fair governance (like adding rank voting) but I don’t want to pretend that this nice process we have is doing that.

If you don’t want the foundation to submit a an executive without a signalling thread don’t vote for their executive if it wasn’t preceded by a signalling thread. I bet community members would agree and you could boycott this action. We could also consider adding some incentive not to do this, like requiring the deposit of a bond along with a proposed executive, that is recovered with interest if the executive passes. This would be a bigger change and maybe not worth bringing up right now but if fair process is important to the community I think we can come up with better ways to enforce it.

Unrelated to my previous points, but I also think signalling threads aren’t a fair measure because they aren’t equally accessible. This forum, and Maker as a whole, happens in English. This excludes a lot of people from participating and being heard.

Yeah anyone can do this, making enforcement of any process precedent very difficult. The foundation just controls the UI for the voting portal, but as you mentioned, you could just make another website.

For me this discussion is more about if we want to value transparency going into the future. Yes anyone can propose anything in a spell, but how will those contents be communicated to everyone going forward? Few people read the code. For governance to scale we probably want some standards around how different types of changes happen (technical, process change, monetary). For those standereds to be useful (communicative) they have to be transparent and consistent.

I would like us to value transparency but I think there are other ways we can express this. Right now I value transparency by staking my Maker on proposals I trust and appreciate. I have started reading more of the code, but it is a lot to consume. I enjoy it, so it makes sense for me to do, but it doesn’t make sense for everyone to do this

Maybe an individual or firm could advertise there expertise as contract / spell auditors. They could then accept MKR that take voting rights but only have the ability to vote or return it to the depositor. They then earn an interest on MKR they are holding and voting on behalf of.

This is off the top of my head so I’m sure there are plenty of problems with this idea and plenty of ways to solve those problems. I don’t think we all need to vote on every decision for governance to be fair, in fact I don’t think that would scale. I do appreciate the current signalling polls though and I don’t want governance forced on anyone.

So to explain my position some.

Signal requests are good at finding a consensus option among a group of people. They are most useful when there are lots of options to fix a problem, and you need to find the option that is most agreeable to most people. The downside of running them is that they are time consuming.

Generally, when the Foundation submits a proposal, they have a specific idea in mind already, work has already been done, etc. This should absolutely be explained to the community on the forum, such that they have a chance to consider the merits of the change and object if they want to do so. It should absolutely go to an on-chain poll so that MKR Holders can weigh in atomically (not bundled with other changes in the executive immediately).

In my eyes by skipping the signalling stage we are skipping the ‘proposal creation’ stage because there is already a proposal ready to go. We aren’t skipping important voting stages because they happen on-chain.

If the on-chain vote fails for any reason, then we should go back to creating a signalling thread. And if there is doubt in the Foundation’s minds about whether the community wants a change, or if they want community input into a proposal then they can optionally run a signalling thread.

2 Likes

To expand on a point that Mitote and I discussed on the chat. It would be better if we could empower Interim Domain Teams with this power rather than the Foundation as a whole.

But for that to happen we’d need to officially make the Foundation Dev Team into the Interim Dev Team and figure out who was part of that team.

1 Like

The core part of the signaling process is the forum vote right? If they are going to post an explanation of a proposal in the forum, why skip the voting step? Its basically a signal request at that point anyways if they are looking for objections. Voting gives a concrete signal of objection for community members. Not everyone has a meaningful amount of MKR.

You make a good point. My argument was going to be that the signal request takes too much time, but then I remembered that the whole point of it taking that long was to give people enough time to express their thoughts.

I’ll think about this some more.

1 Like

The poll tells the community that they need to vote for an outcome in order for it to proceed/pass. It is not clear cut that a forum post requires a poll because one is asking for permission and the other is informing on-chain voters of the details they will be voting on. Also, one is faster and one is slower.

@Mitote Are you saying , “Just throw the poll in there even if its going on-chain right away anyways to get a read on community sentiment.”?