Skip to content

MEP 0 - MEP Purpose and Guidelines

  • Author: Rodda John
  • Status: Adopted
  • Adopted: 2024-04-231

Overview

MEP stands for Moab Enhancement Proposal2. A MEP's audience is the engineering team at Moab and is not designed for product iteration. Things like CI / CD, modeling, architecture changes, technical specifications, are all reasonable topics for a MEP. A MEP should not be concerning a product feature, or involving anything that requires a non-engineer to review it.

MEP Process

  1. Open a PR to the docs repository adding a proposal to the ./proposals subdirector
    • This proposal should be read for clarity, correctness is the responsibility of the author(s)
  2. Upon discussion and comment from the broader engineering team, the MEP shall either be accepted or rejected. Before a MEP is accepted or rejected, it can undergo changes. These changes should be in the form of PRs against it to create an audit trail.

All MEPs shall have the following block at the top of the file (just as this one does).

Author: <the author>
Status: <the status>
Adopted: <timestamp>

The following are permitted statuses:

  • Draft
  • Adopted
  • Rejected
  • Superseded (by MEP <#>)

To amend a MEP, a PR should be made against that MEP and reviewed. If a heavier review process is warranted, a MEP shall be created to edit the original MEP.

Upon a MEP being adopted, edits for clarity should be made as the document switches from being a proposed change to a guide and representation of the present world.

A MEP shall be entited #-<name>.md -- e.g. 0-meps.md

  1. This MEP was adopted chronologically later than earlier MEPs but is denoted the 0th as it explains the process ↩

  2. MEPs (obviously) take an enormous amount of inspiration from PEPs ↩