The Release of the 13 Initial Maker Improvement Proposals (MIPs)

Today, the Maker Foundation formally introduces the first 13 Maker Improvement Proposals (MIPs) to the Maker community. The 13 MIPs include MIP0 and two MIP Sets for Core Governance and Collateral Onboarding.

The MIPs Framework: Defines the underlying structure of the governance processes that will be used to continuously effect change and maintain the Maker Protocol in a standardized manner. It provides the necessary tools, and resources for the community to have a simple, standard approach to proposing new improvements, specifications, or process changes to the Maker Protocol and Governance system.

Core Governance MIPs Set: Defines the key governance structures, laying the backbone of long-term governance processes, such as how to organize executive votes.

Collateral Onboarding MIPs Set: Based on the independently community-created collateral onboarding document, this Set defines an end-to-end framework for scalable collateral onboarding that interoperates with the Governance Cycle and the existing Domain Teams.

What’s Next?

Please review the first 13 MIPs in the Maker Forum and provide feedback. All community members are urged to participate in the review process. On April 27, just 21 days from today, a special governance poll, called a timing poll, will occur. The timing poll will offer two options to the Maker governance community:

  1. Proceed with the ratification vote of the 13 proposed MIPs immediately, or;
  2. Delay the ratification for one month, and then institute a period of time to allow competing proposals to be submitted by the community.

The details of the timing poll are described in this forum post.

Join the Conversation


4 Likes

(I tried to reply in MP0 but it seems that comments there are locked. Where are we expected to discuss the MIPs?)

  • MIPs have a Feedback Period of 3 months. The RFC phase lasts at least 3 months before the MIP can move to the next phase.
  • MIPs have a Frozen Period of 1 month. MIPs must not have had any changes for the last 1 month before they move to the next phase.

I’m a little concerned that it will take a minimum of 4 months to get anything done. I guess MIPs are for only major changes and most stuff can be done using sub-proposals? The status quo seems more like 3 weeks. It takes a week to propose something on the discussion forum and turn it into a poll, the poll takes a week, and then the change can be bundled into an executive vote. Why must MIPs always take a minimum of 4 months? Why not make the timing more discretionary? For example, during the events of March 12, Maker onboarded USDC with about 3 days (from the public’s perspective) from idea to implementation. What if we need to act fast? Are MIPs going to lock us into a glacial pace? I guess there is MIP5 for emergencies, but I’m not sure that 4 months is a good default.

Overall, the MIPs process looks like it makes explicit what we are already doing and will help us do these things in public with transparency.

4 Likes

Good comment, as this is very important context to establish.

The intention is to have different levels of scrutiny for MIPs depending on the scope and the attack vector they represent. This also needs to be considered in the context of a scaled up governance process for a much larger protocol, with potentially hundreds of interconnected MIPs.

MIP0 proposals can change any part of the protocol or the governance process, so need a high level of scrutiny to make sure the final proposal that goes up for vote is as complete as possible, and that all the secondary effects of its implementation have been properly considered. 4 Months is actually the absolute lowest we have considered internally in the foundation, and it started off much higher since it might seem slow now, but in the long run when the system is juggling many more balls at once, 4 months will go by very fast.

However, in the beginning MIP2 gives us a lot more flexibility with implementing solutions to the problems in MIP1, so the 4 months won’t even apply initially except to concepts that are brand new and haven’t been anticipated in MIP1 (which, as it says, is expected to change over time based on what the community observes will be important problems to solve in the long run)

As you point out yourself, all day to day and routine operations such as collateral onboarding should be done through predefined process-MIPs. The goal is to have as much as possible covered by process MIPs and very rarely require new full MIPs in the long run. In general a good governance process contains few surprises.

For actual emergencies or very unusual circumstances that require a quick reaction - and where there isn’t already a process MIP in place that can be used - emergency votes are the way to go. Basically any time that there are serious external time constraints the community may need to make up a bespoke decision making process on the fly that fits within those constraints, which then results in an emergency vote to execute the response that has been decided. All of the governance actions taken during the march 12 crash would fall into this bucket.

Btw, I’m not sure why the MIPs aren’t open for comments yet, I expect we’ll get it fixed later today

3 Likes

Seems to work for me. Might be a permissions issue? I’m TL4, Joshua is TL3. Alternatively, it may have already been fixed. Maybe give it another try @Joshua_Pritikin?

1 Like

