all changes to bugs trigger notifications

[Bryce Harrington]

Please add a way to flag launchpadlib operations as 'minor-edit', thus making launchpad not send email notices about the changes.

[Discussion]
With launchpadlib it's useful to write scripts that do various recordkeeping and janitorial work. For instance, adding tags like 'patch' to bugs with attachments that are patches, or updating the titles to include specifics about hardware info. These can be quite helpful for managing bug workflows or to help sort and prioritize bugs.

However, in general, these changes are minor and of little importance to anyone subscribed to the bug report. They don't provide any indication of human activity on the bug report, they don't give the reporter any information that helps them work around or resolve the issue, and they tend to increase the perception of launchpad's email as overly chatty.

So the idea is to provide a parameter that these scripts could flip on to indicate that the change is minor. This should suppress email from being sent from Launchpad. There are probably only a few API calls which would benefit from having this option... adding/removing tags, changing the title, and (maybe) altering the description.

[Martin Pool (mbp)]

That would be nice.

In some ways it would be nice if this also exempted the bug from being marked as recently changed; I don't especially want minorly-changed bugs at the top of that sort order. (Perhaps.) However if this ties into api caching behaviour it may be infeasible to change. It's not super important.

There is an analog for this in code reviews, which are also interesting to bots and which are also complained about as being too chatty.

[Robert Collins (lifeless)]

I agree it would be nice; Wgrant points out that this is kindof a launchpad - malone issue, rather than launchpadlib: launchpadlib is constrained to malones facilities.

matching this, some folk will want 'email on minor changes' :) - folk running e.g. indexers

[Bryce Harrington (bryce)]

On Tue, Apr 20, 2010 at 02:20:34AM -0000, Robert Collins wrote:
> I agree it would be nice; Wgrant points out that this is kindof a
> launchpad - malone issue, rather than launchpadlib: launchpadlib is
> constrained to malones facilities.
>
> matching this, some folk will want 'email on minor changes' :) - folk
> running e.g. indexers

Yep, and a matching email header for those wishing to receive them but
be able to filter them (or color code in mutt or whatnot).

[Martin Pool (mbp)]

See also bug 568169.

[Bryce Harrington (bryce)]

Apport's 'apport-collect' is another example of a script which could benefit from something like this. Currently, when run on a bug it sends a separate email for each attachment, so for bugs against packages like the kernel, compiz, and xorg that have sizable apport hooks, all the file attachment notifications generate a hefty amount of email. This email is of interest to almost no one (only the triager really cares, and often only marginally), so being able to mark these operations as minor-change would suppress a lot of email notices.

[Deryck Hodge (deryck)]

My preference would be to do something along the lines of bug 568169 and add the ability to distinguish work from API clients in bugs. Then, we could couple that with adding an email header and a notification setting to turn of or filter notices from api clients. The other issues raised here -- noise from changes to title, description, or adding tags -- should be configurable by themselves, regardless of whether or not that change is minor.

Would that be acceptable, rather than a "minor change" flag? I don't generally care for these kinds of flags.

Note, too, that we are about to begin work on improving Launchpad Bugs notifications, so this is could perhaps be done as part of that work. See: https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications for more info on that work.

[Martin Pool (mbp)]

On 27 April 2010 02:08, Deryck Hodge <email address hidden> wrote:
> My preference would be to do something along the lines of bug 568169 and
> add the ability to distinguish work from API clients in bugs.  Then, we
> could couple that with adding an email header and a notification setting
> to turn of or filter notices from api clients.  The other issues raised
> here -- noise from changes to title, description, or adding tags --
> should be configurable by themselves, regardless of whether or not that
> change is minor.
>
> Would that be acceptable, rather than a "minor change" flag?  I don't
> generally care for these kinds of flags.

I basically agree.

I think human-set "this is a minor edit" flags, despite being fairly
popular on eg wikipedia, are likely to have a lot of errors in both
directions: people will not set it when they perhaps should, and
conversely may try to smuggle spam or contentious changes through as
minor.

On the other hand I think having a "notification preferences" bit that
controls whether you are told about trivial changes or not would be
useful.

--
Martin <http://launchpad.net/~mbp/>

[Bryce Harrington (bryce)]

