[incubator-devlake-website] branch main updated: docs: refactor metrics page

[warren]

This is an automated email from the ASF dual-hosted git repository.

warren pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git


The following commit(s) were added to refs/heads/main by this push:
     new 90248014 docs: refactor metrics page
90248014 is described below

commit 90248014de92afdf1e986c1ae8db5ba393413607
Author: Startrekzky <kaiyun.zh...@merico.dev>
AuthorDate: Wed Aug 17 18:00:41 2022 +0800

    docs: refactor metrics page
---
 docs/Metrics/AddedLinesOfCode.md                   | 67 ++++++++++++++++++++++
 docs/Metrics/BugAge.md                             | 67 ++++++++++++++++++++++
 docs/Metrics/BugCountPer1kLinesOfCode.md           | 67 ++++++++++++++++++++++
 docs/Metrics/BuildCount.md                         | 67 ++++++++++++++++++++++
 docs/Metrics/BuildDuration.md                      | 67 ++++++++++++++++++++++
 docs/Metrics/BuildSuccessRate.md                   | 67 ++++++++++++++++++++++
 docs/Metrics/CFR.md                                | 67 ++++++++++++++++++++++
 docs/Metrics/ChangeLeadTime.md                     | 67 ++++++++++++++++++++++
 docs/Metrics/CodingTime.md                         | 67 ++++++++++++++++++++++
 docs/Metrics/CommitAuthorCount.md                  | 67 ++++++++++++++++++++++
 docs/Metrics/CommitCount.md                        | 67 ++++++++++++++++++++++
 docs/Metrics/DeletedLinesOfCode.md                 | 67 ++++++++++++++++++++++
 docs/Metrics/DeployFrequency.md                    | 67 ++++++++++++++++++++++
 docs/Metrics/DeployTime.md                         | 67 ++++++++++++++++++++++
 docs/Metrics/IncidentAge.md                        | 67 ++++++++++++++++++++++
 docs/Metrics/IncidentCountPer1kLinesOfCode.md      | 67 ++++++++++++++++++++++
 docs/Metrics/MTTR.md                               | 67 ++++++++++++++++++++++
 docs/Metrics/MergeRate.md                          | 67 ++++++++++++++++++++++
 .../{EngineeringMetrics.md => Metrics/Overview.md} |  6 +-
 docs/Metrics/PRSize.md                             | 67 ++++++++++++++++++++++
 docs/Metrics/PickupTime.md                         | 67 ++++++++++++++++++++++
 docs/Metrics/RequirementCount.md                   | 67 ++++++++++++++++++++++
 docs/Metrics/RequirementDeliveryRate.md            | 67 ++++++++++++++++++++++
 docs/Metrics/RequirementGranularity.md             | 67 ++++++++++++++++++++++
 docs/Metrics/RequirementLeadTime.md                | 67 ++++++++++++++++++++++
 docs/Metrics/ReviewDepth.md                        | 67 ++++++++++++++++++++++
 docs/Metrics/ReviewRounds.md                       | 67 ++++++++++++++++++++++
 docs/Metrics/ReviewTime.md                         | 67 ++++++++++++++++++++++
 docs/Metrics/TimeToMerge.md                        | 67 ++++++++++++++++++++++
 docs/Metrics/_category_.json                       |  7 +++
 docs/Overview/Introduction.md                      |  2 +-
 docusaurus.config.js                               |  2 +-
 .../2022-05-18-apache-welcomes-devLake/index.md    |  2 +-
 33 files changed, 1888 insertions(+), 7 deletions(-)

