Jump to: navigation, search

Difference between revisions of "StoryBoard/Notifications"

(reordered things)
Line 19: Line 19:
 
     If not all things that can be updated in a subscribed resource will be relevant, then...
 
     If not all things that can be updated in a subscribed resource will be relevant, then...
  
b) SB needs to track whether or not an update to a subscribed resource is relevant to the user,
+
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.
+
   OR:        subscriptions need changing so that users can only subscribe to relevant things.
  
 
   i) What things can update?
 
   i) What things can update?
  
 +
    currently:
 
     Stories are related to projects via tasks.  
 
     Stories are related to projects via tasks.  
 
     Project groups collect projects, which then relate to stories via tasks.
 
     Project groups collect projects, which then relate to stories via tasks.
Line 34: Line 35:
 
         - Tags
 
         - Tags
 
         - Comments
 
         - Comments
         * Tasks (within the story)
+
         * Tasks (listed on story detail page)
 
             - Creation
 
             - Creation
 
             - Removal
 
             - Removal
Line 52: Line 53:
 
                     - Description
 
                     - Description
  
   ii) How will a user tell SB which updates to look out for?
+
   ii) How does storyboard keep track of these?
 
 
  iii) How will SB keep track of these?
 
 
 
c) SB must inform user of these updates
 
 
 
  i) The user needs to know *what* has updated
 
 
 
        *Appropriate metadata should be relayed-- what is it, and should this be configurable?
 
        (example of appropriate metadata: 'what groups does the updated resource fall into?', 'when was it updated?', '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?)
 
 
 
Implementation:
 
 
 
TBA, look into timeline events. Roughly divides into three parts:
 
 
 
a) SB tracking info
 
 
 
b) Info displayed to user
 
  
    i) currently:
+
  iii) How will a user tell SB which updates to look out for?
  
         *recent events on dashboard
+
         currently:
 
 
        *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?)
 
       
 
c) Info configurable (both what's tracked and what's displayed)
 
 
 
    i) currently:
 
  
 
         * User can click stars to subscribe to stories, projects and project groups.  
 
         * User can click stars to subscribe to stories, projects and project groups.  
Line 132: Line 103:
 
                 Task deleted
 
                 Task deleted
 
                 User comment
 
                 User comment
 +
 
 +
  iv) How will SB keep track of these?
 +
 +
c) SB must inform user of these updates
 +
 +
  i) The user needs to know *what* has updated
 +
 +
        *Appropriate metadata should be relayed-- what is it, and should this be configurable?
 +
        (example of appropriate metadata: 'what groups does the updated resource fall into?', 'when was it updated?', '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?)
  
 
</pre>
 
</pre>

Revision as of 12:36, 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?

        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
  
  iv) How will SB keep track of these?

c) SB must inform user of these updates

  i) The user needs to know *what* has updated

        *Appropriate metadata should be relayed-- what is it, and should this be configurable?
        (example of appropriate metadata: 'what groups does the updated resource fall into?', 'when was it updated?', '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. ???