On Mon, Apr 26, 2010 at 04:08:40PM -0000, Deryck Hodge wrote:
> My preference would be to do something along the lines of bug 568169 and
> add the ability to distinguish work from API clients in bugs. Then, we
> could couple that with adding an email header and a notification setting
> to turn of or filter notices from api clients. The other issues raised
> here -- noise from changes to title, description, or adding tags --
> should be configurable by themselves, regardless of whether or not that
> change is minor.
>
> Would that be acceptable, rather than a "minor change" flag? I don't
> generally care for these kinds of flags.

Hmm, well I'm certainly open to better ways to solve this, I totally
agree adding flags is probably sub-optimal.

One thing I like about the scheme you outlined is it would cover actions
by prolific human triagers as well as scripts.

I think having an email header to identify API scripts is great idea,
and definitely agree that would help. I'm uncertain about the idea of
turning on/off notices from API clients though... it seems to be too
broad of a stroke. There are definitely some API scripts which do stuff
worth suppressing (adding tags and the like), but there are also many
whose output should not be missed (such as ones asking reporters for
files, or that mark bugs expired).

Being able to configure noise from changes to bug fields would better
address the crux of the problem. But I wonder if it might also be too
broad of a stroke... For instance, I probably care more if the original
reporter changed the description/title/tags than if a script did it.
But that concern aside, I think this is also something which could help
a lot.

[Bryce Harrington (bryce)]

On Mon, Apr 26, 2010 at 04:08:40PM -0000, Deryck Hodge wrote:
> Note, too, that we are about to begin work on improving Launchpad Bugs
> notifications, so this is could perhaps be done as part of that work.
> See:
> https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications for
> more info on that work.

One thing I should add, there are sort of two different stakeholders I
had in mind for the 'minor-changes' flag.

The first is developers and triagers who get a *ton* of email. Email
headers and preference tunables are great for solving the issue here.
They get enough email that it's worth taking some time to learn and set
up these things. So the proposed solutions at the above URL definitely
suit this group.

The other group are occasional bug reporters, who get confused (or
annoyed) by the automated changes to their bug. This group is not
likely to take time to configure things or set up email filters.
So what's important here is what the defaults are. If the configuration
settings were implemented such that by default notifications of changes
to tags, titles, descriptions, branch linkages, etc. were suppressed,
then I think that'd suit the needs of these stakeholders.

[William Grant (wgrant)]

Why should API clients be discriminated against? Not all API applications are batch operations, and some batch API applications make changes that are not minor. Discriminating against applications simply because they use the API is *completely wrong*.

[Martin Pool (mbp)]

On 28 April 2010 08:38, William Grant <email address hidden> wrote:
> Why should API clients be discriminated against? Not all API
> applications are batch operations, and some batch API applications make
> changes that are not minor. Discriminating against applications simply
> because they use the API is *completely wrong*.

"discriminated" is a somewhat overloaded word. I think Launchpad can
useful allow users to discriminate (eg through mail filters.)

I think asking human users whether a change is a minor change (as
wikipedia does) is unlikely to be super useful because humans are
inconsistent.

For api-driven changes it is more reasonable to expect that at least
any particular program will consistently set metadata like this. When
feed-pqm queues a proposal, it could mark that change precedence=bulk
and then users can opt in or out of getting mail about that, either
through their own filters or eventually through a notification
manager.
--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

Hi, wgrant.

My thoughts are similar to Martin's here on this. Just to be clear, though, I'm suggesting these options be added so that *users* can make this decision. I'm not suggesting Launchpad automatically hide API activity or anything like that. Ultimately, I think this would work best if done per client, i.e. I can turn off script A that expires bugs but leave notices from script B that adds tags and updates bug titles. I think initially the notification setting for this would have to be per project rather than per client, but with an email header, one could choose to receive notices from all clients but then filter according to client.

As Bryce says, we need a sane default, which I think includes API client activity, but we need to make the system as flexible as possible for users who don't care to know about scripted activity on a bug.

Cheers,
deryck

[Bryce Harrington (bryce)]

William, I think the better metaphor here would be like having a 'do-not-call-list' and a 'caller-id' for people to have some control over robo-calls.

[Bryce Harrington (bryce)]

I think last year's changes to bug mail subscriptions has largely obviated the need for this feature. At least, it is no longer important to me.