Skip to content

Commit ecc0d6c

Browse files
committed
chore: add task template
1 parent fd9dcf0 commit ecc0d6c

File tree

2 files changed

+51
-1
lines changed

2 files changed

+51
-1
lines changed

.github/ISSUE_TEMPLATE/bug_report.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
name: Bug report
33
about: Create a report to help us improve
44
title: ''
5-
labels: 'type: bug, triage required'
5+
labels: 'triage required, type: bug'
66
assignees: dovahcrow
77

88
---
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
name: Task Template
3+
about: Task template (for team use)
4+
title: 'Feature Proposal: xxxyyyzzz'
5+
labels: 'type: enhancement'
6+
assignees: ''
7+
8+
---
9+
10+
<!--Adapted from https://github.com/rust-lang/rfcs/blob/master/0000-template.md-->
11+
12+
<!--
13+
Guide:
14+
1. Fill in the summary section first. Then put actions in the UI-level Explanation section when designing the feature.
15+
2. After discussions/meetings/thinking/investigations, fill in the UI-level Explanation, Rational and Alternatives, Prior Art, Future Possibilities gradually.
16+
3. If everyone agrees on the UI-level Explanation, filling in the Implementation-level Explanation.
17+
4. Finish implementation and amend this issue if necessary.
18+
-->
19+
20+
<!--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.-->
21+
22+
## Summary
23+
<!--Use one or two lines to summary the task.-->
24+
25+
## UI-level Explanation
26+
<!--Explain the designing as if it was already implemented and you were teaching it to the user.-->
27+
<!--E.g. We use ... as the config syntax for all the plot functions in EDA. xxx represents yyy...-->
28+
<!--Put actions below-->
29+
30+
## Implementation-level Explanation
31+
<!--This section should return to the examples given in the previous section, and explain more fully how the detailed implementation makes those examples work.-->
32+
<!--E.g. In order to support all the syntax defined in the previous section, we should do syntax normalization first.-->
33+
<!--Put actions below-->
34+
35+
## Rational and Alternatives
36+
<!--
37+
Why is this design the best in the space of possible designs?
38+
What other designs have been considered and what is the rationale for not choosing them?
39+
What is the impact of not doing this?
40+
-->
41+
42+
## Prior Art
43+
<!--Discuss prior art, e.g. how other libraries solve the same problem and why we are using it or not using it.-->
44+
45+
## Future Possibilities
46+
47+
## Additional Tasks
48+
49+
- [ ] The documentation is changed accordingly.
50+
- [ ] Tests are added accordingly.

0 commit comments

Comments
 (0)