MIP0: The Maker Improvement Proposal Framework

MIP0: The Maker Improvement Proposal Framework

Preamble

MIP#: 0
Title: The Maker Improvement Proposal Framework
Author(s): Charles St.Louis (@CPSTL) and Rune Christensen (@Rune23)
Type: Process
Status: <Assigned by MIP Editor>
Date Proposed: 2020-04-06
Dependencies: n/a
Replaces: n/a

Summary

MIP0 is the genesis proposal describing the MIPs Framework. This includes the core components and statuses as well as the various MIP types and the overall MIP lifecycle. Furthermore, it provides the necessary tools, such as MIP templates, replacement processes, and dependencies. Lastly, the proposal details the key roles of the framework, the MIP Editor and the Governance Facilitator along with the process for adding and removing them.

Motivation

MakerDAO is evolving into an organization that is trustless, fully decentralized, open-sourced, and self-sustainable. In order to further enable this gradual evolution while maintaining governance functionality both during this process and after the dissolution of the Maker Foundation, Maker will be governed using Maker Improvement Proposals (MIPs).

The purpose of the MIPs Framework is to open up the ability to improve Maker Governance and the Maker Protocol to anyone in the community.

By empowering the participation of the community and other stakeholders to have a standard approach to proposing improvements, specifications, or process and state changes, the goal is to enable organic growth that will in turn bring MakerDAO closer to self-sustainability.

In order for MIPs to be functional they need to comply with a basic standard outlining their internal structure and external dependencies. This standard is MIPs described in MIP0, the Maker Improvement Proposal Framework.

Specification / Proposal Details

MIP0 Components

  1. MIP0c1: Definitions of the Maker Improvement Proposal Framework
  2. MIP0c2: Three Core Principles
  3. MIP0c3: The MIP Lifecycle
  4. MIP0c4: MIP Components and MIP Component Types
  5. MIP0c5: MIP Replacement Process
  6. MIP0c6: MIP Templates
  7. MIP0c7: MIP0 Domain Role Dependencies
  8. MIP0c8: MIP Editor Election Process
  9. MIP0c9: MIP Editor Removal Process
  10. MIP0c10: Governance Facilitator Election Process
  11. MIP0c11: Governance Facilitator Removal Process

MIP0c1: Definitions of the Maker Improvement Proposal Framework

  • Maker Improvement Proposals (MIPs) are the preferred mechanism for improving Maker Governance and the Maker Protocol. Through an open and documented process, the goal is to collect as much community feedback as possible and reach the broadest possible consensus on how the Maker Protocol should evolve. A proposal clearly defines how and why Maker Governance or the Maker Protocol should be changed and ensures that this improvement is introduced in a responsible way, respecting the highest quality, security and community standards.
  • MIP0: The genesis MIP defining the MIPs framework. This MIP defines all of the processes that are required for the implementation of future MIPs.
  • MIP Sets: A MIP set is a group of several MIPs that are interdependent, in which without the entire set of MIPs existing, one or more MIPs in the Set become inconsistent, invalid or nonsensical. The intention is for MIP sets to together describe a single complex behaviour in such a way that allows each individual MIP to be written following the principle of Specificity but work together as a cohesive modular whole.
  • MIP Types: MIPs are separated into a number of types, and each type has its own list of MIPs and processes.
  • Process MIP: Process MIPs are used to create and define a specific recurring process that the Maker Protocol or Governance will employ.
  • Subproposals (SPs): A subproposal is an instance of a sub-process that has been defined by a specific MIP. Subproposals are named in the following format: MIP0-SP1 (where MIP0 is a Process MIP and MIP0-SP1 is a subproposal under that Process MIP)
  • Minimum Feedback Period: The minimum amount of time within which the community is able to give feedback in response to a proposed MIP.
  • Minimum Frozen Period: The minimum amount of time during which a MIP must remain unchanged (frozen) before it can be submitted for ratification/implementation.
  • Governance Facilitator(s): Governance Facilitators are tasked with ensuring the smooth operation of the governance process. This involves a wide range of activities, anything from general administration to signals gathering to governance scheduling.
  • MIP Editor(s): Enforce the administrative and editorial aspects of the overall MIPs process and program. The expectation is that the program will start out with an interim editor from the Maker Foundation and that others will join later.
  • Domain Teams: Domain Teams work for the DAO, are onboarded through governance and are paid by the Protocol. Domain teams perform defined duties for the DAO, such as overseeing critical processes and mitigating risk. These teams consist of but are not limited to Risk, Oracles, Smart Contracts or Legal.

