MIP-Upgrade #23
MIP-Upgrade #23
Conversation
This MIP adds several improvements to the MIP process
|
Please can you review this PR? @nholland94 @kantp @bpmckenna1 |
|
I will review next week after Thanksgiving. |
|
One initial note is that you need to rename the file with the .md file extension in order for it to render properly on github. |
| - Collect and incorporate feedback from the community. | ||
| - Document alternative opinions, the options considered and other discussed topics. | ||
| - Champion the MIP through each stage of the process. | ||
| - Designate, coordinate and oversee a Dev Team for the MIP implementation. |
There was a problem hiding this comment.
I'm wondering if requiring the MIP author to also coordinate the delivery is too constraining. Authoring an MIP and handling the implementation require different skillsets, so having one person do both might not always be best.
Maybe we should allow for the MIP author to be a team, instead of an individual, natural person? That might make it easier to get all the skills required.
There was a problem hiding this comment.
I completely agree, and this is already addressed in the proposed template. As it states: Multiple authors can contribute to one MIP, but at least one person must be identified to submit and edit it.
That said, I understand how this might not be immediately clear. I’ll make it more explicit across all documents describing the MIP author role to ensure there’s no confusion. Thank you for bringing this up—it’s a valuable point!
| - Any community member can propose the removal of an existing MIP Facilitator or MIP Reviewer by submitting a new MIP. | ||
| - Any community member can vote to approve or reject the selection or removal of MIP Facilitators and MIP Reviewers. | ||
| - As the community builds its capacity to effectively take on these responsibilities, key ecosystem players will continue to fulfill these roles as needed, supporting the bootstrapping and testing of the new processes. | ||
|
|
There was a problem hiding this comment.
Should we add the possibility for an MIP facilitator/reviewer to step down?
There was a problem hiding this comment.
Yes, I’ll add the possibility for an MIP Facilitator/Reviewer to step down in both this document and the attached Facilitator/Reviewer frameworks.
Additionally, I’ll clarify more explicitly that the roles of MIP Author, Reviewer, and Facilitator must be held by different individuals for any specific MIP. This separation of responsibilities ensures impartiality and avoids potential conflicts of interest.
| - Assist and support MIP Authors as necessary. | ||
|
|
||
| Functions: | ||
| - Accept or reject a MIP submission based on the established approval criteria. |
There was a problem hiding this comment.
It may not be a concern yet, but we may want to add an appeal process or a way to request a different facilitator. Being public/transparent with the process may be enough, but rejection is a powerful right and authors may need access to a second opinion in case of conflict.
There was a problem hiding this comment.
This is a valid point—thank you for raising it. While the MIP Upgrade already emphasizes transparency in the decision-making process, introducing an appeal mechanism could indeed enhance fairness and accountability.
That said, I personally believe this is a refinement best addressed in a future MIP once we have more practical experience with the current framework. This will allow us to design an appeal process based on real-world insights and the needs of the community. But I am happy to include this topic in future governance calls to hear more perspectives!
| - Any community member can propose themselves as a candidate for MIP Facilitator or MIP Reviewer by submitting a new MIP. | ||
| - Any community member can propose the removal of an existing MIP Facilitator or MIP Reviewer by submitting a new MIP. | ||
| - Any community member can vote to approve or reject the selection or removal of MIP Facilitators and MIP Reviewers. | ||
| - As the community builds its capacity to effectively take on these responsibilities, key ecosystem players will continue to fulfill these roles as needed, supporting the bootstrapping and testing of the new processes. |
There was a problem hiding this comment.
Does this imply an ability to circumvent the election process? It seems extraneous, assuming the "key ecosystem players" will be elected as described. Other than bootstrapping reviewers for this one mip, these roles should be voted in. It may be helpful to include "seed" reviewers as part of this mip so that it is bootstrapped upon approval.
There was a problem hiding this comment.
The reference to "key ecosystem players" stepping into roles during the initial phase is aimed solely at ensuring a smooth bootstrapping process for the MIP framework. The intent is not to circumvent the election process but to provide necessary support and safeguards as the community builds its capacity to effectively take on these responsibilities.
Your suggestion to explicitly include "seed" reviewers in this MIP is excellent—it could provide additional clarity and set the right expectations. I am already compiling a list of potential candidates for this initial phase, which will be shared for community review and attached to this proposal for approval through an eventual on-chain vote.
I’d love to hear your thoughts on how we can make this process as transparent and exemplary as possible to set a strong precedent for future candidates.
| However, due to the limited current capacity we propose that the Mina Foundation, in collaboration with o1 Labs and other members of the Mina ecosystem, will temporarily fill these new roles as needed while the processes are tested, and the capacity and expertise grows in the community. | ||
|
|
There was a problem hiding this comment.
Instead of generically appointing the foundation, why not identify specific individuals to serve in the necessary roles. I think "Foundation" is too ambiguous.
There was a problem hiding this comment.
The intent of referencing the Mina Foundation was to ensure there is a defined structure during the bootstrapping phase, but I agree that it might appear ambiguous without further details. I will work on clarifying these sections in line with this and your previous comment.
|
|
||
| We propose to introduce new types of public debates: | ||
|
|
||
| - During the expert part of the Review Phase: The MIP Facilitator will schedule, livestream and record open and public meetings between the MIP Author, the MIP Review Group and other stakeholders. The meeting minutes will be posted and shared in the designated channels for public consumption, allowing the community members who are interested to follow the process and contribute with comments. |
There was a problem hiding this comment.
Chatham house rules specified elsewhere may conflict with public deliberation.
There was a problem hiding this comment.
I agree that public deliberation is the default and preferred mechanism for fostering transparency and community trust. However, I acknowledge that certain discussions may require confidentiality under specific circumstances, such as the following examples that crossed my mind:
- Security concerns: Discussions around protocol vulnerabilities or other sensitive technical topics may need to be private to prevent exposing risks to potential attackers prematurely.
- Facilitation needs: Reviewers or stakeholders might find it beneficial to privately align on particularly sensitive or controversial topics before publishing their risk assessments or decisions.
In such cases, applying Chatham House Rules judiciously could provide a balance between transparency and the need for discretion. This could also ensure that when confidentiality is necessary, it is handled responsibly and documented appropriately. I would love to hear thoughts from the community on defining clear guidelines for when exceptions should apply to uphold accountability.
There was a problem hiding this comment.
Perhaps a private deliberation can be invoked by unanimous consent of the author, facilitator,
And reviewers? That could be too high of a threshold - alternatively how about a super majority (propose 67% threshold) vote to have a private session that is not shared with the community until a later (safe) point in time?
I think security should be the only exception. Private "alignment" sounds exactly like the kind of thing that is better done in public.
| We propose to introduce new types of public debates: | ||
|
|
||
| - During the expert part of the Review Phase: The MIP Facilitator will schedule, livestream and record open and public meetings between the MIP Author, the MIP Review Group and other stakeholders. The meeting minutes will be posted and shared in the designated channels for public consumption, allowing the community members who are interested to follow the process and contribute with comments. | ||
| - During the community part of the Review Phase: There will be a period of time for the community to carefully read and consider the MIP and the Review Group’s Risk Assessment. The MIP Facilitator will coordinate with the Mina Foundation to organize a community call where the MIP Author and the MIP Review Group can explain the MIP, including its risks, benefits and tradeoffs, in a way that is comprehensible to non-expert audiences and respond to community questions. Dates for the on-chain vote will be set, along with instructions on how to participate. |
There was a problem hiding this comment.
What is the role of foundation here? Why is it needed? Just to make announcements? Or does coordinate imply something more?
There was a problem hiding this comment.
The Foundation’s role in the community call stage of the Review Phase is primarily supportive and logistical. Specifically, this includes providing logistical and operational support for organizing the calls and leveraging its established communication channels to maximize community awareness and participation.
If the term “coordinate” feels ambiguous, I am happy to refine the wording in this section to more clearly emphasize the Foundation’s supportive role. Please feel free to share any additional thoughts!
|
|
||
| MIP Authors are responsible for writing the implementation plan, collaborating and establishing connections with the Dev Team and other stakeholders during the implementation. | ||
|
|
||
| As a general rule, unless the MIP says otherwise, the implementation should be finished no later than one year after the approval via on-chain vote, and follow an iterative process with short delivery cycles (less than 3 months). |
There was a problem hiding this comment.
Seems arbitrary. Does MIP approval automatically mean sufficient resources/funding to accomplish this? Is it expected that implementation constraints that would violate this be raised by the expert reviewers?
There was a problem hiding this comment.
100% agree this is arbitrary. Not all projects will be so short lived, and it seems really out of scope for this document to try and enforce this. Scoping things down is a discussion that can and should happen on the MIP, but shouldn't be a blanket rule that stifles larger proposals, such as upgrading our consensus mechanism, for example.
There was a problem hiding this comment.
This timeline was established based on lessons learned from past protocol upgrades, such as the Berkeley upgrade. We found that short, incremental delivery cycles (under 3 months) are beneficial for reducing complexity, increasing security, and allowing for better testing, all of which help avoid unexpected issues or side effects that may arise from large, monolithic changes.
While MIP approval signifies that the proposal has been accepted, it does not automatically guarantee sufficient resources or funding. It's important that the implementation plan includes resource estimates and addresses potential constraints or funding gaps. If there are concerns about feasibility, the MIP Reviewers and the Dev Team should raise them during the review process and provide feedback.
Since each MIP will have its unique requirements, it is expected that any changes or delays in the implementation process are communicated clearly with an appropriate rationale.
|
|
||
| The Dev Team designated for the implementation of each MIP must provide transparency about how the implementation is being executed, so that the community can verify that the changes are implemented in the way and time that they were intended. | ||
|
|
||
| A comprehensive suite of tests is mandatory. When necessary, they will properly communicate the rationale for potential changes and delays. |
There was a problem hiding this comment.
Why is this governance proposal overstepping into software development practices. While this is a good rule, it seems misplaced.
There was a problem hiding this comment.
Rules like this live best within the Mina repository, not the MIPs process.
There was a problem hiding this comment.
I understand why it could seem misplaced, the intention here was to incorporate some lessons learned from previous experiences in the implementation of approved MIPs and clarify the relationship between MIP Author and the Implementation team. That said, I appreciate your perspective. Would you suggest leaving this for a more specific MIP treated separately?
| The Admins of the Mina Discord Server will create new private channels to coordinate the operations and internal discussion for both of these roles, granting MIP Facilitators the necessary permissions to effectively facilitate communications and moderate these channels as needed. | ||
|
|
||
| **Implementation plan** | ||
| The Mina Foundation, in collaboration with o1 Labs and other members of the Mina ecosystem, will support the implementation of the proposed changes and help initiate this new process by temporarily filling the new roles as needed while the processes are tested, and the community develops the capacity to effectively assume these roles. |
There was a problem hiding this comment.
Instead of organizations, specify individuals.
There was a problem hiding this comment.
If there is a turnover concern, provide for MF to appoint alternates,
Which must be publicly announced and relevant docs updated, during the first year.
There was a problem hiding this comment.
Correct, I understand the need for more clarity here. I’ll work on rewording this to better reflect the plan and make the intent clearer.
| The risk of centralizing authority in the hands of a few reviewers is mitigated through transparency and broader community involvement. Public debates, deliberation tools, and well-defined reviewer roles ensure decisions reflect diverse perspectives and are not overly influenced by a small group. | ||
|
|
||
| **Risk of not having enough experts** | ||
| The proposal addresses the potential lack of expertise by assigning MIP Facilitators to manage the process, ensuring that a sufficient number of expert reviews are collected. If expertise is lacking, the MIP may be put on hold until necessary input is secured. |
There was a problem hiding this comment.
Consider whether all Reviewers really need to be elected. May be helpful to allow for any community member to volunteer to review a proposal? Perhaps with consent from elected experts to ensure expertise?
There was a problem hiding this comment.
Perhaps we can at least have an initially proposed list of reviewers submitted inside of this MIP? And then the community can elect or remove individual members from then on out.
There was a problem hiding this comment.
Any community member is already welcome to review and provide feedback on any proposal, and this won’t change with the upgrade. The introduction of elected experts aims to ensure that sufficient time and expertise are dedicated to creating a comprehensive risk assessment for the community. I can work on making this distinction clearer in the proposal.
| To prevent conflicts of interest, the proposal establishes separate roles for authors and reviewers. MIP Facilitators ensure that authors do not review their own proposals, promoting objectivity and impartiality in the evaluation process. | ||
|
|
||
| **Managing capacity for MIP reviews** | ||
| MIP Facilitators are responsible for managing MIP flow, estimating future volumes, and requesting additional resources as needed. They develop strategies to handle capacity overload, ensuring the process remains efficient during periods of high activity. |
There was a problem hiding this comment.
What sort of resources are they expected to have/request other than sufficient Facilitators and Reviewers? This may be confusing.
There was a problem hiding this comment.
My initial thought was indeed that additional facilitators and reviewers could be needed during periods of high activity. However, it's also possible that other resources, like tools or software for managing MIP flow or tracking progress, might also be necessary as the process becomes more complex. At this point, it's difficult to fully predict what additional resources will be required. The intention of this section is to offer flexibility, as the exact needs may evolve as we test and refine the process.
There was a problem hiding this comment.
I will be leaving 2 different reviews on this MIP: one as an official MIP reviewer, in which my role is to gate a MIP based on criteria for it to be ready to vote, and another which will include my personal opinion about the MIP. I'll denote them accordingly. This particular review is for the former (gating).
| For greater scalability, we propose the following: | ||
| - Short-term: Introduce MIP Facilitators to assist MIP Authors in the process, coordinate collaboration and help manage the flow of MIPs. | ||
| - Long-term: As the number of MIPs and experts increases, the role of MIP Facilitator could be automated so that it’s no longer needed (or within a lower capacity). MIP Reviewers could be randomly selected from a larger pool of qualified individuals. | ||
|
|
||
| For greater decentralization, we propose the following: | ||
| - Provide information and onboarding materials to the community to empower members and give them more agency in the decision-making processes. | ||
| - Implement the system on-chain (eventually, once tested) so that processes are automated, eliminating dependency on the Mina Foundation to manage these processes manually. |
There was a problem hiding this comment.
Some of these proposals aren't actually included in this MIP. Please rescope the rational section so that it only rationalizes what is proposed here. If you want to mention these somewhere, please add a section for "potential next steps" to discuss these, so that it's clear that this is not part of the content that is being voted on within this MIP.
| - Any community member can propose themselves as a candidate for MIP Facilitator or MIP Reviewer by submitting a new MIP. | ||
| - Any community member can propose the removal of an existing MIP Facilitator or MIP Reviewer by submitting a new MIP. | ||
| - Any community member can vote to approve or reject the selection or removal of MIP Facilitators and MIP Reviewers. |
There was a problem hiding this comment.
Will there be a full on chain vote every single time? Have we done an analysis on the expected transaction throughput a MIP vote has on the network? If we do too many open votes at once, we could run into congestion issues on the chain.
|
|
||
| **Drafting Phase - MIP Submission** | ||
|
|
||
| During the Drafting phase, when the MIP Author submits a new MIP as a pull request in GitHub, a MIP Facilitator is assigned to assist the MIP Author, review the MIP and (if necessary, consult with the MIP Reviewers to) decide whether to approve or reject the pull request according to the following acceptance criteria: |
There was a problem hiding this comment.
This needs to be defined before I would consider this ready for a vote.
| - Communicates the decision to the MIP author. | ||
|
|
||
| **Review Phase - Part 1: Risk Assessment** | ||
| We propose to create a pool of experts to review MIPs across the 3 categories. For each MIP, the Author reaches out to the pool of experts for the relevant category and sends a Request for Comments. To maintain independence, the Author does not choose who the Reviewers are. This MIP Review Group has a period to review the MIP and provide their feedback. The MIP Author can incorporate the feedback into the MIP until a final draft is completed. If the MIP Author does not incorporate the feedback, the MIP process still continues. |
There was a problem hiding this comment.
I think this part of the process needs more clarity. In addition to the questions and notes raised by @jrwashburn above, there needs to be more clarity around how a MIP is determined to fit into the 3 categories, and whether a MIP can span across multiple categories. Eg: most economic changes have direct consensus considerations in the protocol that effect security. When and how do we ensure the protocol reviewer group is looped into the risk assessment of such a MIP? I can think of crossover examples like this for nearly each permutation of the proposed categories.
|
|
||
| When the MIP Author considers the draft ready for the final review, editing stops for at least 1 week to allow MIP Reviewers to write individually a Risk Assessment that is incorporated into the designated section of the MIP template. | ||
|
|
||
| The MIP Facilitator must check that every MIP has enough reviews to complete the Review phase (at least 3 if there is agreement, 5 otherwise). The MIP Facilitator can also coordinate communications and collaborate with the MIP Author to schedule any necessary meetings, and to define a roadmap with target dates for each milestone in the MIP process. |
There was a problem hiding this comment.
How do we ensure there are enough reviewers in each category to reach these thresholds of 3 or 5 reviews?
| The risk of centralizing authority in the hands of a few reviewers is mitigated through transparency and broader community involvement. Public debates, deliberation tools, and well-defined reviewer roles ensure decisions reflect diverse perspectives and are not overly influenced by a small group. | ||
|
|
||
| **Risk of not having enough experts** | ||
| The proposal addresses the potential lack of expertise by assigning MIP Facilitators to manage the process, ensuring that a sufficient number of expert reviews are collected. If expertise is lacking, the MIP may be put on hold until necessary input is secured. |
There was a problem hiding this comment.
Perhaps we can at least have an initially proposed list of reviewers submitted inside of this MIP? And then the community can elect or remove individual members from then on out.
There was a problem hiding this comment.
This review is my personal opinions on the MIP. None of these points need to be addressed in order for me to approve the MIP for voting.
Overall, I think this MIP is unnecessary as is. This seems to be a lot of process to solve what I see as a non-problem. I find the motivation that we need a more complex process to be unconvincing. The truth is: we haven't received a lot of MIPs yet. Our energy would be better placed in making the MIP process as light-weight as possible and creating more spaces for people to collaborate, rather than to make the process more complicated and have more steps.
And still, this proposal (as is) doesn't have much impact. All it really achieves in it's current scope is to break up some responsibilities, add more kinds of roles, and proposes an underbaked election process to give the community control over who is staffed in those roles. The election process became a necessity of expanding the scope of the roles and adding more roles, but I'm not seeing the benefit of that first step to begin with. So it seems we are complicating the process with little benefit.
I think the process doesn't really need much changing as is. And if we want to do anything, I think we should move to something which is even closer aligned to the EIP process, rather than inventing a novel process ourselves by leaning on unrelated democratic systems.
Finally, I have concerns about the direction towards which this proposal is moving the MIPs process as a whole. The current MIPs process is all out in the open, but this is adding key steps which don't happen in a publicly auditable manner. Specifically, the process through which facilitators and reviewers are selected for a given MIP doesn't seem to have enough criteria or guard rails around it, making it rife for potential manipulation should a bad actor get involved in the future.
|
|
||
| MIP Authors are responsible for writing the implementation plan, collaborating and establishing connections with the Dev Team and other stakeholders during the implementation. | ||
|
|
||
| As a general rule, unless the MIP says otherwise, the implementation should be finished no later than one year after the approval via on-chain vote, and follow an iterative process with short delivery cycles (less than 3 months). |
There was a problem hiding this comment.
100% agree this is arbitrary. Not all projects will be so short lived, and it seems really out of scope for this document to try and enforce this. Scoping things down is a discussion that can and should happen on the MIP, but shouldn't be a blanket rule that stifles larger proposals, such as upgrading our consensus mechanism, for example.
|
|
||
| https://drive.google.com/file/d/1RWpwc08Oj43zE25oKRdSmh-Gud_8RNfl/view?usp=drive_link | ||
|
|
||
| ### Guidelines for Implementation |
There was a problem hiding this comment.
I would really recommend taking this entire section out of this MIP. It's not really in scope of the MIP process to enforce engineering standards for how MIPs are implemented. We can't ever guarantee the competancy of a given team to deliver a MIP, so the MIP process is really more around what we (the community) want to see merged, not whether or not we think it will be merged within a certain timeline, or how it should be built.
|
|
||
| The Dev Team designated for the implementation of each MIP must provide transparency about how the implementation is being executed, so that the community can verify that the changes are implemented in the way and time that they were intended. | ||
|
|
||
| A comprehensive suite of tests is mandatory. When necessary, they will properly communicate the rationale for potential changes and delays. |
There was a problem hiding this comment.
Rules like this live best within the Mina repository, not the MIPs process.
There was a problem hiding this comment.
In general this MIP articulates the proposed changes in a comprehensive way that meets the standard for a MIP to be accepted into the 'Review' stage. I would encourage the community to thoroughly analyse the merits of the proposal with respect to security considerations/safeguards against manipulation, the efficiency of the process, transparency, the selection of and ongoing roles of Facilitators and Reviewers and expertise development.
This MIP adds several improvements to the MIP process