This TEP template is a guideline of the sections that a TEP should contain. Extra sections may be added if appropriate, and unnecessary sections may be noted as such.
The TEP should start with a title:
TEPs go through a number of phases in their lifetime:
- Discussion: The TEP is being actively discussed and is being improved by its author. The mailing list discussion of the TEP should include the TEP number (TEPxxx) in the subject line so they can be easily related to the TEP.
- Progress: Consensus was reached on the mailing list and implementation work has begun.
- Completed: The implementation has been merged into master.
- Superseded: This TEP has been abandoned in favor of another approach.
A list of people that should be pinged if there is some discussion of this proposal.
All development branches containing work on this TEP should be linked to from here.
All pull requests submitted relating to this TEP should be linked to from here. (A TEP does not need to be implemented in a single pull request if it makes sense to implement it in discrete phases).
This section describes the need for the TEP. It should describe the existing problem that it is trying to solve and why this TEP makes the situation better. It should include examples of how the new functionality would be used and perhaps some use cases.
This section lists the major steps required to implement the TEP. 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.
This section describes the ways in which the TEP breaks backward incompatibility.
If there were any alternative solutions to solving the same problem, they should be discussed here, along with a justification for the chosen approach.