MIP0c2: Three Core Principles

  1. Specificity: A MIP needs to define and address a specific behaviour or single responsibility. MIPs with many different behaviours or responsibilities will not be allowed and must be split up into multiple MIPs.
    • This mitigates the risk of having “fine print” or potential attacks hidden in large, complex MIPs.
  2. Completeness: A MIP or MIP Set is complete if it has all the necessary or appropriate parts that cover a whole behaviour and avoids being only a specific part of a greater whole.
    • This is important for both understandability, readability and accessibility of MIPs.
  3. Avoid overlap: Multiple MIPs should not implement the same type of behaviour independently. For instance, there should not be two separate but interchangeable ways to do collateral onboarding.
    • This way the primary and best-understood process for each particular behaviour will be fairly available to everyone, without risking having a knowledge gap that makes it possible for some actors with better access to information to use different and potentially better processes

MIP0c3: The MIP Lifecycle

The MIP Lifecycle Flow and MIP Statuses

MIP Status Criteria

1. Conception: The lifecycle of a MIP begins when the MIP proposal is posted on the Maker forum. However, in order for a MIP to move to the next stage, it needs to satisfy the transition criteria (1) described below:

  • Submitted to the MIPs Discourse Forum.
  • Submitted to the MIPs Github repository (with a Pull Request created by the MIP Author or MIP Editor).
  • The format must follow the appropriate MIP Template for its type.
  • MIPs must be original or replacement versions of older MIPs (No repeats allowed).

2. Approved by MIP Editor(s): This phase of a MIP’s life cycle is when the MIP Editor(s) confirms that the proposed MIP follows the correct structure and editorial criteria defined in the MIP template. If the criteria is not met, the MIP Editor(s) will provide an explanation to the MIP Author as to why and allow them to make the appropriate changes before reconsideration. If the criteria have been met, the MIP Editor(s) performs the following actions:

  • The MIP is approved by a MIP Editor(s) and is assigned a formal MIP number.
  • The PR is merged in by a MIP Editor(s).

3. Request for Comments (RFC): This phase is when a MIP goes through a formal review period, including feedback from the community, further drafting and additions. The timeline for the RFC phase is defined by its Feedback Period and Frozen Period. In order to move to the next phase, it needs to satisfy the transition criteria listed below:

  • MIP Author finalizes changes of the MIP, based on community feedback.
  • 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.

4. Fulfilled Feedback Period Requirements: This status is given once the MIP has fulfilled the defined Feedback Period and Frozen Period. After the MIP has waited out its Feedback Period and Frozen Period, it’s ready for Formal Submission. Note that the Feedback Period and Frozen Period can overlap.

5. Formal Submission (FS) - This phase is when MIP Authors submit their complete MIP(s) to the Governance cycle by posting it to the formal submission forum category within the formal submission window of a governance cycle.
- A MIP can be re-submitted to the formal submission process a maximum of 2 additional times (3 total), without having to go through phase 1- 4 again, if it failed to pass due to legitimate external reasons (e.g. got bundled in a governance poll or executive vote with a controversial proposal - subject to the governance facilitators judgement).

6. Approved by the Governance Facilitator(s): This phase is when the MIP must be formally approved by the Governance Facilitators.

  • Once approved by the Governance Facilitator, the MIP will be included in the inclusion poll of the Governance cycle.
  • If the MIP is not approved by the Governance Facilitator, it may be reconsidered at a later date to enter the Governance cycle.

7. Governance Cycle: This phase is when MKR holders vote on whether to include the MIP in the governance poll, ultimately determining whether or not the MIP can formally enter the governance cycle.

  • Once approved for the governance poll, MKR holders determine whether to accept or reject the package of proposals in the governance poll and finally to ratify the result in the executive vote.

8. Executive Vote: This phase is when the MIP becomes officially ratified or not. Determined by MKR holders, the executive vote ultimately accepts or rejects the MIP.

9. Accepted/Rejected: The Executive vote results in either acceptance or rejection of the MIP. If passed, the MIP is officially accepted and is given the accepted status. If the executive vote fails to pass before expiring, the MIP is rejected.

  • As described in phase 5, a rejected MIP, can be resubmitted, and in some cases (if it was rejected for provable extraneous explanation) may be allowed to enter the next Governance cycle immediately.

