MIP24: Emergency Voting System (Replaces MIP 5)

[Jtathmann]

Note: @Jtathmann took a break, this MIP is currently being lead by @Davidutro

---

Hello Friends!

I wrote up a MIP in hopes to create a consistent (but flexible) procedure when dealing with emergencies and other urgent issues.

There have been multiple expedited changes and proposals recently (PSM discussion, urgent configuration changes, WBTC bug, multiple debt ceiling increases, and oracle whitelisting). Unfortunately, they were all handled a little differently, which caused some confusion and were generally inefficient.

I reviewed some of the more recent emergencies to see how they were handled, and wrote up these procedures in a way that could be applied to all of them. I would really appreciate your feedback, as a lot of this is intentionally vague.

Thank you!

MIP24: Emergency Voting System

Preamble

MIP#: 24
Title: Emergency Response
Author(s): @Davidutro, @jtathmann 
Contributors:
Type: General
Status: Formally Submitted
Date Proposed: 2020-09-07
Date Ratified: <yyyy-mm-dd>
Dependencies:
Replaces: MIP 5

References

MIP5: Emergency Voting System
Forum Thread: Emergency / Urgent Governance Process
Forum Thread: Covid Crash: Emergency Governance Summary

Sentence Summary

MIP24 defines emergency and urgent situations for the Maker protocol, as well as the process for handling them.

Paragraph Summary

This proposal defines an emergency voting system. Emergency votes are executive votes that can be initiated by any community member. This MIP aims to provide a general guide that can be applied to a wide range of urgenct situations. Additionally, this MIP will differentiate between an emergency and an urgent situation, and provide processes which can be carried out to deal with either consistently.

Component Summary

MIP24c1: Situation Definitions

Defines the terms “urgent” and “emergency” for purposes of an expedited governance change.

MIP24c2: Considerations of Expedited Protocol Changes

Outlines the various considerations that should be made before enacting expedited changes.

MIP24c3: Emergency Response Procedure

A general procedure for managing emergency situations.

MIP24c4: Urgent Response Procedure

A general procedure for managing urgent situations.

MIP24c5: Role of Governance Facilitators

Outlines the tasks of the Governance Facilitators during emergency interventions.

Motivation

The protocol has often required changes outside of the standard weekly and monthly governance cycles to help maintain the peg or to respond to changes in the ecosystem. The goal of this MIP is to provide a consistent process to manage emergencies and urgent issues.

Specification / Proposal Details

MIP24c1: Situation Definitions

The procedure for managing expedited changes to the protocol will depend on whether a situation is classified as an emergency or urgent.

Emergency: Any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the ecosystem.

Urgent: Any situation that includes a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

MIP24c2: Considerations of Expedited Protocol Changes

There are several important factors to consider before expediting changes to the protocol.

• Potential for MKR holders to miss a poll or executive vote due to departure from the standard governance cycles.
• Expedited votes may not allow for sufficient discussion, leading to a sub-optimal solution.
• Increased governance burden on community and increased workload for domain teams.
• Frequent expeditate votes may signal a lack of appreciation for a consistent and predictable governance process.

MIP24c3: Emergency Response Procedure

The ability to declare an emergency will be reserved for Domain Teams and Governance Facilitators due to their proximity to, and knowledge of, the Maker Protocol and surrounding ecosystem. If a community member wishes to declare an emergency, they will follow the urgent response procedure outlined in MIP24c4. If a Governance Facilitator agrees that the status of the urgent situation should be escalated to “emergency,” they will do so.

The emergency response process will be initiated as follows:

Declare an emergency in the public forum providing sufficient detail regarding the issue and why immediate action is required. If time does not permit, a forum post will be created immediately after or in parallel to taking emergency action. Creating a signal request thread or governance poll is optional.

• If a remedy is known and uncontentious the Governance Facilitators will coordinate with necessary domain teams to expedite an executive vote.
• If a remedy is not known or is contentious the Governance Facilitators will coordinate an emergency governance call to discuss solutions and a plan for subsequent actions, explicitly inviting known stakeholders.

MIP24c4: Urgent Response Procedure

An urgent response may be requested by any community member if they believe the system is experiencing an emergency or urgent situation as defined in MIP24c1.

The urgent response process will be initiated as follows:

The process will be initiated with a signal request thread in the public forum stating the need for expedited governance action and include the following:

• Sufficient detail regarding the issue.
• Proposed action or request to discuss what action governance should take.
• Signal Poll to gauge community sentiment of whether urgent action is needed.
• Tag @Gov-Facilitators at the bottom of the post, so that they will be notified and oversee discussion.

