launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxxx>]

On 28 December 2011 19:07, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:

> Firstly, there is the 'reply by email and that email is forwarded like
> a mailing list' - its a nifty little feature but as most(citation
> needed) interactions happen over the web, forwarding what we receive
> verbatim is relatively rarely exercised and not intrinsically
> valuable. (Note that this is different to 'bug mails thread well in
> mail clients', which merely depends on common subjects (gmail) or
> reply/thread ids (thunderbird / evolution) etc).

So it will still be possible to reply by mail, and people (with a
relevant subscription) will get mail as a result, but it will not be
the same original mail that was forwarded - it may have different
contents (well, it often already has footers), the message id will be
different, gpg signatures will be stripped.

> There were some other grey areas I think we can put stronger straw men
> behind... the system will capture *what was done*, not *what would
> have been done* - that is, if you subscribe to a bug, and look at your
> notifications, it won't show a notice for previous bug comments in the
> web UI or anywhere else : if you were not subscribed when an event
> happened, you were not notified, period. Conversely, if you were
> subscribed, the event will be in your history even after you
> unsubscribe. I think this is easier to understand and explain to
> users. 'Events on services which I am currently interested in' is a
> related, but separate problem - it is separate because things like
> event combining and 'detailed-first-only-mail' depend on knowing some
> history.

I thought about this some more, because I am much more interested in
seeing a timeline (which you currently can't get at all) than in
improving notifications (which could be improved but do at least work
ok over email), and at any rate eventually we want both.

Perhaps this can be done by stacking two services: events, and notification:

Application code signals when a semantic event occurred: "a bug was
filed", "an mp comment was posted", with a dict of semantic-web-ish
links as was discussed above.  Two things listen to this: one is a
service that records all events; another is a service that sends
notifications about events.

The notification service can match the event dict against subscription
filters that say who wants to know about what events for what reason.
It can optionally record every notification it sends so that, facebook
style, you can go back and look at things you were previously notified
about.

Separately, you can query the timeline service for all events relevant
to a particular scope - bug, product, person, whatever.  In that case
you see everything that happened (that you are allowed to see), even
if you were not interested in it at the time.  For instance, we could
show this kind of timeline on a product or person home page, to give
you something like what is shown on many github pages.  Or, I suppose,
we could match your subscription filters against this to show you
everything that you would have seen if you'd subscribed earlier.

If this is append-only and sufficiently detailed it will do pretty
well for a user-level audit trail.

It seems like the main snag here is privacy: to check whether a person
can see a particular event, we'd probably have to check whether they
can see every relevant object related to it, at the time they look it
up.  That might be expensive, but perhaps there are cheaper ways,
along the lines of the bug privacy enhancements, to just check a small
number of scopes to know whether someone can see an object.

-- 
Martin