Other MIP Statuses:

Withdrawn: when a MIP Author withdraws their MIP proposal, such as when:

  • A MIP may be withdrawn at any point before it enters the Governance cycle.
  • Note that a withdrawn proposal can be taken over from the original Author with a simple transition facilitated by a MIP Editor(s) and the respective parties. If the original MIP Author ceases to be available, the MIP Editor(s) may proceed with the transfer of Authors.

Deferred: when a proposal has been deemed as not ready or not a priority but can be re-proposed at a later date.

  • Request for Comments (RFC) - Forum poll/signal request rejects a MIP Proposal.

Obsolete: when a proposal is no longer used or is out of date, such as:

  • A MIP is replaced with a new proposal.
  • A MIP has been deferred for over 6 months.
  • A MIP Author has abandoned the proposal and no person has communicated willingness to take over MIP Author responsibility.
  • A MIP has been replaced by a newer, more updated MIP Proposal.
  • A MIP no longer makes sense to keep in consideration.

MIP Status Change Process:

A status change for a MIP is requested by the MIP Author and will be reviewed by the MIP Editor(s) to see if it meets the status criteria of the requested status change. If it does, the Editor(s) will change the status of the MIP and the Author may proceed with the next stage of the process. If it does not, the MIP Editor(s) will revert with highlighted issues, and the Author must fix the highlighted issues before requesting another status change.


MIP0c4: MIP Components and MIP Component Types

MIP Components

  • When necessary, MIPs can have multiple components if it needs to contain multiple units of logic to satisfy completeness. A MIP can also have only a single component.
  • MIP components are categorized by types, depending on what kind of logic they contain. MIP components are named by their parent MIP. The abbreviation convention MIPXcY is used to refer to these components (as seen in this document).
  • A MIP component has one type or no types.

Note: MIP0’s MIP Components are introduced at the beginning of the Specification section.

Component Types

  • Technical MIP Components

    Summary: The purpose of technical MIP components is to perform state changes to the Maker Protocol.
    Specific Template: Technical MIPs are based on the General MIP Template but must include the following additional information in their specification section:

    • Proposed Code
      • Audited, final code that can be used directly in the executive vote to accept or reject the MIP.
    • Test Cases
      • Test cases for the implementation or testing of the proposed code
    • Security Considerations
      • The purpose of this section is to proactively document any security-relevant design information, decisions, potential failure modes, implementation details, and important discussions related to the proposed change.
      • Backwards compatibility
    • Auditor Information and Report
      • This section includes the audit partner details and the final audit report for the proposed code.
    • License
  • Process MIP Component

    Summary: The purpose of a Process MIP component is to shape a specific process flow for the Maker community to adopt and standardize with respect to how governance operates. This MIP component type helps streamline specific processes in a transparent, open and traceable manner. A Process MIP will provide a publicly documented scope of a proposed process framework as well as a detailed description of the subproposal structure.

    Special Template: N/A

    Important Notes:

    • A Process MIP component must define the Feedback Period and Frozen Period for its sub proposals.
    • Sub proposals of Process MIP components with additional MIP Component types inherit the same types.
  • Sub Proposals

    Summary: A MIP component creates a bespoke process that is engaged by submitting sup proposals according to the framework specified in the process MIP component.

    • The subproposal component naming convention is MIP#c#-SP#. This is important in order to delineate between different SPs under the same MIP.

Special Template: N/A


MIP0c5: MIP Replacement Process

A MIP can define one or more replacement targets in its preamble. If the MIP is given the accepted status, the replacement target(s) MIPs 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.

Due to the fact that the dependencies carry over, a MIP with defined replacement targets must, in order to be valid, strictly adhere to dependency requirements and interface correctly with MIPs that depend on the replaced MIP, and thus after the replacement with the new MIP.


MIP0c6: MIP Templates

General MIP Template

Preamble

MIP#:
Title:
Author(s): 
Type: 
Status: <Assigned by MIP Editor>
Date Proposed: <date created on, in (yyyy-mm-dd) format>
Dependencies: n/a
Replaces: n/a

Summary

A description of what the Maker Improvement Proposal (MIP) is focused on.

Motivation

A short description of the motivation behind the MIP.

Specification / Proposal Details

Proposed process standard details - describes the new process or feature and the problem it is solving.