Hi mate @LongForWisdom, where do you see the attribute TL3 and TL4 ??? I can’t see them even with regular title.

See https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ for details. The Trust level is visible on the profile page.

1 Like

It’s fixed now. Hat tip to @charlesstlouis

2 Likes

Here is my feed back on MIP0-5 that I have already communicated privately but will add here publicly.

MIP0-5 are overly burdened with discussion to the detriment of brevity and clarity. Tons of discussion should just be pulled and moved to reference documents where discussion would be more appropriate (and necessary). I like the discussion but not in process and structure definition documents. IMHO I am also convinced these MIPs should be only two

MIP0 - defining what is needed for MIPs in terms of types, structure (templates/documents), process, and people.
MIP1 - should simply outline the governance process (which is what current MIP3 attempts).

The whole Emergency MIP (MIP5) Emergency MIP can stand on its own but really should be subsumed into MIP0 and MIP1 as a Emergency MIP type, and in MIP1 as exceptions to the normal governance process.

MIP0 needs restructuring mostly for clarity removal of discussion to reference documents and needs included basic processes of adding/removing EPC personnel as LFW suggests.

MIP1 should really be MIP3 and MIP2, MIP4 and MIP5 subsumed into MIP0 and MIP1

MIP3 and MIP4 when read for process literally are single Components after you wade through the pages of discussion.

Unless someone actually has a real counter example I am convinced sub-proposals are not required for this process. Literally if a MIP has a sub-proposal that is required for the MIP this ‘sub-proposal’ is a new component. IF a sub-proposal stands on its own NOT required for the primary MIP it is in - then it can be its own seperate MIP. Catagorizing important components as sub-proposals imo overly complicates what should be as simple a process as possible.

My point here is that I don’t see the sub-proposal concept adding anything except extra complexity for imo for not real added benefit. Now if someone can come up with an example where this would be important I am all ears. I stand by my arguments regarding sub-proposals being unnecessary AND potentially hazardous (leading to dependency issues that will make the whole dependency processing/tracking difficult to track/deal with).

Beyond the above comments I think these are very important first steps, but imo literally an alpha draft that needs further refinement with particular attention paid to brevity, clarity, process definition and removing extraneous discussion/explanations to associated reference documents.

1 Like

Yes i knew this, Thanks @LongForWisdom, i tought it was on the forum itself. I can search for those TL3 and TL4 but i’t manually promoted so i guess we have no access to this tab.

I do like the secret section for regular members, funny. ( Sorry for this reply out of the subject )

How are revisions going to happen? Can these MIPs live in a github repo so we can see what changes? The community could even submit changes as PRs.

My impression is that Maker (the org) is somewhat paralyzed while the MIPs thing is in limbo. I’d like to see revisions happen and move to ratification as soon as possible. Let’s be efficient people. There is collateral waiting to onboard.

1 Like

We will run short on #staff then. Leave the actual forum to get more concentration work on the new addition. It can work.

Regarding the situation that did occur lately, i think this is not even a question to ask about transparency of the gouvernance and documentation should be there. I think it’s going forward.

Yes, the MIPs will be published to MakerDAO’s Github. Much of the correspondence regarding MIPs will be handled through GitHub as well here in the MakerDAO forums.

A week of discussion here on the forums is good before we open up the Github repo for PRs. This time period provides a chance to have some detailed discussion and consolidation before posting suggestions. Once the Github repo is ready and the MIPs are posted on Github, they will go through a formal review period (as defined in MIP0c3: The MIP Lifecycle by the RFC (3) stage in MIP0). This stage includes the MIP Author(s) integrating feedback from the community, further drafting and additions.

2 Likes

Hah, oops. Sorry @charlesstlouis.

1 Like

Nothing is stopping anyone from initiating the collateral onboarding process I believe. The major question is whether domain teams would go along with it. AFAIK most if not all informally signed off on the collateral onboarding document we made , so maybe they would still be willing to work with those guidelines. It doesn’t require high dependency on anything else and should be workable in its current form.

Personally I am not keen on ratifying something that few people are really looking deeply into, especially when they are so structured and complex. Makerman, LFW and I have been looking at MIPs for a little while now, so we are much more familiar. Only recently have they started making some sense to me, so I am sure many are a little befuddled.

I still basically disagree with the design premises, but that doesn’t preclude them from being viable. Ill get my comments together on that front for the forum soon

1 Like