Signal Poll Requirement

Any signal poll must adhere to the practical guide as closely as possible given the circumstances for the change.

• In order for the community to make a change to a system parameter, a signal request must reach a 50% majority and have a reasonable quorum of voters given recent participation.
• In order for the community to make a change outside of the existing system parameters, a signal request must reach a 66% majority and have a reasonable quorum of voters given recent participation.

Mandated Actor Responsibilities

If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a governance poll for MKR holders or to advance an executive vote, at their discretion.

At any time during the urgent response procedure a Domain Team or Governance Facilitator may elevate the status to an emergency. At that time, the procedure in MIP24c3 will be carried out.

MIP24c5: Role of Governance Facilitators

Governance Facilitators will oversee emergency and urgent situation processes to ensure they are carried out in a civil and consistent manner. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency voting system, and may block a request for emergency action at their discretion.

[Planet_X]

How does your proposed MIP relate to MIP5 - Emergency Voting System? https://github.com/makerdao/mips/blob/master/MIP5/mip5.md

[LongForWisdom]

Accidentally submitted this before finishing. More on the way…

Aight will do my usual and just read through and provide comments.

@Jtathmann

MIPX Emergency Response

Titles are traditionally: ‘MIPX: Name’

@Jtathmann

Type: Process

Technically this is a General mip. Types are not super well defined, but in general:

• Process = MIP that has it’s own sub-proposals.
• Technical = MIP that includes code changes.
• General = Anything else.

@Jtathmann

Date Proposed: <yyyy-mm-dd>

Should be September 7th

@Jtathmann

Sentence Summary / Paragraph Summary

Don’t use bullets for these. It’s one item by itself, no need for it.

@Jtathmann

The Emergency Response MIP outlines the processes of implementing changes to the protocol outside of standard governance cycles.

I feel like ‘but within the agreed MIPs framework’ should be appended to this. Mainly because some changes can be made completely outside of everything (random person putting up random executive.) And some changes can be ‘urgent’ or ‘emergency’ but still follow ratified processes.

@Jtathmann

consistent manor.

manner.

@Jtathmann

Component Summary:
Defines the terms “urgent” and “emergency”
Outlines the various considerations that should be made before enacting expedited changes.
Outlines the tasks of the Governance Facilitators during emergency interventions.

So most of these are fine. I would maybe re-word one or two of them with this in mind: These might be read outside of the context of this MIP in the future, meaning that they should include some level of context and be understandable without having read the rest of this MIP. Like if you see MIPXc1 and you hover over it and it says ‘Defines the terms “urgent” and “emergency”’ you don’t know the context for that, and it doesn’t help a whole lot towards understanding the MIP.

@Jtathmann

Increased governance burden on domain teams and community.

So this isn’t just a governance burden. Taking emergency or urgent action generally creates more work for all of the affected domain teams. Obviously sometimes this is necessary. Maybe ‘increased workload on domain teams’? And governance burden for community?

@Jtathmann

The ability to declare an emergency will be reserved for Domain Teams and Core Personnel due to their proximity to, and knowledge of, the Maker ecosystem.

Mmm, technically this includes the MIP Editor, which I’m not sure is correct? There shouldn’t really be any MIP related emergencies. Though perhaps @charlesstlouis can think of one

Like I’m also not certain that this justification is correct. The justification is primarily because they have been ratified to a role which in its definition / mandate says something along the lines of ‘These people should act to secure / protect the protocol in emergency situations.’ Writing that, I have no idea if this is technically in the current mandates. But it really should be if it isn’t.

@Jtathmann

Declare an emergency in the public forum providing sufficient detail regarding the issue and why immediate action is required. Creating a poll for community sentiment, feedback, or parameter changes is optional.

• If a remedy is known and uncontentious the Governance Facilitators will coordinate with necessary domain teams to expedite an executive vote.
• If a remedy is not known or is contentious the Governance Facilitators will coordinate an emergency governance call to discuss solutions and a plan for subsequent actions.

So remove the top-level bullet point, for starters.

I feel like there are a couple of points this should address:

• In an emergency situation, there is not always time to write a forum post in advance. Can you make clear that this should be done first if there is time, and immediately after / in parallel if there is not?
• Regarding polls, can we be specific as to on-chain versus signal requests.
• I would also say that convening an emergency governance call should be presented as a judgement call on behalf of the facilitators. (but include a list of considerations to take into account.)
• I’d present polling in the same format as my last point. As in: ‘This is a judgement call’ but these are the considerations.

