MIP, MD and MG

We differentiate between issue, MD and MIP.

An overview of the MIPs and MDs can be found in the OVERVIEW.

The lifecycle of a proposal should be:

1. create a new issue to register the intent to write an MD/MIP and its scope.
2. If 1. is approved (this may require some discussions), start writing an MD and create a PR for it using this Draft.
3. The author MAY start an MIP using this Draft in the same PR as the MD. However, doing so may slow down the governance approval of the MD. A preferred approach is to start with the MD, then await governance approval and only then start the MIP in a separate PR.

graph LR
    A[Idea: issue] --> B[Request: MD] --> C[Solution: MIP]

Loading

The Glossary contains an alphabetically ordered list of terms used in this repository. In addition MG serves as a platform to define glossary terms, which are used in the MIPs and MDs.

!!! info For more information on the process in this repository, see alsoMIP-0.

Movement Desiderata (MD)

MDs serve to capture the objectives behind the introduction of a particular MIP. Any

• wish,
• requirement, or
• need

related to MIPs should be documented as an MD and stored in the MD directory.

A template with instructions is provided at md-template. See MIP-0 for a definition of its functionality.

Movement Improvement Proposal (MIP)

A template with instructions is provided at mip-template. See MIP-0 for a definition of its functionality.

Deciding whether to propose

You SHOULD draft and submit an MIP, if any of the following are true:

• Governance for the relevant software unit or process requires an MIP.
• The proposal is complex or fundamentally alters existing software units or processes.

AND, you plan to do the work of fully specifying the proposal and shepherding it through the MIP review process.

You SHOULD NOT draft an MIP, if any of the following are true:

• You only intend to request a change to software units or processes without overseeing specification and review.
• The change is trivial. In the event that an MIP is required by governance, such trivial changes usually be handled as either errata or appendices of an existing MIP.

Glossary and Movement Gloss (MG)

A template with instructions is provided at mg-template. See MIP-15 for a definition of its functionality. See MG-0 for an example.

An alphabetically ordered list of terms is provided in the glossary.

MGs serve to capture the definitions of terms introduced in the MIPs and MDs. The creation of a new MG requires an MIP or MG (since new terms are introduced through the MIP or MG).

See MG-0 for an example to get started. A template is provided at mg-template.

Files and numbering

Each MIP, MD or MG is stored in a separate subdirectory with a name mip-<number>, md-<number> or mg-<number>. The subdirectory contains a README.md that describes the MIP, MD, or MG. All assets related to the MIP, MD or MG are stored in the same subdirectory.

An MIP/MD starts as Drafts. They DO NOT acquire a number at this point.

An MIP/MD is assigned their PR number as soon as they are in the Review process. MDs that do not introduce a new MIP/MD are also accepted. Thus, there will be gaps in the MIP/MD number sequence. These gaps will also emerge when MIPs/MDs are deprecated or rejected.

PRs that don't introduce a new MIP/MD are also accepted, for example MIPs/MDs can be updated. PRs that Update a MIP/MD should state so in the PR title, e.g. [Update] MIP-.....

Status Terms

An MIP/MD is proposed through a PR. Each MIP/MD PR should have a status in the name in the form [status] MIP/MD-x: ....

An MIP/MG should at all times have one of the following statuses:

• Draft - (set by author) An MIP/MD that is open for consideration. (It does not yet hold an MIP/MD number)
• Review - (set by author) The MIP/MD is under peer review. The MIP/MD should receive an MIP/MD number, according to the rules described in the Files and numbering section. At this point the editor should be involved to ensure the MIP/MD adheres to the guidelines.

!!! info In case the editors are not available for an unacceptable long period of time, a reviewer should assume the role of the editor interim.

After acceptance the MIP/MD is merged into main and the branch should be deleted.

Additionally, the following statuses are used for MIPs/MDs that are not actively being worked on:

• Stagnant - an MIP/MD that has not been updated for 6 months. Upon this status the PR will be closed.
• Withdrawn - an MIP/MD that has been withdrawn.

Finally, an MIP/MD can also be updated:

• Update - (set by author) An MIP/MD is being updated. The title should list the MIP/MD number, e.g. [Update] MIP-0 ....

Governance

For more information on the role of the governance, see MIP-0: Governance.

Currently the governance consists of @franck44, @l-monninger, @apenzk, @0xmovses, @bhenhsi.

Editor

For more information on the role of the editor, see MIP-0: Editor.

Currently the editors are @apenzk.

Code owners

An author commits to becoming the owner of the MIP/MD they propose. This means that for any future changes to the MIP/MD the author will be notified.

The author MUST add themselves as a code owner in CODEWONERS.