Skip to content

Files

This branch is 45 commits behind pingcap/tidb:master.

design

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Nov 20, 2024
Jun 8, 2022
Jun 4, 2019
Apr 8, 2019
Jun 4, 2019
Jun 4, 2019
Oct 25, 2018
Apr 8, 2019
Jul 9, 2021
Apr 20, 2021
Nov 20, 2018
Jun 8, 2022
Jun 4, 2019
Dec 3, 2018
Nov 2, 2018
Dec 17, 2018
Mar 25, 2019
Dec 12, 2018
Jul 9, 2021
Jun 8, 2022
Dec 13, 2022
Apr 15, 2020
Jun 8, 2022
Dec 29, 2020
Dec 13, 2022
Dec 29, 2020
Apr 27, 2020
Apr 30, 2020
Aug 5, 2020
Oct 16, 2020
Jun 8, 2022
May 6, 2021
Feb 8, 2023
Apr 27, 2021
Dec 20, 2022
Nov 6, 2020
Feb 9, 2021
Oct 1, 2021
Jun 18, 2021
Jun 8, 2022
Jun 23, 2022
Jul 3, 2023
Aug 13, 2021
May 31, 2021
Jun 23, 2022
Jul 16, 2021
Jul 12, 2021
Jul 25, 2021
Sep 18, 2021
Jan 18, 2022
Oct 20, 2023
Sep 26, 2021
Mar 17, 2022
Oct 26, 2021
Oct 14, 2021
Nov 30, 2021
Oct 12, 2021
Nov 8, 2021
Jan 19, 2022
Jun 3, 2022
Aug 12, 2024
Apr 6, 2022
Apr 24, 2022
Jun 15, 2022
May 5, 2022
Apr 14, 2022
May 18, 2022
Jun 15, 2022
Dec 15, 2022
Dec 15, 2022
Feb 16, 2023
Oct 24, 2022
Jul 29, 2022
Aug 22, 2022
Sep 6, 2022
Feb 15, 2023
Nov 2, 2022
Dec 28, 2022
Sep 22, 2023
Mar 17, 2023
Nov 30, 2022
Jan 31, 2024
Jun 27, 2023
Mar 16, 2023
Oct 30, 2024
Apr 20, 2023
Mar 17, 2023
Apr 18, 2023
Apr 28, 2023
Apr 20, 2023
Aug 10, 2023
Sep 14, 2023
Aug 12, 2024
Jul 2, 2024
Feb 18, 2024
Mar 4, 2024
Jul 4, 2024
May 21, 2024
Jun 26, 2024
Nov 21, 2024
Sep 10, 2024
Nov 20, 2024
Jun 8, 2022
Apr 22, 2021

TiDB Design Documents

Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the TiDB community.

The process described in this page is intended to provide a consistent and controlled path for new features to enter the TiDB projects, so that all stakeholders can be confident about the direction the projects is evolving in.

Who should initiate the design document?

Everyone is encouraged to initiate a design document, but before doing it, please make sure you have an intention of getting the work done to implement it.

Before creating a design document

A hastily-proposed design document can hurt its chances of acceptance. Low-quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the design document can make the process smoother.

Although there is no single way to prepare for submitting a design document, it is generally a good idea to pursue feedback from other project developers beforehand, to ascertain that the design document may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.

The most common preparations for writing and submitting a design document for now is creating an issue for discussion, which is going to be converted into a tracking issue of the design implementation.

What is the process?

  1. Create a pull request with a design document based on the template under this directory as YYYY-MM-DD-my-feature.md.
  2. Discussion takes place, and the text is revised in response.
  3. The design document is accepted or rejected when at least two committers reach consensus and no objection from the committer.
  4. If accepted, create a tracking issue for the design document or convert one from a previous discuss issue. The tracking issue basically tracks subtasks and progress. And refer the tracking issue in the design document replacing placeholder in the template.
  5. Merge the pull request of design.

Please update the tracking issue according to the progress of succeeding implementation pull requests.

An example that almost fits into this model is the proposal "Support global index for partition table", without following the latest template.