Technical MIP Template

Preamble

MIP#: <# to be assigned>
Title: <MIP title>
Author: <list of authors' names and/or email addresses and GitHub handles>
Type: MIP Type
Status: <Assigned by MIP Editor>
Date Proposed: <date created on, in (yyyy-mm-dd) format>
Dependencies: <List of depdendent MIPs>
Replaces: <List of MIP it is replacing>
License: <added by MIP Author>

Summary

A short description of what the Maker Improvement Proposal (MIP) is focused on.

Motivation

A short description of the motivation behind the proposed technical solution.

Specification

The details of the proposed technical solution. The specification should be detailed enough to allow an implementation team to begin development as well as testing.

  • Proposed Code:

    • The final code that can be used directly in the executive vote to accept or reject the MIP.
  • Test Cases:

    • For the implementation or testing of the proposed code
  • Security Considerations

    • This is one of the most important aspects of the Technical MIP proposal. The purpose of this section is to proactively document any security-relevant design information, decisions, potential failure modes, implementation details, and important discussions related to the proposed change. This section helps to optimize the MIP process by providing proactive guidance on security considerations when proposing a change that will affect the Maker Protocol.
    • Backwards compatibility
  • Auditor Information and Report

    • This section includes the audit partner details and the final audit report for the proposed code.
  • Licensing


MIP0c7: MIP0 Domain Role Dependencies

The MIPs Framework depends on these types of Domain Roles:

  • MIP Editor(s): Enforces the administrative and editorial aspects of the overall MIPs process and program. The expectation is that the program will start out with an interim editor from the Maker Foundation and that others will join later.

  • Specific authority of the MIP Editor(s) in MIP0 processes:

    • The MIP Editor(s) controls phase 2 of the MIP lifecycle and can assign MIP numbers
    • The MIP Editor(s) is an admin on the MIPs Github repository
    • The MIP Editor(s) is a moderator on the MIPs Discourse forum
    • The MIP Editor(s) is responsible for updating the status of MIPs, as described in MIP0c4 “The MIP Lifecycle”.
  • Governance Facilitator: Operates voting frontends, runs governance meetings and accepts MIPs that are ready to be included in the Governance Cycle and thus, voted on.

  • Specific authority of the Governance Facilitator in MIP0 processes:

    • Consensus from all governance facilitators controls phase 6 of the MIP lifecycle, which allows them to, with consensus, add valid MIPs to the inclusion poll of the next governance cycle, moving them from phase 5 (formal submission) to phase 7 (governance cycle).

MIP0c8: MIP Editor Election Process

Description of MIP Editor Role: The MIP Editor enforces the administrative and editorial aspects of the overall MIPs process and framework. This includes:

  • Maintain and manage mips.makerdao.com.
  • Provide feedback and have discussions in the MIP section of forum.makerdao.com (ex: helping vet proposal ideas).
  • MIPs processing.
  • Enforcing the proper MIPs process with responsibilities such as:
    • Confirm that the title accurately describes the content of the proposal.
    • Confirm there is a (real) dedicated author, coordinator, funder and/or sponsor, etc. of the MIP.
    • Assign proposed MIP’s formal number labels.
    • Change MIP statuses.
    • Correct MIP category placement.
    • Correspond with MIP authors/coordinators.
    • Review the MIP for obvious defects in the language (format, completeness, spelling, grammar, sentence structure) and that it follows the style guide (template). MIP Editors are allowed to correct problems themselves, but are not required to do so and can send comments to authors to improve it themselves.
    • Work and communicate with Governance Facilitators on coordinating governance and executive votes in relation to MIPs and the governance cycle.
    • Onboard and vet new MIP Editors.
    • The expectation is that the system will start out with an interim editor from the Maker Foundation and that others will join later.
    • A MIP Editor must be vetted by the current MIP Editor(s) and by MKR holders through this sub proposal. Once an Editor, they will be added to Github and subscribed to watching the MIP repository. They will also become a moderator in the MIPs Rocket.Chat Channel and the MIPs Forum. Much of the correspondence regarding MIPs will be handled through GitHub as well in the MakerDAO forums.

