<liclass="toctree-l1"><aclass="reference internal" href="../min_dep_policy.html">Dependency version policy</a></li>
<liclass="toctree-l1 current active has-children"><aclass="reference internal" href="index.html">Matplotlib Enhancement Proposals</a><detailsopen="open"><summary><spanclass="toctree-toggle" role="presentation"><iclass="fa-solid fa-chevron-down"></i></span></summary><ulclass="current">
<liclass="toctree-l2 current active"><aclass="current reference internal" href="#">MEP Template</a></li>
<p>This MEP template is a guideline of the sections that a MEP should
contain. Extra sections may be added if appropriate, and unnecessary
sections may be noted as such.</p>
<sectionid="status">
<h2><aclass="toc-backref" href="#id2" role="doc-backlink">Status</a><aclass="headerlink" href="#status" title="Link to this heading">#</a></h2>
<p>MEPs go through a number of phases in their lifetime:</p>
<ulclass="simple">
<li><p><strong>Discussion</strong>: The MEP is being actively discussed on the mailing
list and it is being improved by its author. The mailing list
discussion of the MEP should include the MEP number (MEPxxx) in the
subject line so they can be easily related to the MEP.</p></li>
<li><p><strong>Progress</strong>: Consensus was reached and implementation work has begun.</p></li>
<li><p><strong>Completed</strong>: The implementation has been merged into main.</p></li>
<li><p><strong>Superseded</strong>: This MEP has been abandoned in favor of another
approach.</p></li>
<li><p><strong>Rejected</strong>: There are currently no plans to implement the proposal.</p></li>
</ul>
</section>
<sectionid="branches-and-pull-requests">
<h2><aclass="toc-backref" href="#id3" role="doc-backlink">Branches and Pull requests</a><aclass="headerlink" href="#branches-and-pull-requests" title="Link to this heading">#</a></h2>
<p>All development branches containing work on this MEP should be linked to from here.</p>
<p>All pull requests submitted relating to this MEP should be linked to
from here. (A MEP does not need to be implemented in a single pull
request if it makes sense to implement it in discrete phases).</p>
</section>
<sectionid="abstract">
<h2><aclass="toc-backref" href="#id4" role="doc-backlink">Abstract</a><aclass="headerlink" href="#abstract" title="Link to this heading">#</a></h2>
<p>The abstract should be a short description of what the MEP will achieve.</p>
</section>
<sectionid="detailed-description">
<h2><aclass="toc-backref" href="#id5" role="doc-backlink">Detailed description</a><aclass="headerlink" href="#detailed-description" title="Link to this heading">#</a></h2>
<p>This section describes the need for the MEP. It should describe the
existing problem that it is trying to solve and why this MEP makes the
situation better. It should include examples of how the new
functionality would be used and perhaps some use cases.</p>
</section>
<sectionid="implementation">
<h2><aclass="toc-backref" href="#id6" role="doc-backlink">Implementation</a><aclass="headerlink" href="#implementation" title="Link to this heading">#</a></h2>
<p>This section lists the major steps required to implement the MEP.
Where possible, it should be noted where one step is dependent on
another, and which steps may be optionally omitted. Where it makes
sense, each step should include a link related pull requests as the
implementation progresses.</p>
</section>
<sectionid="backward-compatibility">
<h2><aclass="toc-backref" href="#id7" role="doc-backlink">Backward compatibility</a><aclass="headerlink" href="#backward-compatibility" title="Link to this heading">#</a></h2>
<p>This section describes the ways in which the MEP breaks backward incompatibility.</p>
</section>
<sectionid="alternatives">
<h2><aclass="toc-backref" href="#id8" role="doc-backlink">Alternatives</a><aclass="headerlink" href="#alternatives" title="Link to this heading">#</a></h2>
<p>If there were any alternative solutions to solving the same problem,
they should be discussed here, along with a justification for the