Timeleap Enhancement Proposals

TEP: 1
Title: Timeleap Enhancement Proposals
Author: Timeleap Team team@timeleap.com
Status: Draft
Type: Process
Created: 2024-06-11
Updated: 2024-06-11


This document describes the process for creating, discussing, and implementing Timeleap Enhancement Proposals (TEPs). TEPs are a mechanism for proposing major new features, processes, or other significant changes to the Timeleap ecosystem.


To ensure a structured and transparent method for introducing changes to Timeleap, we adopt a process inspired by Python Enhancement Proposals (PEPs). This process facilitates community involvement, thorough discussion, and clear documentation of significant changes.


TEP Workflow

  1. Idea Stage:

    • Discussion: Proposals begin with discussions in the Timeleap Discourse forum. There will be one category per product and additional categories for other significant areas, such as governance.
    • Community Consensus: Engage with the community to refine the idea. Aim for a rough consensus before moving forward.
  2. Drafting a TEP:

    • TEP Format: Follow the standard format outlined below.
    • Submission: Submit the draft TEP to the Timeleap website GitHub repository under the src/routes/docs/teps directory.
  3. Review and Acceptance:

    • Initial Review: A TEP Editor will review the proposal to ensure adherence to guidelines and completeness.
    • Public Review: The proposal is open for public review and feedback.
    • Final Comment Period (FCP): After sufficient feedback, the TEP enters the FCP, where the final call for comments is made.
  4. Company Approval:

    • Decision by Timeleap: After the FCP, the proposal will be submitted to the company’s decision-makers for final approval.
    • Outcome: Based on the review, Timeleap will mark the proposal as Approved, Rejected, or Deferred.
  5. Implementation:

    • Execution: Approved TEPs can proceed to implementation, and progress should be documented.

TEP Format

Each TEP should include the following sections:

  • TEP Number: Assigned by the TEP Editor.
  • Title: A short, descriptive title of the proposal.
  • Author(s): Name and contact information of the author(s).
  • Status: The current status of the TEP (e.g., Draft, Accepted, Rejected, Deferred).
  • Type: The type of proposal (e.g., Product, Process).
  • Created: Date the proposal was created.
  • Updated: Dates when the proposal was updated.
  • Abstract: A summary of the proposal.
  • Motivation: The rationale behind the proposal and the problem it aims to solve.
  • Specification: Detailed description of the proposed change.
  • Rationale: Explanation of why the proposed solution is the best option.
  • Backwards Compatibility: Analysis of how the proposal affects backward compatibility.
  • Reference Implementation: If applicable, a reference implementation.
  • References: Any references or additional documentation.


A structured proposal process allows for better community involvement and more organized documentation of significant changes. This ensures that every significant change is systematically discussed, reviewed, and approved.

Backwards Compatibility

This TEP introduces a new process and does not affect existing functionality.

Reference Implementation