MIP Editor Selection Criteria

  • A complete understanding of the MIPs Framework
  • Knowledge share will occur when onboarded but the candidate must be very familiar with the framework and how other improvement proposal frameworks operate.
  • Required to be a community member for some time. This can be shown through various proof of participation methods, such as:
    • Past forum posts
    • Attendance of community and governance calls
    • Articles written about Maker or Dai
  • Familiarity with the technical inner workings of the Maker Protocol (bonus)
  • Experience with Github
    • Merging, editing, closing Pull Requests
    • Addressing issues
    • Adding tags / labels
  • Experience with the Markdown language
    • MIPs will be written in Markdown, so editors will need to be familiar with the language.

MIP Editor Election Subproposal

  • Subproposal Feedback Period: 3 months
  • Sub proposal Frozen Period: 1 month
  • Sub proposal template:
Introduction

- Role: MIP Editor

- Name of applicant or proposed applicant:

- Date Applied: <date created on, in (yyyy-mm-dd) format>


Application Form
    
- Motivation:
    - Explanation of why and how you want to become a MIP Editor
    
- Credentials:
	- Past work experience
	- Github account
	- Forum account

- Relevant Information:
	-  Links to forum posts, blog posts, or any other community contributions related to Maker. 
    

MIP0c9: MIP Editor Removal Process

A MIP Editor should be considered for removal if they are:

  • Not adequately performing their defined duties
  • Absence from their duties for a longer period
  • Biased or malicious behaviour
  • The Editor expresses unwillingness to continue in their role.

The removal process begins once the community has agreed on the reasoning for removal. This process must be communicated publicly via the forums in order to provide complete transparency. The MIP Editor will then be removed from the following channels:

  • Github
  • RocketChat
  • Forums

A MIP0 Sub Proposal is required to remove a MIP Editor.

  • Sub proposal Feedback Period: 0 days
  • Sub proposal Frozen Period: 0 days
  • Sub proposal template:
Introduction

  - Role: MIP Editor

  - Person to be removed:

  - Date of Proposed Removal: <date created on, in (yyyy-mm-dd) format>

Removal Form and Supporting Evidence
    
  - Motivation:
    - Explanation behind the removal of the MIP Editor

  - Relevant Information:
	-  Links to evidence further backing the motivation behind the removal of the MIP Editor


MIP0c10: Governance Facilitator Election Process

Description of Governance Facilitator Role and Authority:

  • Governance Facilitators are persons or teams responsible for operating a governance and voting frontend that is available to the entire community as well as venues the community uses for communications.
  • Governance Facilitators have the authority and responsibility to put proposals up for MKR vote for full community ratification, if they determine, with input from the community, that the proposals have fulfilled all requirements to be eligible for MKR voting.
  • Reference: “Mandate: Interim Governance Facilitators”.

GF Selection Criteria

  • Governance Facilitators must have experience engaging with different stakeholders in the community in all the different venues the community uses for communications including chat rooms, forums and video conference calls.
  • Feedback Period: 3 months
  • Frozen Period: 1 month
  • Sub proposal template:

Introduction

- Role: Governance Facilitator

- Name of applicant or proposed applicant:

- Date Applied: <date created on, in (yyyy-mm-dd) format>


Application Form
    
- Motivation:
    - Explanation of why and how you want to become a Governance Facilitator. 
    
- Credentials:
	- Past work experience
	- Github account
	- Forum account

- Relevant Information:
	-  Links to forum posts, blog posts, or any other community contributions related to Maker. 

MIP0c11: Governance Facilitator Removal Process

A Governance Facilitator should be considered for removal if they are:

  • Not adequately performing their defined duties
  • Absence from their duties for a longer period
  • Biased or malicious behaviour
  • A Governance Facilitator expresses unwillingness to continue in their role.

The removal process begins once the community has agreed on the reasoning for removal. This process must be communicated publicly via the forums in order to provide complete transparency. The Governance Facilitator will then be removed from the following channels:

  • Github
  • RocketChat
  • Forums
  • Other Relevant Channels

A MIP0 Sub Proposal is required to remove a Governance Facilitator

  • Sub proposal Feedback Period: 0 days
  • Sub proposal Frozen Period: 0 days
  • Sub proposal template:
Introduction

  - Role: Governance Facilitator

  - Person to be removed:

  - Date of Proposed Removal: <date created on, in (yyyy-mm-dd) format>

Removal Form and Supporting Evidence
    
  - Motivation:
     - The explanation behind the removal of the Governance Facilitator

  - Relevant Information:
	 -  Links to evidence further backing the motivation behind the removal of the Governance Facilitator.

