Strong communities are built on teams. Launchpad has a very rich infrastructure to support the creation of teams, which allows communities to develop in a sophisticated fashion around projects or initiatives.

Let's look at a team:

• https://launchpad.net/~launchpad-beta-testers/

Here's a snapshot of part of the page at the time of writing:

attachment:teamoverview.png

Subscription Policies

As you can see, this team has a list of folks who have just recently joined, and also a list of people who have recently applied to join but not yet been approved for membership. This highlights a useful feature of Launchpad team management - membership subscription policies. You can create a team which is entirely open - anybody can join just by adding themselves to the team. You can also have a team which is moderated, as Launchpad Beta Testers is, which means that anybody can apply to join but the team administrators have to approve your membership. And finally, you can have a team which is restricted - the only way to become a member is to have a team administrator add you to the team.

These subscription policies are similar to those used for mailing lists. They allow you, as the creator or administrator of a team, to decide how flexible you want to be, and to maintain good control of the growth of your community if you want that.

Team Hierarchies

Notice that Launchpad Beta Testers is not a subteam of any other teams? Launchpad allows you to make a team a member of another team, which means of course that all the members of Team A are now also effectively members of Team B (they get all the same permissions and access to all the same goodies). Technically they are "indirect" members of Team B, but that makes no difference, they are treated exactly the same as people who signed up directly to Team B.

Let's look at another team:

• https://launchpad.net/~motu/

Here is the relevant bit of screen:

• attachment:motuteams.png

The MOTU ("Masters of the Universe") is a very important team in Ubuntu because it's the team which looks after the largest collection of packages and is also the team where most developers first get recognized as full contributors to Ubuntu. As a result, the MOTU team is a member of several other teams - because structuring things that way means that "all new Ubuntu developers" become members of those other teams too.

There is no practical limit to the depth of team nesting that you can arrange. For example, we have some community teams which are organised in regions of a country, and they then also have a national team which consists of only the regional team members. This way, everyone who is a member of a regional team is also a member of the national team, but they don't have to do any administration of individual memberships in the national team because it's all handled by the regions.