Jump to: navigation, search

Difference between revisions of "StoryBoard/Notifications"

(the conversation so far)
 
 
(53 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
15:46 < Zara> so priority number 1 has to be email notifications
+
meeting irc logs here: http://eavesdrop.openstack.org/meetings/storyboard/2015/storyboard.2015-11-18-15.00.log.html
−
15:47 < Zara> we've got as far as patches to say '$subscribedresource was updated'
+
 
−
15:47 < Zara> so once those are merged
+
followup in #storyboard here: http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2015-11-18.log.html#t2015-11-18T15:46:32
−
15:47 < betherly> can we narrow that even further. ie subpoinnts
+
 
−
15:47 < betherly> ie what does that involve work wise and what will we include feature wise
+
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.
−
15:48 < Zara> yeah, was about to say, we can stop at that point if something else seems like a better priority, or we can continue to refine them-- where those questions come in
+
 
−
15:48 < betherly> :)
+
 
−
15:49 < Zara> this is the patch where the discussion heads toward that: https://review.openstack.org/#/c/240346/
+
 
−
15:54 < Zara> So, re: refining or moving on-- I'm not sure there's anything that's ready to move on to. My gut feeling is that this affects people more than any bugs in search.
+
<h2>Spec</h2>
−
15:55 < persia> Lack of subscription makes it not worthwhile to put anything in storyboard: you can't have a conversation, and your stories get lost.
+
----
−
15:55 < Zara> or at least it will, once it's merged and people start getting lots of emails-- and for as long as it isn't merged, nobody can use storyboard to track tasks without putting in a *lot* of effort.
+
<pre>
−
15:56 < persia> With subscription, search isn't important for any story you are already following (because you have notifications), and it encourages folk to share story URLs to others so they can subscribe.
+
A user needs to know:
−
15:56 < Zara> we should distinguish between subscriptions themselves and notifications when things happen to subscribed resources
+
 
−
15:56 < Zara> subscriptions are up.
+
1. When something (that affects that user) updates (in a way that affects that user)
−
15:57 < Zara> notifications do come up in recent events
+
 
−
15:57 < Zara> email notifications aren't up yet.
+
Requirements:
−
15:59 < Zara> and I think the notifications that come up in 'recent events' don't apply to every change one can make to the subscribed resource
+
 
−
15:59 < Zara> I'm wondering if we should say that 'notification' is the main thing to focus on, or if we're best just looking at emails specifically
+
a) Things that affect users must be tracked. Selectable subscriptions exist.  
−
16:00 < Zara> I think the goal matters more and we'd be better off looking at notification in general.
+
    If not all things that can be updated in a subscribed resource will be relevant, then...
−
16:02 < Zara> (I think this is currently recent events on the dashboard and email notifications)
+
 
−
16:11 -!- wuhg [uid39398@gateway/web/irccloud.com/x-hzcjrnfbyyeemhcb] has quit [Quit: Connection closed for inactivity]
+
b) EITHER: SB needs to track whether or not an update to a subscribed resource is relevant to the user,
−
16:12 < Zara> so my vague map for notifications would be: 1) email notifications when subscribed resources update-- these should be configurable to avoid spam (configuration options need to be decided). 2) recent events should update in a useful way when subscribed
+
  OR:        subscriptions need changing so that users can only subscribe to relevant things.
−
              resources update (this needs fleshing out-- what time period is 'recent'? (ie: how long should an event display for? presumably we want multiple events to display... under what conditions should they update?))
+
 
−
16:12 < Zara> I suspect the code for these is quite entwined atm.
+
  i) What things can update?
−
16:13 < Zara> lots of brackets because I am a terrible person
+
 
−
16:14 < Zara> I don't know where to start with configuration options for emails, but it seems like the sensible place to start.
+
    currently:
−
16:15 < Zara> I suppose we would need to decide what got configured, make the filters functional, and have a way for a user to choose them.
+
    Stories are related to projects via tasks.
−
16:16 < betherly> sorry for disappearing for a while there
+
    Project groups collect projects, which then relate to stories via tasks.
−
16:16 < Zara> as far as the last point goes, there's already a 'preferences' area in the UX for timeline events, so that seems like the place to put the options.
+
    An asterisk at the end means that a user can currently subscribe to/unsubscribe from this update directly.