5 Likes

So as usual I have a lot of feedback. In general I think this is a good foundation, but would like to see it tightened up and optimised for the average MKR Holder in a number of ways. Given the difficulty in gathering consensus in cases like this, I’m going to include a lot of polls for people to easily signal agreement or disagreement on each suggested change.

@charlesstlouis I know there is a limited timescale for getting these ratified. I’m happy to help implement any or all of these changes if they prove to be popular.


General Template Changes

Provide Multi-level Summaries

What should change? Split the current summary into the three following sections…

  • Sentence Summary: A single sentence explanation of what the MIP is and what it does. Suggest max 30 words.
  • Paragraph Summary: A single paragraph explanation of what the MIP is and what it does. Suggest max 100 words.
  • Component Summary: A summary of the included components and their contents. Suggest no more than 200 words per component.

These summaries should specifically be called out as not the canonical source of truth (that is found in the specification.)

Why do this?

  • It allows MKR Token Holders to engage with MIPs at whichever level they prefer. Not much time? Read the paragraph summary before voting. Vote ends in 10 minutes? Read the sentence summary. Want to get an overview of the MIP before deciding if you want to spend the time reading the full specification? Read the component summary. Etc.
  • It makes MIPs easier to grasp as you are reading them. It gives readers an upfront view of what is in the MIP before getting into the specification details. Assuming summaries are well written, this should aid understanding and comprehension while reading.
  • It gives new members of the community a fast-track path to catch-up with currently ratified MIPs, getting them to a base level of knowledge faster, and allowing them to contribute more meaningfully earlier.
  • It allows press to get an overview of what a MIP is going to do and write about it in an informed manner. Obviously in an ideal world press would take the time to read the whole document if they are writing about it. We don’t live in an ideal world.
  • It makes the MIPs much more consumable for front-ends in the future. Want an index page of all the MIPs with one sentence explanations? Use the sentence summary. Want an overview page of all the MIPs, list them out with the paragraph summary. Want to create a lookup function using the component code (MIPXcY)? You can provide the MIP paragraph summary, the component summary for that specific component, and then the component text.
  • It may lead to better formed MIPs. If an author is forced to summarise at different levels it may give them a better appreciation of what is critical to the MIP, and what is not.
  • Changing the general template later is much much harder than changing it now. Right now we’d have to re-write 13 MIPs, later it could be over 100.

Reasons not to do this?

  • May be overkill for a number of the smaller MIPs.
  • Makes MIPs longer and includes non-essential content.
  • Possibility of confusion between summaries and specification.
  • More work for MIP Authors, forcing them to summarise their own content at varying levels.
  • I support this change.
  • I do not support this change.

0 voters


Move the component list earlier in the MIP document.

What should change?
The MIP Component list should move out of the specification and under a new heading ‘Component List’ which should appear directly under the Preamble section.

Why do this?

  • It frontloads information about the length and content of the MIP, leading to easier consumption.
  • This is not technically specifying anything directly, so it probably shouldn’t live in the specification section.
  • Changing the general template later is much much harder than changing it now. Right now we’d have to re-write 13 MIPs, later it could be over 100.

Reasons not to do this?

  • It’s a fairly minor change, it may not be worth the effort.
  • I support this change.
  • I do not support this change.

0 voters


Support tags

What should change?
In MIP0c6 we should add a tags field into the preamble section of the general and technical MIP templates. This field should be used only by the MIP Editors to organise MIPs as best as is possible. Assign appropriate tags to the initial set of 13 MIPs.

Why do this?

  • Makes MIPs better organised.
  • Yields one cannonical set of tags rather than multiple community sets.
  • It makes the MIPs much more consumable for front-ends in the future. Enables searching by tag, word clouds, analytics, navigation via tag, etc.

Reasons not to do this?

  • I can’t think of any, it’s a low effort change with a high potential reward.
  • I support this change.
  • I do not support this change.

0 voters


Content Changes

Add Clarity as a Core Principle

What should change?
MIP0c2 should have an additional principle labelled ‘Clarity.’ The description could be something along the lines of: A MIP must not have equally valid conflicting interpretations. MIP Authors and MIP Editors must strive to reduce ambiguity wherever possible.

Why do this?

  • Ambiguity is a problem that is inevitable, but that we should try to avoid. Having confusion about what is and is not the intention / logic of a ratified MIP is not a good place to be.
  • It makes it clear to MIP Authors that in order for their MIP to be accepted, it needs to be easily understandable.

