diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
index 944ee6868..0231d376a 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -2,7 +2,7 @@
 name: Bug report
 about: Create a report to help us improve
 title: ''
-labels: 'type: bug, triage required'
+labels: 'triage required, type: bug'
 assignees: dovahcrow
 
 ---
diff --git a/.github/ISSUE_TEMPLATE/task-template.md b/.github/ISSUE_TEMPLATE/task-template.md
new file mode 100644
index 000000000..e70d3f883
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/task-template.md
@@ -0,0 +1,50 @@
+---
+name: Task Template
+about: Task template (for team use)
+title: 'Feature Proposal: xxxyyyzzz'
+labels: 'type: enhancement'
+assignees: ''
+
+---
+
+<!--Adapted from https://github.com/rust-lang/rfcs/blob/master/0000-template.md-->
+
+<!--
+Guide: 
+1. Fill in the summary section first. Then put actions in the UI-level Explanation section when designing the feature. 
+2. After discussions/meetings/thinking/investigations, fill in the UI-level Explanation, Rational and Alternatives, Prior Art, Future Possibilities gradually. 
+3. If everyone agrees on the UI-level Explanation, filling in the Implementation-level Explanation.
+4. Finish implementation and amend this issue if necessary.
+-->
+
+<!--Action means a sentence describing what to do and what is the outcome. E.g. "Read dask documentation" is a bad action, but "Read dask documentation to figure out the optimal block size" is good.-->
+
+## Summary
+<!--Use one or two lines to summary the task.-->
+
+## UI-level Explanation
+<!--Explain the designing as if it was already implemented and you were teaching it to the user.-->
+<!--E.g. We use ... as the config syntax for all the plot functions in EDA. xxx represents yyy...-->
+<!--Put actions below-->
+
+## Implementation-level Explanation
+<!--This section should return to the examples given in the previous section, and explain more fully how the detailed implementation makes those examples work.-->
+<!--E.g. In order to support all the syntax defined in the previous section, we should do syntax normalization first.-->
+<!--Put actions below-->
+
+## Rational and Alternatives
+<!--
+Why is this design the best in the space of possible designs?
+What other designs have been considered and what is the rationale for not choosing them?
+What is the impact of not doing this?
+-->
+
+## Prior Art
+<!--Discuss prior art, e.g. how other libraries solve the same problem and why we are using it or not using it.-->
+
+## Future Possibilities
+
+## Additional Tasks
+
+- [ ] The documentation is changed accordingly.
+- [ ] Tests are added accordingly.
\ No newline at end of file