Skip to content

Files

Latest commit

6857123 · Oct 16, 2020

History

History
This branch is 843 commits behind tektoncd/community:main.

teps

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Jul 24, 2020
Jul 7, 2020
Aug 14, 2020
Aug 14, 2020
Aug 12, 2020
Sep 23, 2020
Sep 2, 2020
Sep 21, 2020
Sep 15, 2020
Sep 9, 2020
Oct 16, 2020
Aug 24, 2020
Oct 6, 2020
Oct 12, 2020
Oct 12, 2020
Oct 7, 2020
Oct 13, 2020
Sep 3, 2020
Jul 21, 2020

Tekton Enhancement Proposals (TEPs)

A Tekton Enhancement Proposal (TEP) is a way to propose, communicate and coordinate on new efforts for the Tekton project. You can read the full details of the project in TEP-1.

What is a TEP

A standardized development process for Tekton is proposed in order to

  • provide a common structure and clear checkpoints for proposing changes to Tekton
  • ensure that the motivation for a change is clear
  • allow for the enumeration stability milestones and stability graduation criteria
  • persist project information in a Version Control System (VCS) for future Tekton users and contributors
  • support the creation of high value user facing information such as:
    • an overall project development roadmap
    • motivation for impactful user facing changes
  • ensure community participants are successfully able to drive changes to completion across one or more releases while stakeholders are adequately represented throughout the process

This process is supported by a unit of work called a Tekton Enhancement Proposal (TEP). A TEP attempts to combine aspects of the following:

  • feature, and effort tracking document
  • a product requirements document
  • design document

into one file which is created incrementally in collaboration with one or more Working Groups (WGs).

This process does not block authors from doing early design docs using any means. It does not block authors from sharing those design docs with the community (during Working groups, on Slack, GitHub, ….

This process acts as a requirement when a design docs is ready to be implemented or integrated in the tektoncd projects. In other words, a change that impact other tektoncd projects or users cannot be merged if there is no TEP associated with it.

This TEP process is related to

  • the generation of an architectural roadmap
  • the fact that the what constitutes a feature is still undefined
  • issue management
  • the difference between an accepted design and a proposal
  • the organization of design proposals

This proposal attempts to place these concerns within a general framework.

See TEP-1 for more details.

The TEP OWNERS are the main owners of the following projects:

Merging TEPs

  • TEP should be merge as soon as possible in the proposed state. As soon as a general consensus is reached that the TEP, as described (even if incomplete) make sense to pursue, the TEP can be merged. The authors can then update the missing part in follow-up pull requests and move it to implementable.
  • TEP should be approved by at least two owners from different company. This should prevent a company to force push a TEP (and thus a feature) in the tektoncd projects.