sort order flow

This commit is contained in:
Radek Stepan 2014-10-15 19:34:51 -07:00
parent bc20dbda2c
commit 91dff8e828
1 changed files with 11 additions and 1 deletions

12
TODO.md
View File

@ -4,6 +4,16 @@
- [ ] sort milestones on index and project page based on priority (most delayed first); Trend - actual = different in days and those overdue come first
1. in a projects collection observe the list prop and resort index; already sorted flag passed in as yes)
1. The index is not already sorted when sort order changes
1. index is a list of 3 elements; list index, milestone index and priority number
1. go through projects and its milestones in two loops to extract and sort using function
1. tables loop index getting the obj from projects collection and render
1. sort order link toggles available sort by keys and changes the current key
1. use while loop and pop when resetting the index
1. third number in tuples be the priority number so we can insert into already sorted
1. leave the code open so we can remove a project or milestone later on
###Notifications
- [ ] create a 500/400/loading system messages
@ -99,4 +109,4 @@
- [ ] show number of tasks, points, days left just like in Assembly on chart page
- [ ] receive reminders when a due date is nearing and our project is behind schedule; receive a daily digest saying how the progress went in that day/week; these are all ways we can help people answer the question: is my project on track?
- [ ] if we save user's tokens we could check data on their behalf, then messaging would work; API could be provided so that others could plug into the data
- [ ] derive insights; one part is to see if we are on track, the other is to get better at estimating. If we know when an issue is worked on and when closed, with its accompanying size, we can say which issues went well, and which fared poorly. Then we can visualize a weekly/monthly/per-milestone list of loosers and winners. Perhaps the user can glean a pattern from that.
- [ ] derive insights; one part is to see if we are on track, the other is to get better at estimating. If we know when an issue is worked on and when closed, with its accompanying size, we can say which issues went well, and which fared poorly. Then we can visualize a weekly/monthly/per-milestone list of loosers and winners. Perhaps the user can glean a pattern from that.