−
16:16 < Zara> no worries
+
 
−
16:16 < Zara> I just rambled
+
    * Stories:
−
16:16 < betherly> that all seems good to me tbh
+
        - Creation*
−
16:17 < betherly> do you want to write that up in an etherpad or something?
+
        - Removal
−
16:17 < persia> Let's use the StoryBoard wiki.
+
        - Title
−
16:17 < betherly> ah yes sorry persia you mentioned that earlier my bad
+
        - Description
−
16:18 < betherly> #memoryissues #oldbeforemytime
+
        - Tags Added*
−
16:18 < persia> betherly: No worries: I just find the proliferation of etherpads increasingly hard to follow :)
+
        - Tags Removed*
−
16:18 < persia> They are great for live sessions because it supports multiple simultaneous edits better, but less ideal for longer-lived things.
+
        - Comments*
−
16:18 < Zara> heh, I was just working things out on paper (well, irc) but recording it will stop things from getting lost in the meantime
+
        (TODO: find out if 'title' and 'description' = 'story details changed' in preferences)
−
16:19 < betherly> yep :)
+
        * Tasks (listed on story detail page)
−
16:19 < Zara> I work things out by discussing them with myself at length on irc and distracting everyone, it's great
+
            - Creation*
−
16:20 < betherly> haha :D
+
            - Removal*
−
16:21 < Zara> is this enough to be getting on with, or is it worth rambling some more before we put it up?
+
            - Title
−
16:23 < persia> I think that's enough for notifications.
+
            - Assignee*
−
16:24 < persia> I also want tags to work: the mess a few days ago when a tag was added making the story unreadable was very unfortunate. Even if tags don't work right, making them not dangerous would be good.
+
            - Priority*
−
16:24 < Zara> okay, I think we'll find the first step to getting there (re: notifications) is to work out how timeline events currently work, where they intersect with email notifications atm.
+
            - Status (todo, review, merged, invalid)*
 +
            (TODO: find out if 'title' = 'task details changed' in preferences)
 +
            * 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
 +
 
 +
Worklists and boards are ways of viewing stories and tasks. They can show tasks on their own,
 +
or stories (which contain tasks).
 +
 
 +
    * Worklists
 +
      - Title
 +
      - Permissions
 +
      - Item added (story or task)
 +
      - Item removed (story or task)
 +
      - Items reordered
 +
      - Changes to item (see stories and tasks above)
 +
      - Worklist removed
 +
    * Boards
 +
      - Title
 +
      - Description
 +
      - Permissions
 +
      - Lane added
 +
      - Lane removed
 +
      - Lane title
 +
      - Lanes reordered
 +
      - Card (story or task) added to lane
 +
      - Card (story or task) removed from lane
 +
      - Card (story or task) changed (see stories and tasks above)
 +
 
 +
 
 +
  ii) How does storyboard keep track of these?
 +
 
 +
    Every POST, PUT, or DELETE request triggers a hook in the API, which
 +
    publishes a message to the rabbitmq queue representing the event (eg.
 +
    a PUT request that edits a story creates a `story_details_changed`
 +
    event message).
 +
 
 +
    `storyboard-worker-daemon` watches this queue for messages and passes
 +
    them to handler processes. Currently, the only handler is one which
 +
    creates records in the `subscription_events` table relating to what
 +
    the request did (eg. a PUT request that edited a story creates a
 +
    `story_details_changed` event in `subscription_events`).
 +
 
 +
    The Recent Events list on the dashboard leverages the API to get the
 +
    contents of this table relevant to the logged-in user, and displays
 +
    them.
 +
 
 +
  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 (always on right)
 +
 
 +
          Stories:
 +
 
 +
          * Story list page (accessed from sidebar)
 +
          * Story detail page (accessed by clicking on story name in list)
 +
          * Projects detail page (accessed by clicking on project name in projects list)
 +
          * Project group detail page (accessed by clicking on project group name in project groups list)
 +
 
 +
          Projects:
 +
 
 +
          * Project list page (accessed from sidebar)
 +
          * Project group detail page (accessed by clicking on project group name in project groups list)
 +
 
 +
          Project Groups:
 +
 
 +
          * Project group list page (accessed from sidebar)
 +
     
 +
        *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
 +
                Tags added
 +
                Tags deleted
 +
                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. Issues:
 +
 
 +
        1) Tied to stories. Settings are only for timeline events, not recent events. Timeline
 +
            events currently apply to stories only (and display on story detail page),
 +
            but recent events could be more broad (eg: boards and worklists). Either changes
 +
            to these need to update the timeline events on a story, or we need a way to set user
 +
            preferences for recent events. (related: a user may wish to have different
 +
            preferences for timeline events and recent events)
 +
 
 +
            *What will the preferences be?
 +
            *Where will a user set them?
 +
 
 +
        2) 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...
 +
 
 +
        3) More things need to be tracked. From the list above, it's clear that far more things can update than
 +
            can be automatically tracked by a user. It's likely that a manager of a team using a board will want to
 +
            track the board as it updates, for example.
 +
 
 +
  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
 +
 
 +
        *plugin merged, webclient button to turn them on in user preferences
 +
 
 +
    ii) in progress:
 +
 
 +
        *infra's email configuration needs merging for notifications to work on s.o.o:  
 +
            https://review.openstack.org/#/c/270331/
 +
        We will want to make this more finegrained.
 +
 
 +
    iii)  todo :
 +
        * Let everyone know it's working and await feedback!
 +
 
 +
