Let people lurk on mailing lists

+1 to this, though it should be an option on the mailing list to restrict delivery to folks who are actually team members, and that option should IMO default to "true".

A case could also be made that it should default to true for teams that are moderated or closed, but open for teams that themselves are open, but that makes it harder to predict and also means that there will be weird interactions when the team status changes. So I think this should just be a checkbox on the mailing list admin page:

   [x] Deliver mail to subscribers who are not also members of ubuntu-dev.

Mark

See my comments in bug 194934

This should be a post-2.0 feature.

We will postpone working on this in favour of private team features.

I'd like to add another use for this, I need to set my bot up to receive bug mail, and in the currently LP setup I need to make him his own account, or lose my ability to receive bug mail.

What's the status of this bug? I'm working with others on a project called the FEniCS Project (www.fenics.org). We are currently migrating to Launchpad from our own server that currently runs a large number of mailing lists. We rely heavily on mailing lists but it looks like it is only possible for team members to subscribe. Why is that so? We would like anyone to post and read the mailing lists, but we don't want to give write permissions to everyone.

Thanks

This bug is marked as Low. That means there are no plans to work in this. Low bugs are fixed opportunistically by developers when working on a related issue. This is not a bug however, it is a feature request. Someone from the community can work on this feature. I think there is a fundamental design flaw with teams-mailing-lists. You created the list knowing that everyone who is subscribed is, well, subscribed. Since team members are not automatically subscribed, you can never reach the whole team, yet this is insane because in most cases, the only reason the team exists it to get the list mail. This feature may require a decoupling of teams from mailing lists and data migration.

Anders, your summary of your intent may cause you problems in the future. You rarely want to us a team for both control and communication. Automated systems send messages to the team used for control, such as project owners and bug supervisors. Most launchpad teams do not want these kinds of messages going to everyone one on the team. Most project create teams for control, or for communication and do not mix their purposes. Create open and moderated teams for the lists you want. Create separate teams for groups that control projects, bugs, ppas, branches, and translations.

Thanks Curtis. This is exactly what we did and I realized this a couple of minutes after sending the comment.

We have now created two teams for each project, one Foo Team (foo) and one Foo Core Team (foo-core). The first team is open and owns the mailing list. The second is restricted and owns the code. Furthermore, we've made foo-core a subteam of foo.

This seems like a good solution and does not require much work to set up. Is there some Launchpad guide or best practices for how to best make use of Launchpad to organize a project? I might not have looked carefully enough.

So, I agree that we need to decouple teams from mailing lists and make the latter first-class objects. I think there's pretty much widespread agreement on that, and it's just waiting for resource allocation to tackle. Once that's done then "subscribing" and "joining" can really be collapsed to one action, joining a mailing list.

Once that's done, it's not clear to me what "lurking" means. For open mailing lists, if you want list traffic, you'd just join the mailing list. There'd be no team you'd have to join first. John's comment is interesting because he wants to subscribe a bot to the mailing list and not have to create an account for the bot first. I'm not sure we want to allow unregistered/unvalidated email addresses to be subscribed to our mailing lists, because that's a potential vector for abuse. However, we have a second related use case: if we wanted to subscribe an external mailing list to a Launchpad mailing list, you can't really do an email validation dance, since you don't want the external mailing list to receive the confirmation token. I haven't come up with a good workflow to address both the external mailing list and bot use cases.

Just a comment about subscribing one list to another. We've subscribed our mailing lists (hosted on our own server) to Launchpad bugs before which would be similar to subscribing one list to another. What we did then to manage the verification was to make use of the fact that our mailing list held posts from non-subscribers for approval. So when we received the confirmation, it was held for approval and the list administrator could go in and follow the confirmation link without sending it on to the list.

@Anders: good point!