@Jtathmann

Poll to gage community sentiment of whether urgent action is needed.

gage -> gauge

@Jtathmann

dentify the quorum needed to participate in the poll to validate the outcome.

• Governance Facilitators will confirm the quorum is sufficient given recent community activity.

Quorum probably doesn’t have to be confirmed in advance (facilitators can respond confirming it?). Maybe make a requirement to inform the facilitators?

@Jtathmann

If this requires a poll, the practical guide to the signaling process will be followed.

Requires elaboration, imo. The practical guide suggests a 2 week minimum.

@Jtathmann

If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a confirmation poll for MKR holders.

Might also go straight to executive? Not sure if this is sensible if it’s community sourced. Probably depends ont he circumstances. Leave it up to the facilitators?

@Jtathmann

At any time during the urgent response procedure a Domain Team or Core Personnel may elevate the status to an emergency. At this time, the procedure in MIPXc3 will be carried out.

Good, this makes sense.

@Jtathmann

Governance Facilitators will oversee emergency processes to ensure they are carried out in a civil and consistent manor. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency process.

manor -> manner.

So the final sentence needs to go further. It isn’t just the governance facilitators job to identify abuse, they also need to decide whether abuse of the procedure justifies blocking the action (and then potentially blocking it). Fallback can always be removal of facilitators in extremis using MIP5 (I think?)

---

So, what’s there seems great generally. We’ve discussed having some sort of classification system previously beyond urgent / emergency. I’m not sure whether this is beneficial. But I like the idea of having a defcon-like system. Either numeric, or possibly some more intuitive naming convention. Maybe based on animals and how dangerous they are? Colours? Traffic light system? etc.

I’m also not sure this covers on-going emergencies as well as it could? For example after Black Thursday, we had a whole bunch of responses in the subsequent week. Would it be worth adding some sort of process for dealing with aftermath or ongoing urgencies / emergencies?

I think that about covers my thoughts for now.

[Jtathmann]

@Planet_X

How does your proposed MIP relate to MIP5 - Emergency Voting System? https://github.com/makerdao/mips/blob/master/MIP5/mip5.md

My interpretation, is that MIP5 allows for emergency actions to take place. The Emergency Response MIP is aimed more at a framework/procedure for how those emergencies are initiated/communicated, and separating emergency actions from urgent actions.

[Jtathmann]

Updated with @LongForWisdom suggestions.

A few things I haven’t updated yet:

@LongForWisdom

@Jtathmann

Declare an emergency in the public forum providing sufficient detail regarding the issue and why immediate action is required. Creating a poll for community sentiment, feedback, or parameter changes is optional.

• If a remedy is known and uncontentious the Governance Facilitators will coordinate with necessary domain teams to expedite an executive vote.
• If a remedy is not known or is contentious the Governance Facilitators will coordinate an emergency governance call to discuss solutions and a plan for subsequent actions.

So remove the top-level bullet point, for starters.

I didn’t make this update, yet, because I like the encompassing nature of these two statements. I don’t believe there can exist an emergency that does not fall within these parameters.

@LongForWisdom

I would also say that convening an emergency governance call should be presented as a judgement call on behalf of the facilitators. (but include a list of considerations to take into account.)

I also like the way these statements are sorted because it provides clear, yet general guidelines for when there should be an emergency call. If something were an Emergency that did not have a solution or was contentious, I don’t believe discussion on the forum would be sufficient.

@LongForWisdom

Mmm, technically this includes the MIP Editor, which I’m not sure is correct? There shouldn’t really be any MIP related emergencies. Though perhaps @charlesstlouis can think of one

It seems odd to me that all ratified members would have the authority to declare emergencies except the MIP editor. I’d be more inclined to include the MIP editor just in case all other members are incapacitated, even if it is rarely used. Might come in handy some day

Still working!

[LongForWisdom]

@Jtathmann

I didn’t make this update, yet , because I like the encompassing nature of these two statements. I don’t believe there can exist an emergency that does not fall within these parameters.

I meant just don’t use the actual bullet point syntax for top level points. The content of the statements is fine.

Some Header

• This is a bad top-level point
  • Bad
  • Bad

Some Header
This is a good top level point

• Good
• Good

[Davidutro]

I feel like this should be proposed as a MIP5 amendment

[Jtathmann]

How I understand this, it would be cleaner to make this MIP dependent on MIP5.