diff --git a/docs/Metrics/AddedLinesOfCode.md b/docs/Metrics/AddedLinesOfCode.md
new file mode 100644
index 00000000..0644e445
--- /dev/null
+++ b/docs/Metrics/AddedLinesOfCode.md
@@ -0,0 +1,67 @@
+---
+title: "Added Lines of Code    "
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/BugAge.md b/docs/Metrics/BugAge.md
new file mode 100644
index 00000000..4ea18675
--- /dev/null
+++ b/docs/Metrics/BugAge.md
@@ -0,0 +1,67 @@
+---
+title: "Bug Age"
+description: >
+  Bug Age
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/BugCountPer1kLinesOfCode.md 
b/docs/Metrics/BugCountPer1kLinesOfCode.md
new file mode 100644
index 00000000..d9ccc372
--- /dev/null
+++ b/docs/Metrics/BugCountPer1kLinesOfCode.md
@@ -0,0 +1,67 @@
+---
+title: "Bug Count per 1k Lines of Code"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/BuildCount.md b/docs/Metrics/BuildCount.md
new file mode 100644
index 00000000..9d9d3d62
--- /dev/null
+++ b/docs/Metrics/BuildCount.md
@@ -0,0 +1,67 @@
+---
+title: "Build Count"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/BuildDuration.md b/docs/Metrics/BuildDuration.md
new file mode 100644
index 00000000..e43d8861
--- /dev/null
+++ b/docs/Metrics/BuildDuration.md
@@ -0,0 +1,67 @@
+---
+title: "Build Duration"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/BuildSuccessRate.md b/docs/Metrics/BuildSuccessRate.md
new file mode 100644
index 00000000..dbf08eb9
--- /dev/null
+++ b/docs/Metrics/BuildSuccessRate.md
@@ -0,0 +1,67 @@
+---
+title: "Build Success Rate"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/CFR.md b/docs/Metrics/CFR.md
new file mode 100644
index 00000000..3a800235
--- /dev/null
+++ b/docs/Metrics/CFR.md
@@ -0,0 +1,67 @@
+---
+title: "Change Failure Rate"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/ChangeLeadTime.md b/docs/Metrics/ChangeLeadTime.md
new file mode 100644
index 00000000..7cdcc740
--- /dev/null
+++ b/docs/Metrics/ChangeLeadTime.md
@@ -0,0 +1,67 @@
+---
+title: "Change Lead Time"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/CodingTime.md b/docs/Metrics/CodingTime.md
new file mode 100644
index 00000000..0a5d71d7
--- /dev/null
+++ b/docs/Metrics/CodingTime.md
@@ -0,0 +1,67 @@
+---
+title: "Coding Time"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/CommitAuthorCount.md 
b/docs/Metrics/CommitAuthorCount.md
new file mode 100644
index 00000000..ae84376b
--- /dev/null
+++ b/docs/Metrics/CommitAuthorCount.md
@@ -0,0 +1,67 @@
+---
+title: "Commit Author Count"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/CommitCount.md b/docs/Metrics/CommitCount.md
new file mode 100644
index 00000000..e1b1509b
--- /dev/null
+++ b/docs/Metrics/CommitCount.md
@@ -0,0 +1,67 @@
+---
+title: "Commit Count"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/DeletedLinesOfCode.md 
b/docs/Metrics/DeletedLinesOfCode.md
new file mode 100644
index 00000000..a4f0f611
--- /dev/null
+++ b/docs/Metrics/DeletedLinesOfCode.md
@@ -0,0 +1,67 @@
+---
+title: "Deleted Lines of Code  "
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/DeployFrequency.md b/docs/Metrics/DeployFrequency.md
new file mode 100644
index 00000000..5f297994
--- /dev/null
+++ b/docs/Metrics/DeployFrequency.md
@@ -0,0 +1,67 @@
+---
+title: "Deploy Frequency"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/DeployTime.md b/docs/Metrics/DeployTime.md
new file mode 100644
index 00000000..0b824b62
--- /dev/null
+++ b/docs/Metrics/DeployTime.md
@@ -0,0 +1,67 @@
+---
+title: "PR Deploy Time"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/IncidentAge.md b/docs/Metrics/IncidentAge.md
new file mode 100644
index 00000000..77c8d170
--- /dev/null
+++ b/docs/Metrics/IncidentAge.md
@@ -0,0 +1,67 @@
+---
+title: "Incident Age"
+description: >
+  Incident Age
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/IncidentCountPer1kLinesOfCode.md 
b/docs/Metrics/IncidentCountPer1kLinesOfCode.md
new file mode 100644
index 00000000..8d1a4830
--- /dev/null
+++ b/docs/Metrics/IncidentCountPer1kLinesOfCode.md
@@ -0,0 +1,67 @@
+---
+title: "Incident Count per 1k Lines of Code"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/MTTR.md b/docs/Metrics/MTTR.md
new file mode 100644
index 00000000..5d829dac
--- /dev/null
+++ b/docs/Metrics/MTTR.md
@@ -0,0 +1,67 @@
+---
+title: "Mean Time to Restore Service"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/MergeRate.md b/docs/Metrics/MergeRate.md
new file mode 100644
index 00000000..67183e43
--- /dev/null
+++ b/docs/Metrics/MergeRate.md
@@ -0,0 +1,67 @@
+---
+title: "Pull Request Pass Rate"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/EngineeringMetrics.md b/docs/Metrics/Overview.md
similarity index 99%
rename from docs/EngineeringMetrics.md
rename to docs/Metrics/Overview.md
index 77760efe..88c8fb4d 100644
--- a/docs/EngineeringMetrics.md
+++ b/docs/Metrics/Overview.md
@@ -1,8 +1,6 @@
 ---
-sidebar_position: 8
-title: "Engineering Metrics"
-linkTitle: "Engineering Metrics"
-tags: []
+sidebar_position: 1
+title: "Overview"
 description: >
   The definition, values and data required for the 20+ engineering metrics 
supported by DevLake.
 ---
