diff --git a/src/contribute-to-tidb/contribute-code.md b/src/contribute-to-tidb/contribute-code.md
index e1b42156..63e37319 100644
--- a/src/contribute-to-tidb/contribute-code.md
+++ b/src/contribute-to-tidb/contribute-code.md
@@ -23,6 +23,12 @@ 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 repos in TiDB community requires all the pull requests referring to corresponding issues. When opening a pull request, you MUST fill the pull request body with relevant issue numbers. In the pull request body, there MUST be one line matching the pattern `Issue Number: ref #{issue-number}` or `Issue Number: close[sd]?|resolve[sd]?|fix(e[sd])? #{issue-number}`. `ref` means associated with an issue but does not close it. There should be no other content in the same line and the check is case-insensitive. Multiple issues should be separated by a comma, like `Issue Number: close #12341, close #12342`. For PRs 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.
+
+The pull request cannot be merged if the rule is violated.
+
 ## 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.