Mail notifications sent to team admins on joins / leaves to open teams

The value of these emails is to help track the churn of the group, particularly around events that the group might hold. Also it allows the admin to send out a personal welcome to new members or a goodbye email to those leaving.

I'd say if they are annoying most admins of these open groups can configure a suitable email filter to trash them as they arrive..

If a change is deemed necessary by this 'bug' please make it a checkbox option for the admin. Just because you view it as useless spam, others consider it a valuable tool.

For the Danish LoCo team the checkbox option would be perfect. For our team these mails are low volume, but they are a good means to keeping an eye on the membership flow.
Like Chuck Frain we think that a checkbox option to turn those mails on/off would be fine.

I find them useful, and not annoying for the ubuntu-uk team updates.

I find the emails to be useful, but a little repetitive. It would be more useful for me to have a monthly report showing all the users who have changed status (joined, removed, left, expired, renewed) and then I can take any external action based on that.

It also gives me a better churn overview than single emails. If this idea is good, I will make a separate bug report.

I don't mind the emails, however I can definitely see the benefit of a checkbox option to turn the notifications off/on... I like Martin's idea as well.

With regard to having folk setup mail filters, its a poor user experience if upon becoming a developer in (say) drizzle, you immediately need to add several list filters to turn off unwanted email.

We intended the LP API to provide good facilities for reporting and analysis, and I think it can be used to do daily/weekly/monthly reporting for community management.

Regardless of whether we have a checkbox or not, the key question for me is what is the sane default: should we mail people about things they cannot control and which have no functional impact by default, or not?

(LP has a strong culture against options-for-everything - we want to figure out the best behaviour, and use that, and only add options as a last result). I don't think we've tried nearly hard enough here, yet :).

@doctormo
> It also gives me a better churn overview than single emails. If this
> idea is good, I will make a separate bug report.

Please do, I think thats a good report to have.

-Rob

I've now discussed this with Curtis, who has spent a great deal of time talking to other users and looking at how our mailing list / team management features hang together.

He pointed me at bug 285414, which was filed because of the same behaviour - its a feature request asking for a way to turn the notifications off - essentially asking for a checkbox. That bug needs a wider change to be addressed than this bug because folk may want to opt out (or in) to changes in moderated/restricted/private teams as well.

He also pointed me at bug 507515 which asks for the ability to subscribe to changes in a team - so that non-admins can send welcome emails, have a feel for activity around the team, and so forth.

So, big picture, what we want to do is:
 - allow subscriptions to team metadata changes of various sorts, including membership
 - still send notifications when an action needs to be taken [e.g. approving a moderated join request]
 - stop sending notifications to folk who are not subscribed
 - default admins for non-open teams to have a subscription.

The question then, is can we reasonably make the change to address this bug before implementing subscriptions to team metadata? The consensus we have in #launchpad-dev is that we can: we have a bug going back to 2008 asking for less mail about this sort of thing.

So, I'm going to land my branch for this; if anyone wants to work on bug 507515 I'm positive we can get some mentoring for you.

I am in favor of a checkbox for the notifications. DoctorMo's idea is also very nice.

Fixed in stable r13528 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13528>.