I think the addition of this procedure would exceed MIP4c1’s guidance of only using amendments for minor changes.

MIP4c1: Purpose Description

Amendments MIP Amendments that preserve the MIP number can be performed as long as there are no changes to the logic of the MIP or to the MIP’s external output dependencies. They should only be used when minor changes are required.

I’m not married to this stance though

[Davidutro]

You’re right, doing this is an amendment would be an enormous change to MIP 5.

I think, in general, MIP 5 should go through a full rewrite with your proposed MIP 24 in mind. At the moment MIP 5 is for the “Emergency Voting System” and only outlines two things

• How to remove a rogue Governance Facilitator
• How Governance Facilitators handle an “Emergency vote”

The latter is what MIP 24 basically expands upon. The former is an emergency personnel removal process.

@LongForWisdom what would be the right way to go about a full rewrite of an existing MIP, because this is def more than minor changes. I’m not sure an amendment here makes sense.

[charlesstlouis]

There are two other methods you can use to replace/re-write a MIP:

1. (Proactive Approach) As MIP0c5: MIP Replacement Process states, when a MIP is proposed, it can define one or more replacement targets (already existing MIPs/MIP-SPs) in its preamble. If the MIP goes through the governance cycle successfully and is given the Accepted status, the replacement target(s) then receive the Obsolete status and effectively become inactive. The replaced MIP will in its MIP document contain the number of the MIP that replaced it, and other MIPs that depend on the replaced MIP will instead interact with the new MIP.
2. Using MIP4c3: MIP Removal Process, you can remove an already Accepted MIP using the MIP4c3 subproposal process. This process is meant to be used for removing MIPs that are no longer useful. Once the subproposal to remove a MIP goes through the governance cycle successfully, the MIP is effectively removed from use. In parallel or after it has been removed, you may create a new MIP to replace the old/outdated version of the proposal. Note that if there are other MIPs that depend on a MIP that is being removed, they must also be removed in the same governance cycle, or the proposal will be invalid.

[Davidutro]

Thanks Charles, that’s super helpful.

I think the best course of action is the proactive approach.

I may tackle a rewrite, @Jtathmann, combining MIP 5 and this proposed MIP 24.

Shouldn’t be too hard imo. DM me on rocket and I can send you the working doc. Or vice versa :))

[Davidutro]

MIP24: Emergency Voting System

Preamble

MIP#: 24
Title: Emergency Response
Author(s): @Davidutro, @jtathmann 
Contributors:
Type: General
Status: <Assigned by MIP Editor>
Date Proposed: 2020-09-07
Date Ratified: <yyyy-mm-dd>
Dependencies:
Replaces: MIP 5

References

MIP5: Emergency Voting System
Forum Thread: Emergency / Urgent Governance Process
Forum Thread: Covid Crash: Emergency Governance Summary

Sentence Summary

MIP24 defines emergency and urgent situations for the Maker protocol, as well as the process for handling them.

Paragraph Summary

This proposal defines an emergency voting system. Emergency votes are executive votes that can be initiated by any community member. This MIP aims to provide a general guide that can be applied to a wide range of urgenct situations. Additionally, this MIP will differentiate between an emergency and an urgent situation, and provide processes which can be carried out to deal with either consistently.

Component Summary

MIP24c1: Situation Definitions

Defines the terms “urgent” and “emergency” for purposes of an expedited governance change.

MIP24c2: Considerations of Expedited Protocol Changes

Outlines the various considerations that should be made before enacting expedited changes.

MIP24c3: Emergency Response Procedure

A general procedure for managing emergency situations.

MIP24c4: Urgent Response Procedure

A general procedure for managing urgent situations.

MIP24c5: Role of Governance Facilitators

Outlines the tasks of the Governance Facilitators during emergency interventions.

Motivation

The protocol has often required changes outside of the standard weekly and monthly governance cycles to help maintain the peg or to respond to changes in the ecosystem. The goal of this MIP is to provide a consistent process to manage emergencies and urgent issues.

Specification / Proposal Details

MIP24c1: Situation Definitions

The procedure for managing expedited changes to the protocol will depend on whether a situation is classified as an emergency or urgent.

Emergency: Any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the ecosystem.

Urgent: Any situation that includes a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

MIP24c2: Considerations of Expedited Protocol Changes

There are several important factors to consider before expediting changes to the protocol.

• Potential for MKR holders to miss a poll or executive vote due to departure from the standard governance cycles.
• Expedited votes may not allow for sufficient discussion, leading to a sub-optimal solution.
• Increased governance burden on community and increased workload for domain teams.
• Frequent expeditate votes may signal a lack of appreciation for a consistent and predictable governance process.

