From 9559a20bf228a1490975c633012f18a48b51a27e Mon Sep 17 00:00:00 2001 From: zhangyangyu Date: Wed, 15 Dec 2021 21:59:14 +0800 Subject: [PATCH] add pr issue association rule --- src/contribute-to-tidb/contribute-code.md | 26 +++++++++++++++++++++++ src/contribute-to-tidb/make-a-proposal.md | 13 +++++++----- 2 files changed, 34 insertions(+), 5 deletions(-) diff --git a/src/contribute-to-tidb/contribute-code.md b/src/contribute-to-tidb/contribute-code.md index e1b42156..3600c260 100644 --- a/src/contribute-to-tidb/contribute-code.md +++ b/src/contribute-to-tidb/contribute-code.md @@ -23,6 +23,32 @@ After a consensus is reached in issues, it's time to start the code contributing Clear and kind communication is key to this process. +## Referring to an issue + +Code repositories in TiDB community require **ALL** the pull requests referring to its corresponding issues. In the pull request body, there **MUST** be one line starting with `Issue Number: ` and linking the relevant issues via the [keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), for example: + +If the pull request resolves the relevant issues, and you want GitHub to close these issues automatically after it merged into the default branch, you can use the syntax (`KEYWORD #ISSUE-NUMBER`) like this: + +``` +Issue Number: close #123 +``` + +If the pull request links an issue but does not close it, you can use the keyword `ref` like this: + +``` +Issue Number: ref #456 +``` + +Multiple issues should use full syntax for each issue and separate by a comma, like: + +``` +Issue Number: close #123, ref #456 +``` + +For pull requests trying to close issues in a different repository, contributors need to first create an issue in the same repository and use this issue to track. + +If the pull request body does not provide the required content, the bot will add the `do-not-merge/needs-linked-issue` label to the pull request to prevent it from being merged. + ## Writing tests One important thing when you make code contributions to TiDB is tests. Tests should be always considered as a part of your change. Any code changes that cause semantic changes or new function additions to TiDB should have corresponding test cases. And of course you can not break any existing test cases if they are still valid. It's recommended to [run tests](../get-started/write-and-run-unit-tests.md) on your local environment first to find obvious problems and fix them before opening the pull request. diff --git a/src/contribute-to-tidb/make-a-proposal.md b/src/contribute-to-tidb/make-a-proposal.md index ea516d3d..fe86520b 100644 --- a/src/contribute-to-tidb/make-a-proposal.md +++ b/src/contribute-to-tidb/make-a-proposal.md @@ -24,11 +24,14 @@ The most common preparations for writing and submitting a draft of design docume ## What is the process? -1. Create a pull request with a design document based on the [template](https://github.com/pingcap/tidb/blob/7f4f5c02364b6578da561ec14f409a39ddf954a5/docs/design/TEMPLATE.md) 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](https://github.com/pingcap/tidb/issues/new?assignees=&labels=type%2Fenhancement&template=development-task.md) 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. +1. Create an issue describing the problem, goal and solution. +2. Get responses from other contributors to see if the proposal is generally acceptable. +3. Create a pull request with a design document based on the [template](https://github.com/pingcap/tidb/blob/7f4f5c02364b6578da561ec14f409a39ddf954a5/docs/design/TEMPLATE.md) as `YYYY-MM-DD-my-feature.md`. +4. Discussion takes place, and the text is revised in response. +5. The design document is accepted or rejected when at least two committers reach consensus and no objection from the committer. +6. If accepted, create a [tracking issue](https://github.com/pingcap/tidb/issues/new?assignees=&labels=type%2Fenhancement&template=development-task.md) 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. +7. Merge the pull request of design. +8. Start the implementation. Please refer to the tracking issue from subtasks to track the progress.