Reasons not to do this?

  • Adds text to what is already a long-ish MIP.
  • Maybe this can be considered to be implied?
  • I support this change.
  • I do not support this change.

0 voters


Add Brevity as a Core Principle

What should change?
MIP0c2 should have an additional principle labelled ‘Brevity.’ The description could be something along the lines of: A MIP must be as short as possible, including only that which is essential given the other core principles.

Why do this?

  • MIPs are not a place for endlessly expounding only tangentially related motivations or logic. Every additional word added is one more word that MKR Token Holders may feel some obligation to read.
  • It should help to make MIPs more focused and strip out any logic or commentary that isn’t strictly necessary.
  • It reduces the surface area for attack-by-slipping-in-innocuous-sounding-phrases-that-actually-break-things.

Reasons not to do this?

  • Adds text to what is already a long-ish MIP. (For the greater good!)
  • Maybe this can be considered to be implied?
  • I support this change.
  • I do not support this change.

0 voters


MIP0c8 - MIP0c11 should be restructured

What should change?
These components should be rewritten such that:
MIP0c9 becomes a definition of the MIP Editor Role (includes removal criteria)
MIP0c10 becomes a definition of the Governance Facilitator Role (includes removal criteria)
MIP0c11 becomes a process to onboard core personnel defined in MIP0.
MIP0c12 becomes a process to offboard core personnel defined in MIP0.

Why do this?

  • Currently we are mixing the role definition with the process to onboard and offboard, these are distinct units of logic.
  • The onboarding and offboarding processes are identical for the two roles, it makes no sense to define them both twice.
  • Makes it easier to replace any of these components in the future without affecting the role definitions.

Reasons not to do this?

  • Relatively minor change, probably isn’t 100% necessary.
  • More work.
  • Means you can no longer have separate Feedback and Freeze periods for the MIP Editor versus the Governance Facilitator for the onboarding and offboarding processes.
  • I support this change.
  • I do not support this change.

0 voters


Content Additions

Add a component that formalizes the linking of external documents to a MIP.

What should change?
A component should be added called ‘Supporting Materials’ and should have the following logic:

  • MIPs can optionally refer to external materials.
  • External Materials must be added to the MIPs github in the same folder as the MIP (MIPs would need to have their own folder) which refers to them.
  • These externally referenced materials are not MIP content, and are not ratified when a MIP becomes Accepted unless it is explicitly stated otherwise in a MIP Component specification.
  • MIP References are named according to their parent MIP. The convention ??? is used to refer to external materials. (Actual convention used is open to debate, there are some tradeoffs between using numbers / letters)

A section should be added after the Preamble section called ‘References’ which lists the external materials referenced by this MIP.

Why do this?

  • It could be useful to link supporting documents to MIPs. This could include: Audit Reports, Discussion and Feedback on the MIP during its creation, Inspirational materials, Templates, defined outside of the main MIP text.
  • Future Proofing, feels like we will probably need this at some point.
  • Formalizing how these materials are linked to MIPs now means that every linked document will follow the same standard.
  • MIPs can provide additional optional reading.

Reasons not to do this?

  • More text in MIP0.
  • Not strictly necessary content.
  • I support this change.
  • I do not support this change.

0 voters


Add a component that explicitly defines the ‘Protocol Discussion Venues’

What should change?
Add a new component named ‘Protocol Discussion Venues’ that explicitly defines (ie urls) what is meant by:

  • The MakerDAO chat.
  • The MakerDAO forum.
  • The MIPs Github Repository.
  • (possibly) The MakerDAO voting portal.

In relation to the roles of the MIP Editor and the Governance Facilitator.

Why do this?

  • It makes explicit and clear what is already well-understood.
  • It avoids rules-lawyer (Hello!) coming along and saying ‘Well I’m doing MIPs in my own github, what makes your more official than mine?’
  • If these venues change that change can be made very clear using the MIPs process (prevents people from using the old venues for ‘official’ business.)

Reasons not to do this?

  • Maybe this can be considered to be implied?
  • Adds more text in MIP0.
  • If these venues change at any point MIP0 will need to be amended.
  • I support this change.
  • I do not support this change.

0 voters

6 Likes

I am generally in favor of less rules and more discretion.

3 Likes

