Difference between revisions of "StoryBoard/Notifications"
(reordered things) |
|||
Line 56: | Line 56: | ||
iii) How will a user tell SB which updates to look out for? | iii) How will a user tell SB which updates to look out for? | ||
+ | |||
+ | Should be: easy to find, easy to change, precise. | ||
currently: | currently: | ||
Line 103: | Line 105: | ||
Task deleted | Task deleted | ||
User comment | User comment | ||
+ | |||
+ | I think the current implementation meets criteria of being easy to find and easy to change, but isn't precise | ||
+ | enough yet. User should be able to subscribe to all projects in a group except one, and so on. Maybe we | ||
+ | need a corresponding 'unsubscriptions list' that overrides the subscriptions? Which leads onto... | ||
iv) How will SB keep track of these? | iv) How will SB keep track of these? | ||
+ | |||
+ | Currently: [To be filled in] | ||
c) SB must inform user of these updates | c) SB must inform user of these updates | ||
Line 110: | Line 118: | ||
i) The user needs to know *what* has updated | i) The user needs to know *what* has updated | ||
− | + | Suggested data to relay (should this be configurable?): | |
− | + | ||
+ | - 'what was updated?' | ||
+ | - 'what subscribed groups does the updated resource fall into?' | ||
+ | - 'when was it updated?' | ||
+ | - 'who updated it?' | ||
+ | - 'does this update require my input?' | ||
ii) The user should be notified in the most suitable way. What is this, and should *this* be configurable? (eg: what channels? how frequently should a user be notified?) | ii) The user should be notified in the most suitable way. What is this, and should *this* be configurable? (eg: what channels? how frequently should a user be notified?) |
Revision as of 13:06, 1 December 2015
meeting irc logs here: http://eavesdrop.openstack.org/meetings/storyboard/2015/storyboard.2015-11-18-15.00.log.html
followup in #storyboard here: http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2015-11-18.log.html#t2015-11-18T15:46:32
To be worked into a more readable spec for notifications, that will form the backbone of a roadmap for the next few months of StoryBoard development.
Spec ---- A user needs to know: 1. When something (that affects that user) updates (in a way that affects that user) Requirements: a) Things that affect users must be tracked. Selectable subscriptions exist. If not all things that can be updated in a subscribed resource will be relevant, then... b) EITHER: SB needs to track whether or not an update to a subscribed resource is relevant to the user, OR: subscriptions need changing so that users can only subscribe to relevant things. i) What things can update? currently: Stories are related to projects via tasks. Project groups collect projects, which then relate to stories via tasks. * Stories: - Creation - Removal - Title - Description - Tags - Comments * Tasks (listed on story detail page) - Creation - Removal - Title - Assignee - Priority - Status (todo, review, merged, invalid) * Project (to which the task belongs.) - Creation - Removal (currently not possible) - Title - Description * Project Groups (to which the project belongs): - Creation - Removal (currently not possible) - Title - Description ii) How does storyboard keep track of these? iii) How will a user tell SB which updates to look out for? Should be: easy to find, easy to change, precise. currently: * User can click stars to subscribe to stories, projects and project groups. There is no way to subscribe directly to a task; the user must subscribe to the story containing that task. Star locations: Stories: * Story list page (accessed from sidebar) (stars on right) * Story detail page (accessed by clicking on story name in list) (stars on right) * Projects detail page (accessed by clicking on project name in projects list) (stars on left!) * Project group detail page (accessed by clicking on project group name in project groups list) (stars on right) Projects: * Project list page (accessed from sidebar) (stars on right) * Project group detail page (accessed by clicking on project group name in project groups list) (stars on right) Project Groups: * Project group list page (accessed from sidebar) (stars on right) *preferences for timeline events accessed from profile page (linked from 'profile' button on sidebar) *popup timeline filters accessed from story detail pages (linked from wheel next to 'events timeline' heading) These both look like : Checkboxes with 'save' button at the bottom, with the following options: Story created Story details changed Task created Task assignee changed Task status changed Task priority changed Task details changed Task deleted User comment I think the current implementation meets criteria of being easy to find and easy to change, but isn't precise enough yet. User should be able to subscribe to all projects in a group except one, and so on. Maybe we need a corresponding 'unsubscriptions list' that overrides the subscriptions? Which leads onto... iv) How will SB keep track of these? Currently: [To be filled in] c) SB must inform user of these updates i) The user needs to know *what* has updated Suggested data to relay (should this be configurable?): - 'what was updated?' - 'what subscribed groups does the updated resource fall into?' - 'when was it updated?' - 'who updated it?' - 'does this update require my input?' ii) The user should be notified in the most suitable way. What is this, and should *this* be configurable? (eg: what channels? how frequently should a user be notified?) i) currently: *recent events on dashboard *events timeline on story detail pages ii) in progress *email notifications patches (currently awaiting the rework here: https://review.openstack.org/#/c/240345/1 . What point are notifications at once this patch series is merged?)
Timeline:
When do we expect what? We could probably refine this forever, so at what point should we consider changing priority?
1. Make current implementation consistent
2. ???