launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Tue, Nov 29, 2011 at 12:19 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> The notification system has a lot of overlap with comments/activity on
> a bug, mp, or question.  To start with, perhaps they will be
> redundantly stored both as events and where they currently are, but
> eventually the bug page could will just show the overall metadata
> (task table etc) and then the wall of activity about that bug.
>
>> Well, I humbly suggest that there are two common problems needed to
>> implement customisable notifications, dashboards/walls, and timelines:
>>  - 'who is interested in a given event'
>
> ... ie for the purpose of pushing email or other notifications out
>>  - 'who was told about a given event'
>> (Note that the tense is very deliberate here).
>
> It's not clear to me that people would actually prefer "what events
> was I interested in?" to "what events am I interested in?"  If people
> actually prefer the latter perhaps there is a way to implement it
> reasonably?

We can implement a current-interest only view by revising history when
folk become interested in/lose interest in some events. This would be
an asynchronous process - it wouldn't happen immediately that they
e.g. leave a team, but shortly afterwards.

> In your approach as I understand it: relevance of events to people is
> marked at the time the event is fired (or soon afterwards).  So if I
> subscribe to a new bug, I will see events about it in my timeline from
> that point on, but not previous activity on it.  Similarly if I
> implicitly subscribe to some bugs by joining a team.

> Conversely if I unsubscribe from or mute a bug or leave a team, I will
> still have all its activity in my log.  I suspect this will cause
> complaints or confusion.  It is explainable though.  It is consistent
> with what email would have been sent to the user, but inconsistent
> with most social wall-type things people may be used to.

Yes. I think regardless of the UI / interaction design we choose,
having the database reflect 'what the person was interested in' is
appropriate - because that is key to delivering indexed responses -
rather than reconstructing interests at some arbitrary historic date,
we have an asserted 'this is what interested them at that time' - we
can of course rewrite that [fairly trivially] if we want to calculate
their prior interests with some new team memberships etc. This is
complicated [a little] by teams being deleted and merged and so forth
- but as long as we choose one UI *goal*, the implementation is still
quite tractable.

> If somebody is removed from a commercially or security sensitive team
> (perhaps they were incorrectly added) it is a bit strange to keep
> serving what should have been private data to them, even if they could
> potentially have a copy of that in email.

As with all other LP SOA components, filtering of backend data will
need to be done to combine different facilities. In this case, the
source data for events needs to be consulted to determine visibility.
This is entirely independent of whether we redact their stored event
history or not. (Imagine someone leaves a security team and then is
added back. Should their notification history be emptied? I think that
depends on whether we show 'events from things you are currently
interested in going back in time' or 'events that you were interested
in going back in time'). Either way, we'll always want to do a
security filter on the returned contents.

> We could fix this while keeping the same approach of having things
> fully expanded out by subscriber by going through to add or remove
> rows when subscriptions change.

Indeed :)

-Rob