On Mon, 2009-11-23 at 19:17 +0000, Anders Logg wrote:
> Thanks Curtis. This is exactly what we did and I realized this a couple
> of minutes after sending the comment.
>
> We have now created two teams for each project, one Foo Team (foo) and
> one Foo Core Team (foo-core). The first team is open and owns the
> mailing list. The second is restricted and owns the code. Furthermore,
> we've made foo-core a subteam of foo.
>
> This seems like a good solution and does not require much work to set
> up. Is there some Launchpad guide or best practices for how to best make
> use of Launchpad to organize a project? I might not have looked
> carefully enough.

No, help.launchpad.net does not answer these kinds of questions. When I
consider all the advise I gathered, I think it will take my Christmas
holidays to write. I'll try to write something about team project
structures in this weekend.

--
__Curtis C. Hovey_________
http://launchpad.net/

@Curtis: I'd be interested in reading that.

FWIW, here's how we ended up organizing our projects after a weekend of trial and error: http://www.fenics.org/wiki/Development

On Mon, 2009-11-23 at 22:08 +0000, Anders Logg (test account) wrote:
> @Curtis: I'd be interested in reading that.
>
> FWIW, here's how we ended up organizing our projects after a weekend of
> trial and error: http://www.fenics.org/wiki/Development

This is the best description of working with a project I have seen.

If was just using launchpad, I would not know what the dolphin team did
https://edge.launchpad.net/~dolfin Considering how well Launchpad pages
are ranked by Google, you may want to to improve the team and project
descriptions to attract user and contributors.

--
__Curtis C. Hovey_________
http://launchpad.net/

So a group of developers I am tangentially working with is discussing moving the mailing list, and there is a strong pushback against moving it to launchpad because:

a. a developer doesn't want to have to "join" a "team" in order to subscribe to a mailing list and

b. the mailing list functionality is quite difficult to discover

regarding issue b., the developer wrote: 'Unless you know that there is a list, you wouldn't even think there is one: the link to the list only shows up under "Answers" as "Answer Contact" and page there makes it look like the list is for $PROJECT developers only'

A different developer wrote:
"""
Since Launchpad's UI makes this basically impossible to discover, here are the steps for getting on to that list:

    * Make sure you have a launchpad.net account and are logged in. (Start here if you don't have one: <https://login.launchpad.net/+new_account>.)
    * If you already did have one, make sure your email address is correct. (See <https://launchpad.net/~your-username/+editemails> to double check.)
    * Go here: <https://launchpad.net/~$PROJECT-users>. (By the way, this isn't linked anywhere from <https://launchpad.net/$PROJECT>.)
    * Click "join the team".
    * Make sure "Subscribe me to this team's mailing list" is checked.
    * Click "join".
"""

I think these two issues may be intimately related, so I'm posting the both on this bug #194126, but if people responsible for launchpad design think otherwise I will create a separate ticket for "mailing lists are hard to discover".

Just to clarify, I think that these two issues (a) and (b) may be intimately related because it is quite possible that changing some words to say "mailing list" instead of "team" may fix both issues for these developers -- not sure.

This seems related to #191111.

I think there are other existing defect reports around this area
already, but anyhow...

a 'team' is just a collection of 'people-or-team' objects; for mailing
lists in launchpad its used to identify 'folk with subscriptions' to
mailing list - with the default subscription being 'no mail received'
- so we definitely let folk lurk at the moment. Teams are also able to
be put anywhere a role is provided for (e.g. bug assignee, project
maintainer, can-write-to-branch etc) - and teams-with-lists permit you
to couple 'being on this list is a requirement of getting this
privilege' - if you want to.

What I do in my personal projects to work around LP's UI/modelling is
in the project description include a link to the list.
https://launchpad.net/subunit is an example of this.

Grab me on IRC if you want to talk about the confusion some more, we
are totally open to fixing things, but (as you may know if you've been
following the blog) we're currently reviving our project by
identifying and zapping truely critical issues that we let build up
over time which had become ridiculously painful and a massive energy
sap.

-Rob