Suggestions for updating the Signaling Guidlines

NOTE that signal requests have 0 enforcability and primarily serve to gather discussion/opinion. Anyone can submit an executive even if the foundation does not approve. The foundation just controls the voting UI. Which is significant power, but not totally gatekeeper status.

I went with a question/answer form for discussion purposes. I just gave my opinions on the questions and expect people will have different perspectives. If the answers are deemed satisfactory I will put them into the same format as the other signaling guidelines so they can be integrated. The questions came from @LongForWisdom @Aaron_Bartsch @rich.brown me and @Sirlupinwatson1

1. Should multiple choice polls be required? Yes, it’s the standard now. It gives people more control, I can’t think of any reason they could be bad right now. Please share what I am missing in this.

2. Is a majority or plurality required in a signaling thread?
In polls with many options, a majority requirement could be too difficult to come up with, even if the poll is not contentious. A plurality should be sufficient to enter the on chain governance process, however social actions may be pursued by those in either the winning or losing option to encourage a shift to a majority result. If a contentious signal request occurs the “winners” could negotiate a compromise rather than choose to sow division. That should be left up to the individuals, hence just plurality requirement. If they believe the issue is important enough to push ahead without compromise, that is their choice.

3. Should there be other exceptions to the signaling guidelines? Besides very time sensitive Emergencies, I think not. The signaling guidelines aren’t particularly restrictive and are in an unenforceable position anyways.

4. What should the defined cadence be? I feel hamstrung on this question because of MIPs development, which includes a proposed governance cycle. However, one possibility is that cadence has to be laid out in the signal request itself. Any votes agreeing for the change would be affirming the timeline stated in the request. This allows for response to urgent situations as well as more typical, measured, governance decisions. A voting option would HAVE TO include “disagree with proposed timeline”, giving voters a chance to signal disagreement with the author on the cadence and hopefully initiate discussion for coming to an agreement in the thread. This only works if multiple choice voting is required and if the author manually determines the signals closing date (no predetermined closes).

The cadence should include:

Time allotted for discussion
(potentially indeterminable) Time needed for a proposed technical change
Expected date of inclusion as a governance poll or executive (this way we could start a “governance calendar” the request would be added to the calendar if it received the necessary plurality).

Template? A template filled out at the conclusion of the signal request would help reduce the governance facilitators work load. The issue is many signal requests differ in nature, so making a template that satisfies all the possibilities would have to be broad. Personally I think it makes sense that the author has to write the text for the governance poll AS the summary at the conclusion of the signal requests discussion period. That text should include:

Description (a couple paragraphs max):
Brief History of the signal request and related discussions:
Recap on timeline
Potential Outcomes

For signal requests with similar precedents, the author should look to those polls for examples. Since the GF actually adds the poll to the UI they will likely still need to fill details like the exact time/date. If the author cannot complete the required text they should find someone willing or notify the GF. The GF can refuse to add a signal request if they explain why the polls does not contain an adequate summary.

Additional questions from LFW from rocketchat: Should the vote be public (able to see who votes for what)? His points were that if we want rationale/scientific discussion people should be defending how they vote. Having the vote open allows for the signal thread author to call out people who vote against their proposal without providing discourse. Also this provides us a way to gauge sybil attacks.

For now I am mostly going to ignore the emergency response question. I will say the practical reality is that domain teams and groups from the foundation will push whatever spell they see as necessary in a time crunched emergency. It seems that forum debate would unlikely change the addition of a spell in those circumstances. In terms of the community we could still just follow the signaling guidelines and try and make the case for very swift action (skipping governance poll, adding emergency spell)


Some thoughts below. Generally I agree with everything, including the aim to make the signaling process more formal. In general I think it has had enough use that we have a better idea of what works and what doesn’t at this point.

Completely agree. Unless there are only two mutually exclusive options it feels like there is very little downside to this.

This one is more tricky imo. I’d prefer to push for requiring a majority before moving on anything, especially combined with point 1 (majorities are easier to form when you have multiple votes)

Unsure on this point. My preference at this stage would be to agree on a set of guidelines written in the spirit of: “Use these unless you have a good reason not to and are able to justify that reason.” That said, I’m not completely against making it a requirement either. I’d be happy with either.

Also a difficult question. I think it’s best to leave this open, as you’ve said. It allows for more flexibility. Maybe we could define guidelines for different situations?

Definitely think this should include pro and cons of the possible outcomes as far as possible, and that the creator should be prepared to add to these as discussion takes place. I’m also very keen on having the creator be as clear as humanly possible on the planned timeline for the signal thread. Something like: “This will be reveiwed on date x, at which point, y (or z, potentially) will happen.”

Ya that accurately describes my position.

There are some other points that you haven’t covered. What do you think regarding the whole ‘start general then move to specific’ principle outlined in the previous thread? Suggested Signaling Process

Would also love to hear more discussion on this, especially from those that have used this process in the past (particularly @Aaron_Bartsch and @hexonaut). Some other people that have used this is some form include @Joshua_Pritikin and @Derek and @Kurt_Barry. Would be great if they could add their thoughts.

1 Like

Oh shoot I didnt even know this existed, I thinking this would be an update to Signaling Guidelines. Ill look deeper into the one you just posted.

I agree that starting general then getting specific is good for understanding an issue, but I dont think the general part needs to happen in the context of a signal request. When starting a general discussion about an issue alot of different solutions could be brought up with varying relevance to the question in that specific point in time. So I think signal request should only really be used once the debate/possible solutions are hashed out and specific.

To the other comments:

Agree. Thats what I was trying to get at with the 0 enforcability and emergency realities thing, but probably wasn’t clear

I like the idea to define guidelines for different situation, but am having trouble conceptualizing what differences we would define and how.

I completely agree that the human should list outcomes, but I dont really think requiring pro vs con is fair because whats a pro for some stakeholders is a con for other.

Yeah I want specific dates/timeline that everyone would know about. A live governance calendar/schedule would be sweet.


Would suggest people weigh in on this if they have a spare moment. We use the signalling process for making most non-routine changes at the moment and it’s always been a work-in-progress.

Any feedback can hopefully help us to make it work better.

1 Like

It is also a little hard to be motivated to care about the signaling process when alot of people know that a whole new thing is going to be introduced soon.

1 Like