diff --git a/docs/Metrics/PRSize.md b/docs/Metrics/PRSize.md
new file mode 100644
index 00000000..6677bafb
--- /dev/null
+++ b/docs/Metrics/PRSize.md
@@ -0,0 +1,67 @@
+---
+title: "PR/MR Size"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/PickupTime.md b/docs/Metrics/PickupTime.md
new file mode 100644
index 00000000..fa767dd3
--- /dev/null
+++ b/docs/Metrics/PickupTime.md
@@ -0,0 +1,67 @@
+---
+title: "PR Pickup Time"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/RequirementCount.md b/docs/Metrics/RequirementCount.md
new file mode 100644
index 00000000..eb7fd6e9
--- /dev/null
+++ b/docs/Metrics/RequirementCount.md
@@ -0,0 +1,67 @@
+---
+title: "Requirement Count"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/RequirementDeliveryRate.md 
b/docs/Metrics/RequirementDeliveryRate.md
new file mode 100644
index 00000000..e5e1467e
--- /dev/null
+++ b/docs/Metrics/RequirementDeliveryRate.md
@@ -0,0 +1,67 @@
+---
+title: "Requirement Delivery Rate"
+description: >
+  Requirement Delivery Rate
+sidebar_position: 3
+---
+
+## What is this metric? 
+The number of issues in type `requirement/feature`, reflecting the throughput 
of features delivered.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/RequirementGranularity.md 
b/docs/Metrics/RequirementGranularity.md
new file mode 100644
index 00000000..3a7e46d4
--- /dev/null
+++ b/docs/Metrics/RequirementGranularity.md
@@ -0,0 +1,67 @@
+---
+title: "Requirement Granularity"
+description: >
+  Requirement Granularity
+sidebar_position: 4
+---
+
+## What is this metric? 
+The number of issues in type `requirement/feature`, reflecting the throughput 
of features delivered.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/RequirementLeadTime.md 
b/docs/Metrics/RequirementLeadTime.md
new file mode 100644
index 00000000..37d67982
--- /dev/null
+++ b/docs/Metrics/RequirementLeadTime.md
@@ -0,0 +1,67 @@
+---
+title: "Requirement Lead Time"
+description: >
+  Requirement Lead Time
+sidebar_position: 4
+---
+
+## What is this metric? 
+The number of issues in type `requirement/feature`, reflecting the throughput 
of features delivered.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/ReviewDepth.md b/docs/Metrics/ReviewDepth.md
new file mode 100644
index 00000000..1871a5ab
--- /dev/null
+++ b/docs/Metrics/ReviewDepth.md
@@ -0,0 +1,67 @@
+---
+title: "Review Depth"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/ReviewRounds.md b/docs/Metrics/ReviewRounds.md
new file mode 100644
index 00000000..7c3e46bb
--- /dev/null
+++ b/docs/Metrics/ReviewRounds.md
@@ -0,0 +1,67 @@
+---
+title: "Pull Request Review Rounds"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/ReviewTime.md b/docs/Metrics/ReviewTime.md
new file mode 100644
index 00000000..c3b0cb06
--- /dev/null
+++ b/docs/Metrics/ReviewTime.md
@@ -0,0 +1,67 @@
+---
+title: "PR Review Time"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/TimeToMerge.md b/docs/Metrics/TimeToMerge.md
new file mode 100644
index 00000000..b8150e0a
--- /dev/null
+++ b/docs/Metrics/TimeToMerge.md
@@ -0,0 +1,67 @@
+---
+title: "Time To Merge"
+description: >
+  Requirement Count
+sidebar_position: 2
+---
+
+## What is this metric? 
+The number of issues created with the type `REQUIREMENT`.
+
+## Why is it important?
+1. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration to improve the organization and planning of R&D resources.
+2. Evaluate whether the delivery capacity matches the business phase and 
demand scale. Identify key bottlenecks and reasonably allocate resources.
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+
+
+## How is it calculated?
+This metric is calculated by counting the number of completed issues in type 
"REQUIREMENT".
+
+<b>Data Sources Required</b>
+
+This metric relies on issues collected from Jira, GitHub, or TAPD.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the "issue type mapping" in "blueprint-transformation 
rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+
+<b>SQL Queries</b>
+
+If you want to see a single count, run the following SQL in Grafana
+```
+  select 
+    count(*) as value
+  from issues i
+    join board_issues bi on i.id = bi.issue_id
+  where 
+    i.type in ($type)
+    and i.type = 'REQUIREMENT'
+    -- this is the default variable in Grafana
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+```
+
+If you want to see the monthly trend, run the following SQL
+```
+  SELECT
+    DATE_ADD(date(i.created_date), INTERVAL 
-DAYOFMONTH(date(i.created_date))+1 DAY) as time,
+    count(distinct case when status != 'DONE' then i.id else null end) as 
"Number of Open Issues",
+    count(distinct case when status = 'DONE' then i.id else null end) as 
"Number of Delivered Issues"
+  FROM issues i
+    join board_issues bi on i.id = bi.issue_id
+    join boards b on bi.board_id = b.id
+  WHERE 
+    i.type = 'REQUIREMENT'
+    and $__timeFilter(i.created_date)
+    and bi.board_id in ($board_id)
+  GROUP by 1
+```
+
+## How to improve?
+1. Analyze the number of requirements and delivery rate of different time 
cycles to find the stability and trend of the development process.
+2. Analyze and compare the number of requirements delivered and delivery rate 
of each project/team, and compare the scale of requirements of different 
projects.
+3. Based on historical data, establish a baseline of the delivery capacity of 
a single iteration (optimistic, probable and pessimistic values) to provide a 
reference for iteration estimation.
+4. Drill down to analyze the number and percentage of requirements in 
different phases of SDLC. Analyze rationality and identify the requirements 
stuck in the backlog. 
diff --git a/docs/Metrics/_category_.json b/docs/Metrics/_category_.json
new file mode 100644
index 00000000..c0404058
--- /dev/null
+++ b/docs/Metrics/_category_.json
@@ -0,0 +1,7 @@
+{
+  "label": "Metrics",
+  "position": 4,
+  "link":{
+    "type": "generated-index"
+  }
+}
diff --git a/docs/Overview/Introduction.md b/docs/Overview/Introduction.md
index 6cf72409..7a4e868c 100755
--- a/docs/Overview/Introduction.md
+++ b/docs/Overview/Introduction.md
@@ -11,7 +11,7 @@ Apache DevLake is designed for developer teams looking to 
make better sense of t
 
 ## What can be accomplished with DevLake?
 1. Collect DevOps data across the entire Software Development Life Cycle 
