-
Notifications
You must be signed in to change notification settings - Fork 206
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
51 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |