Add biap_template

Author: matthew-brett

doc/source/devel/biaps/biap_template.rst

@@ -0,0 +1,90 @@
+==================================
+BIAP X — Template and Instructions
+==================================
+
+:Author: <list of authors' real names and optionally, email addresses>
+:Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>
+:Type: <Standards Track | Process>
+:Created: <date created on, in yyyy-mm-dd format>
+:Resolution: <url> (required for Accepted | Rejected | Withdrawn)
+
+
+Abstract
+--------
+
+The abstract should be a short description of what the BIAP will achieve.
+
+Note that the — in the title is an elongated dash, not -.
+
+Motivation and Scope
+--------------------
+
+This section describes the need for the proposed change. It should describe
+the existing problem, who it affects, what it is trying to solve, and why.
+This section should explicitly address the scope of and key requirements for
+the proposed change.
+
+Usage and Impact
+----------------
+
+This section describes how users of Nibabel will use features described in this
+BIAP. It should be comprised mainly of code examples that wouldn't be possible
+without acceptance and implementation of this BIAP, as well as the impact the
+proposed changes would have on the ecosystem. This section should be written
+from the perspective of the users of Nibabel, and the benefits it will provide
+them; and as such, it should include implementation details only if
+necessary to explain the functionality.
+
+Backward compatibility
+----------------------
+
+This section describes the ways in which the BIAP breaks backward compatibility.
+
+The mailing list post will contain the BIAP up to and including this section.
+Its purpose is to provide a high-level summary to users who are not interested
+in detailed technical discussion, but may have opinions around, e.g., usage and
+impact.
+
+Detailed description
+--------------------
+
+This section should provide a detailed description of the proposed change.
+It should include examples of how the new functionality would be used,
+intended use-cases and pseudo-code illustrating its use.
+
+
+Related Work
+------------
+
+This section should list relevant and/or similar technologies, possibly in other
+libraries. It does not need to be comprehensive, just list the major examples of
+prior and relevant art.
+
+
+Implementation
+--------------
+
+This section lists the major steps required to implement the BIAP.  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 to related pull requests as the implementation progresses.
+
+Any pull requests or development branches containing work on this BIAP should
+be linked to from here.  (A BIAP does not need to be implemented in a single
+pull request if it makes sense to implement it in discrete phases).
+
+
+Alternatives
+------------
+
+If there were any alternative solutions to solving the same problem, they should
+be discussed here, along with a justification for the chosen approach.
+
+
+Discussion
+----------
+
+This section may just be a bullet list including links to any discussions
+regarding the BIAP:
+
+- This includes links to mailing list threads or relevant GitHub issues.

doc/source/devel/governance.rst

@@ -138,7 +138,7 @@ Enhancement Proposals (BIAPs)
 =============================
 
 Any proposals for enhancements of Nibabel should be written as a formal BIAP
-following the template :doc:`biap-template`. The BIAP must be made public and
+following the template :doc:`biap_template`. The BIAP must be made public and
 discussed before any vote is taken. The discussion must be summarized by a key
 advocate of the proposal in the appropriate section of the BIAP. Once this
 summary is made public and after sufficient time to allow the core team to