no way to be both official-reviewer on a project and not recieve email (without using an external mailing list service)

[Robert Collins]

In the LP project we would like folk that have qualified as reviewers for LP and its components to remain as official reviewers - we still value their opinion and knowledge. However they would like to not get mail on every change we make, which happens if they are in (directly or indirectly) the single review-team for our trunk branches. If they are not in that team, their reviews show up as 'community' - and we'd like to give them a stronger voice.

There are probably many ways to achieve this :)

[Aaron Bentley (abentley)]

The specific mechanism for email is not that a reviewer is "subscribed", it's that their team is the default reviewer, so they get email when the default is used.

[William Grant (wgrant)]

Most projects work around this by setting their branches' default reviewers to another team that has a contact address (to prevent the emails from going directly to the members) and the actual team of reviewers as a member (so they still have full review privileges).

For example, branches maintained by the Launchpad team are owned by https://launchpad.net/~canonical-launchpad-branches, but their default reviewer is set to https://launchpad.net/~launchpad-reviewers. ~launchpad-reviewers' mailing list gets the review notifications, and ~canonical-launchpad-branches is a member so its members can review without being spammed.

[Kill Animals (kill-animals)]

I wish this was higher priority. I am considering deleting my launchpad account, this issue is so bad.

[William Grant (wgrant)]

If this is a serious issue for you, ask the maintainers of the projects in question to implement the workaround I described in comment #2. It takes just a few moments to set up.

[Niklas Wenzel (nikwen)]

I'm on the same team as Akiva (https://launchpad.net/~ubuntu-touch-coreapps-test-writers) and therefore I get plenty of mails every day, which is really annoying. Just have a look at the attached screenshot to get an impression of what I mean.

I contacted the team owner and got the following response: "Sadly it looks like this is just not possible. I've considered merely deleting the team, but it has it's use. I'd suggest filtering the mails, or more simply just removing yourself from the team."

While I really don't want to do the latter as it would mean my MPs' autopilot tests won't be run automatically anymore, I'm really considering doing so as the "spam" is getting far too much. (Just received another email while writing that...)
Do you have any idea how to do it in this case?

[William Grant (wgrant)]

Did you point him at my workaround in comment #2? The key point is that a team with an email address configured will never cause email to be sent to its members -- messages go to the team's address instead.

[Niklas Wenzel (nikwen)]

Yes, I did. He looked at it and decided it was not possible. Do you have any idea?

@Nicholas: I've added you to the subscribers here to ensure you see this discussion. Would you mind reading through the other posts as well, please? Thanks. :)

[William Grant (wgrant)]

Well, it is possible, since most of our projects use exactly that workaround. Why do you believe it to be impossible?

[Niklas Wenzel (nikwen)]

William, I just sent Nicholas a mail again. Hopefully, he'll contact you. Thanks. :)

[Nicholas Skaggs (nskaggs)]

It's difficult in this case because the team at hand is a member of several teams; of which I don't have control over. Each of those projects would need to be setup in this manner AFAICT. Not that it is a bad thing to solve the mass mailings, but it got convoluted and complicated quickly. I'm sure nothing is "impossible", but I didn't see a way to make it work without killing the purpose of the team (an easy way to be a "developer" on all projects so jenkins will run on your mp's). I will say, I don't know how to do it. While the explanation makes sense, I'm not sure how to implement it in this case, nor is it likely I alone can do so.

[William Grant (wgrant)]

General Launchpad email background
----------------------------------

Launchpad follows three simple rules when sending email to a particular
person or team:

 - If the recipient is a person, send it to their preferred address.
 - If the recipient is a team with a contact address, send it to that
   address.
 - If the recipient is a team without a contact address, follow these
   rules again for each direct member.

So a message destined for a team will be sent to every indirect member
of that team, except where one of the teams on the way down the
hierarchy has a contact address.

We discourage teams from opting their members into email. Forcing
people to receive email they don't want just makes them filter it, not
read it. To this end, Launchpad has progressively made email settings
more flexible to let people control which email they receive, to move
toward opt in rather than opt out, and to eliminate the need for team
subscriptions.

Merge proposals in particular
-----------------------------

Merge proposals follow the recipient rules as above, but are the
primary source of email that hasn't yet been fixed to respect the
guidelines around opt-in defaults: each reviewer or requested reviewer
gets emailed on changes to the merge proposal, even if the reviewer is
a team and even if they're not subscribed to either branch, and there's
no way to directly stop that. We'll be giving merge proposals a big
makeover soon, which will fix this problem once and for all, but until
then there is a workaround to stop the spam.

One of the teams just needs to have a contact address set. The team
admins will find an edit link next to the Email field on their team's
Launchpad page, where a Launchpad mailing list can be selected or an
address can be specified manually. Choose the address, follow the
instructions in the email, and the merge proposal notifications will
be redirected from team members to that single mailbox.

You can use any address that you have access to, as long as another
Launchpad person or team doesn't already list that address. It's common
for people to use "plus addressing" to overcome this limitation: many
email services (including Gmail) let you suffix your username with
+anystringyouchoose, so <email address hidden> would end up
in my <email address hidden> inbox.

Using Launchpad itself as an example (https://launchpad.net/launchpad),
our projects' branches have their default reviewer set to
https://launchpad.net/~launchpad-reviewers, a team with a mailing list
configured as its contact address. Our main developer team,
https://launchpad.net/~launchpad, is a member of the review team, so we
all have review privileges and relevant MPs show up on our review
lists. Individuals who want to get email about all our merge proposals
can subscribe to the mailing list, or directly subscribe to just the
branches they're interested in.

[William Grant (wgrant)]

In the Ubuntu Core Apps case, it looks like each app has its own team
which owns the project and branch and does most of the reviews. Each
app team includes people specifically interested in the app, plus the
Ubuntu Core Apps Drivers and Ubuntu Core Apps Test Writers teams and
the Ubuntu Phone Apps Jenkins Bot.

The easiest option to fix the Test Writers problem is to just set a
contact address on the Test Writers team. Nicholas can do that
unilaterally and with immediate effect.

But it seems like the Ubuntu Core Apps Drivers team probably has a
similar problem. So I'd consider creating a new team containing
Ubuntu Core Apps Drivers, Ubuntu Core Apps Test Writers and
Ubuntu Phone Apps Jenkins Bot. That team would have a contact address
set to prevent emails from flooding through, and it would mean each new
app would have to add just a single member rather than three.

[Nicholas Skaggs (nskaggs)]

William, thank you much for the help. I implemented this with a new team as suggested and confirmed everything worked as described above.

[Niklas Wenzel (nikwen)]

I really back this thank you. Your help is really appreciated. :)