The intention of this post is to introduce the idea of Mina Improvement Proposals by sketching out a draft MIP process.
Goals:
- Promote high quality feature proposals for Mina Protocol and a robust process for validating and deciding upon protocol changes
- Encourage speed and fluidity in the process (allow Mina to iterate quickly as a protocol generally)
- Transparent, high participation, decentralised decision making
- Leverage the good work done by other projects
Rationale
- Further decentralisation of the Mina ecosystem
- Empower the community to participate and reach decisions on changes to the protocol in a way that is accessible and inclusive for all members
What next?
- Seeking review and feedback here on MinaResearch from ecosystem participants, community and interested parties
- Adapt and iterate based on participant feedback
- Poll the community to assess sentiment on the process and to gather further feedback
- Test in beta mode by running a series of decisions through the process in advance of the next hard fork.
Some ideas for providing feedback:
- As a potential author, do you believe this is an open and transparent process? If not, what aspects need to be more clear?
- As a community member, do you believe this process is inclusive and encourages broad participation? If not, what are the barriers to participation?
- Do you believe any other docs, resources or tools are required for the process to run fluidly?
- Do you have any other comments or questions?
Mina Improvement Proposals
What is a MIP?
MIP stands for Mina Improvement Proposal. An MIP is a design document providing information to the Mina community, or describing a new feature for Mina or changes to the parameters of the protocol. The MIP should provide a concise technical specification of the feature and a rationale for its inclusion in the protocol. The MIP author is responsible for championing their proposal, building consensus within the community and incorporate feedback.
MIP Rationale
The Mina Foundation intends MIPs to be the primary mechanism for proposing new features, collecting community input on an issue, and for documenting design decisions that have gone into Mina. It is intended to be a highly participatory and transparent process for complex decision making on changes to the Mina Protocol. In the long term, the vision for Mina is for more decentralized decision making, and during every iteration, we will work towards that goal.
The MIP Process
This document is not intended to be the end state process for MIPs, but rather servers as a draft proposal to encourage discussion and feedback from community and all stakeholders. The process will be evaluated and adapted on a regular basis, based on participant feedback and robustly testing in beta mode by running a series of decisions through the process.
The process described here is inspired by the long track record in this area by other projects, particularly Ethereum.
Types of MIP
A Standards Track MIP describes any change that affects most or all Mina protocol, such as a change to the network protocol, a change in consensus or block validity rules, to the zero-knowledge cryptography or any change in the accounts or rules around MINA. Standards Track MIPs, as well as serving as the design document, should include a reference implementation where appropriate.
Process discuss requirement for this type
Meta discuss requirement for this type
MIP format and structure
Template and Github repo for the beta version of MIP to be created once the ‘Idea’ has been vetted
MIP Process
Idea - The MIP is put forward by the author(s) for community discussion and sentiment gathering on Mina Research and via Polling e.g., (Pol.is). The MIP is not tracked within the MIP repository.
Draft - The MIP has been formally drafted and submitted to the Github repository. The MIP is checked by the MIP Editors for compliance and is merged when it has been validated.
Review - Dev Teams, Community and Advisory Group provide feedback on the MIP
Last call This is the final review window for an MIP before moving to Finalization. The MIP Editors will assign Last Call status and set a review end date, typically 2 weeks later.
If this period results in the identification of high impact issues the MIP will be moved back to Review.
Finalization The proposal is deemed to have met all the appropriate criterias consensus to be considered and the Dev Teams are in a position to incorporate the changes into the implementation schedule
Inactive A MIP that has been deemed to be inactive for a period of 1 month.
Withdrawn - The MIP Author(s) have withdrawn the proposed MIP. The proposal can no longer be resurrected using this MIP number. If the idea is pursued at later date it is considered a new proposal.
MIP Workflow
How to create a MIP
1. Submit a MIP Idea to MinaResearch
If you have an idea you would like to propose, first search through previously proposed or discussed ideas in this MinaResearch. If your idea is original or sufficiently distinct, start a new conversation thread to enable a discussion with the community on MinaResearch (see guidelines here). You should seek feedback and try to build informal consensus, as well as keep track of any critical feedback so that you can address it later.
For complex decisions, it is recommended that the Author start with gathering criteria and information from the community for complicated solutions. The Author is encouraged to poll the community at this point for the criteria that a good solution/proposal would fulfil, or to gather sentiment for the idea generally.
2. Create a Draft MIP and submit it to the MIP repository
Once you’ve allowed enough time for feedback and a properly formatted (see below section) draft MIP has been written, it should be submitted to the MIPs GitHub repository as a pull request, accompanied by a summary of the discussion so far in the comment section, with links where possible.
A member of the MIP Working Group will assign a MIP number, select the appropriate MIP type (Standards, Informational, or Meta and begin the validation process)
3. Wait for approval and/or feedback from the MIP Editors
A MIP editor will assign a MIP number, select the appropriate MIP type and merge the pull request if the conditions have been met. Otherwise, the Author will receive a written notification and reasons why their draft was not merged.
Roles
Authors
Responsible for vetting the idea, gathering sentiment, writing the MIP, championing MIP through process, gathering and incorporating community feedback including alternative and dissenting views. Multiple authors can contribute to one MIP, but one person must be identified to submit and edit it.
MIP Editors
The MIP Editors are here to ensure the MIP is complaint to the process at all times and that process is fluid and there is progression of MIPs through the process . If you have questions regarding the MIP process, they can point you in the right direction.
Dev Teams
The team responsible for checking technical specifications and implementing the MIP once finalized.
Advisory Group
A group comprised of subject matter experts representative of impacted developers and community members. It is important that impacted stakeholders for a particular MIP are identified and included in the process. This is not a fixed group and impacted participants may vary for each MIP.
What belongs in a successful MIP?
<TO BE UPDATED)
MIP Formats and Templates
MIPs should be written in markdown format. There is a template to follow <TO BE UPDATED)
MIP Header Preamble
<TO BE UPDATED)