(SDLC) and connect the siloed data with a standard [data 
model](../DataModels/DevLakeDomainLayerSchema.md).
-2. Visualize out-of-the-box engineering [metrics](../EngineeringMetrics.md) in 
a series of use-case driven dashboards
+2. Visualize out-of-the-box [engineering metrics](../Metrics/Overview.md) in a 
series of use-case driven dashboards
 3. Easily extend DevLake to support your data sources, metrics, and dashboards 
with a flexible [framework](Architecture.md) for data collection and ETL 
(Extract, Transform, Load).
 
 ## How do I use DevLake?
diff --git a/docusaurus.config.js b/docusaurus.config.js
index da47b752..10f67c54 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -193,7 +193,7 @@ const versions = require('./versions.json');
               },
               {
                 label: 'Engineering Metrics',
-                to: 'docs/EngineeringMetrics',
+                to: 'docs/Metrics/Overview',
               },
               {
                 label: 'Dashboards (Live Demo)',
diff --git 
a/i18n/zh/docusaurus-plugin-content-blog/2022-05-18-apache-welcomes-devLake/index.md
 
b/i18n/zh/docusaurus-plugin-content-blog/2022-05-18-apache-welcomes-devLake/index.md
index 9196f283..2ee43a6c 100644
--- 
a/i18n/zh/docusaurus-plugin-content-blog/2022-05-18-apache-welcomes-devLake/index.md
+++ 
b/i18n/zh/docusaurus-plugin-content-blog/2022-05-18-apache-welcomes-devLake/index.md
@@ -35,7 +35,7 @@ tags: [devlake, apache]
 
 研发过程数据的标准化程度低，用户难以直接使用这些数据进一步分析；而效能指标定义与计算方法模糊，又给研发数据的应用带来了额外的成本。
 
-Apache DevLake 
提供了便捷的数据转化能力，将收集来的数据清洗转换为[标准数据模型](https://devlake.apache.org/docs/DataModels/DevLakeDomainLayerSchema)，并基于标准模型生成一系列[研发效能指标](https://devlake.apache.org/docs/EngineeringMetrics)，对用户来说简单易懂、开箱即用。一方面节省了治理数据和定义指标的成本，另一方面使效能指标更加透明，便于研发数据的应用落地。
+Apache DevLake 
提供了便捷的数据转化能力，将收集来的数据清洗转换为[标准数据模型](https://devlake.apache.org/docs/DataModels/DevLakeDomainLayerSchema)，并基于标准模型生成一系列[研发效能指标](https://devlake.apache.org/docs/Metrics/Overview)，对用户来说简单易懂、开箱即用。一方面节省了治理数据和定义指标的成本，另一方面使效能指标更加透明，便于研发数据的应用落地。
 
 目前 Apache DevLake 已支持 20+常见研发效能指标，可应用于交付效率、质量、成本、能力等不同认知域。