On Tue, Nov 29, 2011 at 12:19 PM, Martin Pool <m...@canonical.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