MIP24c3: Emergency Response Procedure

The ability to declare an emergency will be reserved for Domain Teams and Governance Facilitators due to their proximity to, and knowledge of, the Maker Protocol and surrounding ecosystem. If a community member wishes to declare an emergency, they will follow the urgent response procedure outlined in MIP24c4. If a Governance Facilitator agrees that the status of the urgent situation should be escalated to “emergency,” they will do so.

The emergency response process will be initiated as follows:

Declare an emergency in the public forum providing sufficient detail regarding the issue and why immediate action is required. If time does not permit, a forum post will be created immediately after or in parallel to taking emergency action. Creating a signal request thread or governance poll is optional.

• If a remedy is known and uncontentious the Governance Facilitators will coordinate with necessary domain teams to expedite an executive vote.
• If a remedy is not known or is contentious the Governance Facilitators will coordinate an emergency governance call to discuss solutions and a plan for subsequent actions, explicitly inviting known stakeholders.

MIP24c4: Urgent Response Procedure

An urgent response may be requested by any community member if they believe the system is experiencing an emergency or urgent situation as defined in MIP24c1.

The urgent response process will be initiated as follows:

The process will be initiated with a signal request thread in the public forum stating the need for expedited governance action and include the following:

• Sufficient detail regarding the issue.
• Proposed action or request to discuss what action governance should take.
• Signal Poll to gauge community sentiment of whether urgent action is needed.
• Tag @Gov-Facilitators at the bottom of the post, so that they will be notified and oversee discussion.

Signal Poll Requirement

Any signal poll must adhere to the practical guide as closely as possible given the circumstances for the change.

• In order for the community to make a change to a system parameter, a signal request must reach a 50% majority and have a reasonable quorum of voters given recent participation.
• In order for the community to make a change outside of the existing system parameters, a signal request must reach a 66% majority and have a reasonable quorum of voters given recent participation.

Mandated Actor Responsibilities

If the signal for an urgent response passes, Governance Facilitators will coordinate with necessary domain teams to expedite a governance poll for MKR holders or to advance an executive vote, at their discretion.

At any time during the urgent response procedure a Domain Team or Governance Facilitator may elevate the status to an emergency. At that time, the procedure in MIP24c3 will be carried out.

MIP24c5: Role of Governance Facilitators

Governance Facilitators will oversee emergency and urgent situation processes to ensure they are carried out in a civil and consistent manner. They will be responsible for confirming poll outcomes and identifying whether the community or external actors have attempted to abuse or game the emergency voting system, and may block a request for emergency action at their discretion.

[charlesstlouis]

My initial comment:

• If @Jtathmann agrees with the changes, the actual MIP itself will need to be updated in John’s original post as well as a PR to update the proposal on Github (on the RFC branch).

I will follow up with some more comments tomorrow on the content.

[LongForWisdom]

Went through and made some comments. Thanks David!

@Davidutro

MIP24 defines emergency changes to the protocol and Governance Facilitator role and how they should be handled in practice.

This makes it sound like there are emergency changes to the facilitator role, which isn’t the case.

@Davidutro

Urgent: Any situation where the system would benefit from an expedited governance process, where following the standard governance cycles would yield an insufficient response.

I feel like this might be too vague. One could argue that all changes would benefit from an expedited governance process. What makes a response insufficient?

@Davidutro

Frequent emergency actions may demonstrate lack of control in the governance process.

Not sure I would phrase this as a lack of control. Maybe a lack of appreciation for consistent and predictable governance?

@Davidutro

Tag Governance Facilitator

@Gov-Facilitators is the correct tag to notify the facilitators group.

@Davidutro

Urgent Response Procedure

Can you include some of the points in the Emergency / Urgent Governance Process thread in this section please? Mainly the following (some of it is covered in MIP24c5, which is probably sufficient.)

In order for the community to make an emergency change to a system parameter a signal request must reach a 50% majority and have a reasonable quorum of voters given recent participation.

In order for the community to make a change outside of the existing system parameters, a signal request must reach a 66% majority and have a reasonable quorum of voters given recent participation.

Any emergency signals must adhere to the practical guide as closely as possible given the circumstances for the change.

Ultimately, the governance facilitators will make the call as to whether the community or external actors have attempted to abuse or game these requirements when determining whether a poll or executive is warranted.

I would also consult this post: Covid Crash: Emergency Governance Summary specifically the final section.

