Tutor Enhancement Proposals (TEPs) are texts written by the Tutor community to discuss changes to the project. These changes can be of different natures: they can be written to address technical issues, community organisation questions, governance, etc.
Although the name of TEPs was explicitely inspired by Python’s PEPs and Open edX’s OEPs, the process for writing and accepting (or rejecting) a TEP is much less formal or involved.
Anyone can write a TEP and submit it to the community, such that anyone can comment on it. TEPs should be written only for important, non-consensual changes. For instance, we should not write a TEP for a bugfix. On the other hand, changes that affect a large part of the Tutor codebase, or backward-incompatible changes that impact many users or developers would probably warrant a TEP.
As always when discussing technical topics, TEP authors are encouraged to make their proposals as detailed as possible. Screenshots, schemas and code excerpts are all welcome addition to TEPs to foster richer conversations.
The decision to accept or to reject a TEP is made by the Tutor project maintainers. Project maintainers strive to achieve consensus. When consensus is not possible, the decision is made by @regis, who effectively acts as a BDFL for the project.
A TEP does not require explicit approval or discussion. In most cases, we should assume that silence is consent, following the principles of lazy consensus. Lazy consensus works if the community is sufficiently active and if proposals are made with enough advance notice to leave time for other people to comment (see Warnock’s Dilemma). Thus, all maintainers are strongly encouraged to respond to every TEP, even if just with a 
It should be noted that having an accepted TEP does not guarantee that someone will actually work on it, not does it imply a deadline for the realisation of the work.