No way for team admins to contact all members of the team when a list is configured

[Andrea Corbellini]

A team administrator cannot contact all members at once if, for example, the contact address for the team is a mailing list, and not all members are subscribed to it.

This is related to bug #66105.

[Curtis Hovey (sinzui)]

I brought this issue up in several discussion immediately after the "Contact this user" feature was made available to teams. It was decided that if the team chooses to set the mailling list as the contact address, then it should be used in the "Contact this team" behaviour because it would be surprising if the list was not used. This blocked my suggestion to never user the mailing list.

I suspect the right way to implement this is with the launchpad mailing list itself. The mailing list does not know who the subscribers are; launchpad provides that information. If the getMembers rules were update to accept a parameter that specified if the list is for the subscribers, or the members we could have two priorites of emails. The default is to the subscribers. The member priority goes to all members.

This feature has another interesting interaction with the "lurker" and "good standing" features that permits non-members to subscribe to lists under certain restrictions. They would never get the member emails.

I think this feature should be implement in conjunction with the afore mentioned features to ensure that the interaction is consistent.

[Curtis Hovey (sinzui)]

Barry, I think you know of another way this feature could be implemented. I'd like to estimate this story this cycle since the lurker story is still looming in the near future.

[Barry Warsaw (barry)]

The other way to possibly do this is to hook in the Mailman 'urgent' flag, which essentially tells Mailman to contact all team members using regular delivery, irrespective of the member's delivery flag (enabled/disabled) or delivery mode (digest/regular).

The problem with that approach though is that I don't see a way to avoid some team members getting duplicates because Mailman has no idea that <email address hidden> and <email address hidden> might just be two registered addresses for the same user. With the 'urgent' flag, both addresses would get a copy of the message.

If the mailing list isn't used for these 'urgent' messages, then the best approach is probably to bypass the contact address for these types of messages, and calculate the list of recipients using the same algorithm we'd use if there was no contact address.

[Curtis Hovey (sinzui)]

On Mon, 2009-01-12 at 20:46 +0000, Barry Warsaw wrote:
> If the mailing list isn't used for these 'urgent' messages, then the
> best approach is probably to bypass the contact address for these types
> of messages, and calculate the list of recipients using the same
> algorithm we'd use if there was no contact address.

I think I want to use the list of the message, I assumed that we would
of the get_contact_email_addresses method to determine all the addresses
for the list to use. I see this is hard because when a user replies to
that email. Mailman must see something in the header to tell it to use
the members rules instead of the subscriber's rules. If the user is in
the list, the message goes through, otherwise the message is held.

[Barry Warsaw (barry)]

Sorry Curtis, a few of the typos in your comment are making it a little hard to follow, but let me see if I understand your proposal. (e.g. there's no get_contact_email_addresses method).

You'd like to be able to send one message to the mailing list, and have the Mailman side use something in the email to determine what set of recipients to send the message copy to. If the message is created on Launchpad, adding some tag that Mailman could recognize would not be difficult. Heck, we could even stick in the 'Urgent:' header that Mailman already recognizes.

The problem is that Mailman really has just one list of members and it has no knowledge of which addresses belong to which people. It does know which addresses are disabled and which are enabled, and we use this trick to allow all team members to post to the list from any of their validated addresses, but limit delivery to just those that are explicitly subscribed. "Explicitly subscribed" are just the Mailman list member addresses that are enabled.

We could definitely use the Urgent: header approach to, as I said, bypass the disabled flag check, but it means every list member will get a delivery at every address they've validated with Launchpad. I for example would get 7 copies, which doesn't seem like a good idea.

I think to do what you're proposing, you'd have to dynamically update the Mailman list of members whenever you had an Urgent message to deliver, but that seems infeasible because you'd also have to reset the mailing list's membership flags once the urgent message is delivered.

I can think of some hacks of various complexity and effectiveness to make this work. We could hack Mailman to track the launchpad id for each address it knows about, then do de-duping on those when the Urgent message came in. That'll mean a non-standard list attribute and an extension of the xmlrpc protocol to communicate that information to Mailman. Or we could use the Real Name (i.e. displayname) to de-dup, but that's not really going to work and would require some custom code too.

Another way to do this would be to utilize Mailman's bin/inject program, or the Python API to that command. That API accepts a list of explicit recipients which overrides the recipients normally calculated by Mailman. The problem here is that the Launchpad side doesn't have access to that because the systems are separated. So Launchpad can't directly call that method or command. We could however extend the xmlrpc protocol between the two systems to add a 'send_urgent_message' action. When Mailman saw this action during it's normal LP polling loop, it would have to get the team name, message text, and recipient list. Then it would parse the message and call the inject() method with the explicit list of recipients.

That's probably the least hacky way to do it, and thinking about it now, it's the way I'd recommend implementing it, if you don't want to bypass the mailing list. Though I'd still like to explore the bypass-the-mailing-list approach. :)

[Andrea Corbellini (andrea.corbellini)]

Wouldn't be simplier to give Mailman just the contact addresses of each person and then send the mail with the Urgent flag?

[Andrea Corbellini (andrea.corbellini)]

Bug #316047 may be related.

[Curtis Hovey (sinzui)]

On Mon, 2009-01-12 at 23:31 +0000, Barry Warsaw wrote:
...
> Another way to do this would be to utilize Mailman's bin/inject program,
> or the Python API to that command. That API accepts a list of explicit
> recipients which overrides the recipients normally calculated by
> Mailman. The problem here is that the Launchpad side doesn't have
> access to that because the systems are separated. So Launchpad can't
> directly call that method or command. We could however extend the
> xmlrpc protocol between the two systems to add a 'send_urgent_message'
> action. When Mailman saw this action during it's normal LP polling
> loop, it would have to get the team name, message text, and recipient
> list. Then it would parse the message and call the inject() method with
> the explicit list of recipients.

This is the scenario I had in mind.

> That's probably the least hacky way to do it, and thinking about it now,
> it's the way I'd recommend implementing it, if you don't want to bypass
> the mailing list. Though I'd still like to explore the bypass-the-
> mailing-list approach. :)