@Davidutro

An emergency removal of Governance Facilitator(s) executive vote contains sufficient detail about the reason for removal and logic that stops any payment stream to the particular governance facilitator(s).

Executive spells only include code. Maybe clarify that this should be specified in the copy accompanying the executive vote.

@Davidutro

If the executive vote gets the most MKR votes and becomes the active proposal the stated Governance Facilitator(s) are then removed.

This isn’t correct under DssGov (the new governance contract). There is not one active proposal under the new system as currently designed.

@Davidutro

If there are no Governance Facilitators left, a list must be provided of one or more new Interim Governance facilitators that will take the role in an interim capacity until they are either formally voted in, or another Governance Facilitator is elected by Maker governance.

Who provides this list? Where do they provide it, as part of the vote or in the forum?

---

On more of a general level. I liked the idea of providing a traffic-light / defcon / etc type system that categorizes the severity of emergency situations in a slightly more granular way.

Have you considered integrating something like that into this MIP?

[Davidutro]

This makes it sound like there are emergency changes to the facilitator role, which isn’t the case.

I’ve removed the whole bit about the removal of GF from this MIP, as it seems to be covered in MIP0c11: Governance Facilitator Role and MIP0c13: Core Personnel Offboarding. I thought it was from an emergency removal situation, but there’s no reason the standard process can’t be followed.

I feel like this might be too vague. One could argue that all changes would benefit from an expedited governance process. What makes a response insufficient?

rewrote as
“Any situation that includes a time-sensitive matter that would need an expedited governance process, where following the standard governance cycles would be too slow, risk a larger problem, or constitute an important missed opportunity.”

Not sure I would phrase this as a lack of control. Maybe a lack of appreciation for consistent and predictable governance?

fixed to, “Frequent emergency actions may signal a lack of appreciation for a consistent and predictable governance process.”

Tag Governance Facilitator

fixed tag

I liked the idea of providing a traffic-light / defcon / etc type system that categorizes the severity of emergency situations in a slightly more granular way.
Have you considered integrating something like that into this MIP?

I have, but I think it needs more discussion around what the different “defcon” levels would be. There is no rush here, since this can be added as an amendment to MIP24c1: Situation Definitions, or amended as a new component all together.

I edited the draft MIP in the comment above.

[Davidutro]

I have not received a response from @Jtathmann, @charlesstlouis

[LongForWisdom]

@Davidutro

I thought it was from an emergency removal situation, but there’s no reason the standard process can’t be followed.

Well, there is a reason the standard process doesn’t work, because the Governance Facilitator manages the standard process.

My point was more that it’s not an emergency change to the role itself, it’s an emergency removal of an individual from the role.

@Davidutro

Any situation that includes a time-sensitive matter that would need an expedited governance process, where following the standard governance cycles would be too slow, risk a larger problem, or constitute an important missed opportunity.

I like this a fair bit better, thanks.

@Davidutro

I have, but I think it needs more discussion around what the different “defcon” levels would be.

That’s fair. My point was more that we should consider starting those discussion and thinking about whether there are useful separations of severity we can use. I agree that it’s not essential, but I think it’s worth considering.

[Davidutro]

Do you think it’s worth keeping the emergency personnel removal here then?

Is there a reason an emergency removal couldn’t go through MIP 24, as it’s proposed? The community would put up the same type of explanatory forum thread detailing why the GF in question should be removed and why it’s an urgent situation.

The next-up GF can execute on the request.

In the absence of another GF, maybe an additional signal can be created electing someone in the interim?

In the absence of another GF, maybe an additional signal can be created electing someone in the interim?

I guess this is the piece of the process that should be captured somewhere in the MIPs

[charlesstlouis]

After coordinating with @LongForWisdom, @Davidutro, and @Jtathmann, I’m transferring Authorship of MIP24 to @Davidutro which will allow him to incorporate the new changes he has proposed for MIP24 as well as decide when to Formally Submit the proposal.

[Davidutro]

I have updated the MIP with some final edits to clean up the language. I added the updated version to the top-level original post as well as my own comment above.

I decided, for the time being, to leave off emergency removal of GF since I believe it can be covered by this process implicitly.

In the future of this MIP I expect the community to discuss and reach some consensus around a multi-level warning system rather than the simple urgent / emergency system being proposed here.

In general, I believe this is a huge improvement on MIP 5. Please let me know any final comments or changes I can make before officially submitting it for the November governance cycle.

@LongForWisdom @charlesstlouis