This is the result of serious, lenghty thought; thank you for this work. I don’t have time to give very constructive feedback and I apologize for that. I agree with @Joshua_Pritikin, but I hope we are clear that this is a “standard approach”, not a source of future process friction. So I’ll just reiterate something which I think is important to keep in mind: any executive vote can pass at any time regardless of the governance rules we agree on. This should not constitute a grave governance failure: the incentive structure around MKR is supposed to be good enough to secure the system and we are, right now, merely trying to optimize decisionmaking quality during the normal course of governance.

I’ll do my best to come back with more substantive thoughts on the contents of the post.

5 Likes

LFW. Amazing that you did this.

My comments will be more general and placed in the general thread.

2 Likes

Great work #comm-dev and @everyone. This is going somewhere.

@scottrepreneur

I would also like to see it on #Github . This would be easy to find and to manage i think . More easy to find than on the forum itself.

1 Like
5 Likes

A few top-of-mind thoughts after first read:

  1. For pure process MIPs, is the governance cycle necessary? Do we plan on putting e.g. some Smart Contract on-chain that stores the names and content hashes of approved MIPs, with governance voting on what goes into that Smart Contract?
  2. Should MIP sets be treated atomically by the lifecycle process? I.e. the process guarantees that either all MIPs in a set are approved, or none? For example, by requiring that only complete MIP sets can proceed to executive vote.
  3. I think some parts are over-specified: e.g. listing out “Github, Rocket Chat, and Forums” as explicit channels to remove people from is probably a little too much detail. The wording should probably just be “when a (MIP Editor|Governance Facilitator) is removed from their role, any elevated permissions granted to them in order to perform the duties of that specific role will be revoked (unless needed for other roles they still occupy)”.
8 Likes
  1. Great question - would love to know the answer too.
  2. It makes sense to me that each set would behave atomically. I loved this particular part of the explanation:

A MIP Set is a group of several MIPs that are interdependent, in which without the entire set of MIPs existing, one or more MIPs in the Set becomes inconsistent, invalid or nonsensical. The intention is for MIP sets to together describe a single complex behaviour in such a way that allows each individual MIP to be written following the principle of Specificity but work together as a cohesive modular whole.

I imagine that, much like with code, if your set gets rejected (governance communities irl version of a big red stack trace) you just ctrl C + ctrl V the parts that weren’t causing issues and redo the parts that were failing. This idea of cohesive modularity addressing complex behaviour in a well-specified domain is NB imo, and worth sacrificing a bit of potential effort for.

  1. Agree on specific chat channels being over-specified.

  2. Also, @LongForWisdom - I reckon that brevity and clarity are often mutually exclusive in Maker, and prefer Clarity, fwiw. Agree on most of the rest of it - great feedback!

2 Likes

The MIPs Github repo is now public and MIP0 can be found here: https://github.com/makerdao/mips/tree/master/MIP0

3 Likes

I find this sentence confusing. Does it mean:

  • MIP has a type property
  • type definition requires it’s own MIP(s)
  • types differentiate MIPs relating to processes etc?

Last sentence seems redundant.

I would change it to: A MIP component has one type and introduce special type N/A (or whatever).
Easier to parse and validate.

I would change it to: <List of dependent MIP Sets>

I would have this only as an optional and submitter can choose his format:

  • summary is required
  • paragraph summary and component summaries are optional
1 Like

I voted yes, still… tags are extremely hard to be long term useful:

  • people just love to add new ones,
  • tag meaning can change
  • in practice it’s almost impossible to merge, split, rename them (breaks immutability, breaks clients:
    programmers are short term focused and introduce dependencies where/when they shouldn’t). You would need abstract tag not being just label, plus encode transitions…
  • this forum already has 30 tags and some of them are highly specific, like “covid-crash” and one very similar “black-thursday”
  • who “owns” the tag list? It’s easier when you only have 1 editor, but when multiple?

I guess this is just my usual tag rant :slight_smile:
(maybe to remind editors to use them very conservatively: use very general words and maybe have a tag number cap)

Actually forum has more than 30 tags - not all of them are shown when you click on dropdown ‘all tags’.

I think most of this can be mitigated by having the MIP Editors own the MIP tags.

For all intents and purposes I own the tags on this forum. Imo they are pretty useful, I’d love to hear any ideas you had for improvement. You can see them all on the https://forum.makerdao.com/tags page and there is a curated list here: Forum Navigation Index