</pre>
 +
 
 +
----
 +
 
 +
<h2>Roadmap Plan</h2>
 +
 
 +
<pre>
 +
We now have some detail about the current implementation. We need more input from users to work out where this falls
 +
short. re: emails: we'll probably get comments on these as we work on them. So far, people have said they want email notifications, so we'll
 +
need those before we're likely to get a lot of feedback.
 +
 
 +
 
 +
# Overall Roadmap
 +
 
 +
We could probably refine this forever, so at what point should we consider changing priority?
 +
 
 +
1. Fix  bugs in current implementation (including making it consistent).
 +
 
 +
  a) User preferences patches in review -- Done!
 +
        Though we should make more of these to allow users to set more preferences.
 +
 
 +
  b) Decide on approach to timeline events vs recent events
 +
    If we separate them, then:
 +
      * Decide on candidates for recent events (bigger set containing set of timeline events?)
 +
      * Implement
 +
          * backend to store preferences and handle them
 +
          * UX for preferences
 +
 
 +
  c) Support for worklists and boards in:
 +
      * recent events (see above, since these don't form part of a story, unless we change that)
 +
      * timeline events? (eg: 'this story has been added to board x'. does anyone want this?)
 +
      * user preferences (checkboxes to enable and disable notifications)
 +
 
 +
2. Merge email patches so that some basic email notifications work (currently 'off' by default')
 +
 
 +
  a) story https://storyboard.openstack.org/#!/story/2000456
 +
 
 +
  b) Then get feedback and improve these
 +
 
 +
3. Improve UX for Recent Events
 +
 
 +
  a) align all timestamps to right-- Done!
 +
  b) display tag events instead of empty boxes-- Done!
 +
 
 +
(Those two things were done before they were added to this wiki page; have been included so
 +
it's clear what sort of thing the vague 'improve ux' entails here.)
 +
 
 +
4. Give better variety of subscription options.
 +
  a) track more things! (probably falls under 1b)
 +
  b) allow user to unsubscribe from story within a subscribed project, and similar

Latest revision as of 14:48, 16 February 2016

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.
     An asterisk at the end means that a user can currently subscribe to/unsubscribe from this update directly.

     * Stories:
         - Creation*
         - Removal
         - Title
         - Description
         - Tags Added*
         - Tags Removed*
         - Comments*
         (TODO: find out if 'title' and 'description' = 'story details changed' in preferences)
         * Tasks (listed on story detail page)
             - Creation*
             - Removal*
             - Title
             - Assignee*
             - Priority*
             - Status (todo, review, merged, invalid)*
             (TODO: find out if 'title' = 'task details changed' in preferences)
             * 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