My concern with by-passing the list, is that the conversation is not on
on the list, replies could be lost. The conversation is still not
private of course, it is archived for everyone to see.

[Daniel Holbach (dholbach)]

Isn't this fixed by the "contact team members" button now?

[Andrea Corbellini (andrea.corbellini)]

> Isn't this fixed by the "contact team members" button now?

Unfortunately no: this button is only present when a team does not have a contact address.

[Curtis Hovey (sinzui)]

The "Contact this team" link is always present. This bug is still open because we honour the team's decision to set the mailing list as the contact address, even though is is possible that no team members are subscribed. Mailing lists are fundamentally broken

[Robert Collins (lifeless)]

So contact this team now emails the owner not the members; so this bug is a bit clearer: we don't provide this facility. The question then becomes, should we provide it?

I think the answer has to be no - or at least no for anyone that isn't an admin/owner : we don't want to become a trivial email multiplier.

[Robert Collins (lifeless)]

And that suggests that the simplest thing to do is to stop using the mailing list ever, and make the UI for 'contact this team' be 'contact the administrators of the team'; for the administrators it can say 'contact the members'.

[Curtis Hovey (sinzui)]

Robert, you misunderstand the link you inspected.
non-members contact the owner (probably should be admins)
members contact all the members, but also honour the contact address. (No not honour the contact address.)

[Robert Collins (lifeless)]

On Wed, Feb 1, 2012 at 4:57 PM, Curtis Hovey <email address hidden> wrote:
> Robert, you misunderstand the link you inspected.
> non-members contact the owner (probably should be admins)
> members contact all the members, but also honour the contact address. (No not honour the contact address.)

Oh, but the thing about the list getting in the way is still true, right?

-Rob

[Curtis Hovey (sinzui)]

Yes, the list is in the way. By list I mean contact address. Any list or the team owners second email address is effectively stops team member communication

If we believe this is an issue about the text of the link and *never* use the team contact address. I would tag this bug as trivial.
We are removing the TO_TEAM rule from ContactViaWebNotificationRecipientSet and deleting tests!

[Robert Collins (lifeless)]

I think we have to decide:
 - trust the contact address
 - or don't

So this bug is either wontfix (we trust the address) or trivial (we
don't trust the address)

[Curtis Hovey (sinzui)]

Teams need a reliable way to communicate, and failed to solve the problem with mailing lists. this was a major debate in the implementation of contact-this-user. We know teams need to communicate and when they cannot, they ask us to extraordinary steps in support to help them. If Contact-this-team had a LEP, it would have failed to meet this use case and would have continued in development.

I do not trust the contact address. Team leads set contact addresses to avoid bot spam. This feature is about people; team members are trying to talk to each other. Marking this as wont fix will not end frustrations. I do not want to take help one more ubuntu team that cannot send an email to its members about a policy change.

[Curtis Hovey (sinzui)]

Lp will contact the team members. Lp will ignore team contact addresses when a member contacts the team to ensure the team functions. non-members will contact the team admins, not the team owner.

[Launchpad QA Bot (lpqabot)]

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