This repository holds Tidegate Enhancement Proposals (TEPs). A TEP is a design document that describes a significant change to Tidegate, the reasoning behind it, and how it will be built and rolled out. The process is modeled on Kubernetes KEPs and Python PEPs, scaled down for a young project.
TEPs exist so that design decisions happen in the open and leave a record. Code review shows how something was built. A TEP shows why it was built that way, which alternatives were rejected, and what security tradeoffs were accepted. For a privileged access management system, that record matters to contributors and to the people who have to trust the software.
The full process is defined in TEP-0001. This page is a summary.
Write a TEP for changes that other contributors or operators need to agree on before the code lands. Typical cases:
- A new user-facing feature or a new component.
- A change to the security model: authentication, authorization, credential handling, session brokering, audit logging, or trust boundaries between components.
- A breaking change to an API, CLI, configuration format, or on-disk or wire format.
- A new external dependency that becomes part of the trusted computing base.
- A change to project governance or to this process.
Bug fixes, refactors, documentation, and small improvements that do not change behavior go straight to a pull request in the relevant code repository. When in doubt, open a GitHub issue in this repository and ask.
- Open an issue using the "TEP tracking issue" template. Describe the problem in a few paragraphs and gather early feedback before writing a full design.
- Copy
teps/0000-template/toteps/NNNN-short-title/. Take the next free number (see the index below) and use lowercase, hyphenated words for the title. - Fill in the front matter and as many sections as you can. Set
status: draft. - Open a pull request. Discussion happens on the PR. Small, early PRs are fine; a TEP does not need to be complete to be merged as
provisional. - Once approvers agree on the direction, the TEP is merged as
provisional. When the design details are settled, a follow-up PR moves it toimplementableand implementation can start. - When the work ships, update the status to
implemented.
Run scripts/validate-teps.py locally before pushing. CI runs the same checks.
| Status | Meaning |
|---|---|
draft |
Under discussion in a pull request. Not merged yet. |
provisional |
The project agrees the problem is worth solving and the direction is sound. Design details may still be open. |
implementable |
The design is approved. Implementation can begin. |
implemented |
The change has shipped in a release. |
deferred |
Accepted in principle, but nobody is working on it. |
rejected |
Approvers decided against it. The TEP records why. |
withdrawn |
The author dropped it. |
replaced |
Superseded by another TEP, named in superseded-by. |
| TEP | Title | Status | Authors |
|---|---|---|---|
| 0001 | TEP process | implemented | @trevex |
| 0002 | Architecture vision | draft | @trevex |
See CONTRIBUTING.md for pull request titles and how to sign off commits. Please follow our Code of Conduct in all project spaces.
All TEPs are licensed under the Apache License 2.0, the same license as Tidegate.