Worklists and boards are ways of viewing stories and tasks. They can show tasks on their own,
or stories (which contain tasks).

    * Worklists
       - Title
       - Permissions
       - Item added (story or task)
       - Item removed (story or task)
       - Items reordered
       - Changes to item (see stories and tasks above)
       - Worklist removed
    * Boards
       - Title
       - Description
       - Permissions
       - Lane added
       - Lane removed
       - Lane title
       - Lanes reordered
       - Card (story or task) added to lane
       - Card (story or task) removed from lane
       - Card (story or task) changed (see stories and tasks above)


  ii) How does storyboard keep track of these?

    Every POST, PUT, or DELETE request triggers a hook in the API, which
    publishes a message to the rabbitmq queue representing the event (eg.
    a PUT request that edits a story creates a `story_details_changed`
    event message).

    `storyboard-worker-daemon` watches this queue for messages and passes
    them to handler processes. Currently, the only handler is one which
    creates records in the `subscription_events` table relating to what
    the request did (eg. a PUT request that edited a story creates a
    `story_details_changed` event in `subscription_events`).

    The Recent Events list on the dashboard leverages the API to get the
    contents of this table relevant to the logged-in user, and displays
    them.

  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 (always on right)

          Stories:

          * Story list page (accessed from sidebar)
          * Story detail page (accessed by clicking on story name in list)
          * Projects detail page (accessed by clicking on project name in projects list)
          * Project group detail page (accessed by clicking on project group name in project groups list)

          Projects:

          * Project list page (accessed from sidebar)
          * Project group detail page (accessed by clicking on project group name in project groups list)

          Project Groups:

          * Project group list page (accessed from sidebar)
      
        *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
                Tags added
                Tags deleted
                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. Issues:

        1) Tied to stories. Settings are only for timeline events, not recent events. Timeline
             events currently apply to stories only (and display on story detail page),
             but recent events could be more broad (eg: boards and worklists). Either changes
             to these need to update the timeline events on a story, or we need a way to set user
             preferences for recent events. (related: a user may wish to have different
             preferences for timeline events and recent events)

             *What will the preferences be?
             *Where will a user set them?

        2) 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...

        3) More things need to be tracked. From the list above, it's clear that far more things can update than
            can be automatically tracked by a user. It's likely that a manager of a team using a board will want to
            track the board as it updates, for example.
  
  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

        *plugin merged, webclient button to turn them on in user preferences

    ii) in progress:

        *infra's email configuration needs merging for notifications to work on s.o.o: 
             https://review.openstack.org/#/c/270331/
        We will want to make this more finegrained.

    iii)  todo :
        * Let everyone know it's working and await feedback!

Roadmap Plan

We now have some detail about the current implementation. We need more input from users to work out where this falls
short. re: emails: we'll probably get comments on these as we work on them. So far, people have said they want email notifications, so we'll
need those before we're likely to get a lot of feedback.


# Overall Roadmap

We could probably refine this forever, so at what point should we consider changing priority?

1. Fix  bugs in current implementation (including making it consistent).

   a) User preferences patches in review -- Done!
        Though we should make more of these to allow users to set more preferences.

   b) Decide on approach to timeline events vs recent events
    If we separate them, then:
       * Decide on candidates for recent events (bigger set containing set of timeline events?)
       * Implement
           * backend to store preferences and handle them
           * UX for preferences

   c) Support for worklists and boards in:
       * recent events (see above, since these don't form part of a story, unless we change that)
       * timeline events? (eg: 'this story has been added to board x'. does anyone want this?)
       * user preferences (checkboxes to enable and disable notifications)

2. Merge email patches so that some basic email notifications work (currently 'off' by default')

   a) story https://storyboard.openstack.org/#!/story/2000456
   
   b) Then get feedback and improve these

3. Improve UX for Recent Events
  
   a) align all timestamps to right-- Done!
   b) display tag events instead of empty boxes-- Done!

(Those two things were done before they were added to this wiki page; have been included so
it's clear what sort of thing the vague 'improve ux' entails here.)

4. Give better variety of subscription options.
   a) track more things! (probably falls under 1b)
   b) allow user to unsubscribe from story within a subscribed project, and similar
Retrieved from "https://wiki.openstack.org/w/index.php?title=StoryBoard/Notifications&oldid=104290"