Je Hais Le Printemps

What is the very first thing that I must do when I've registered a project into Launchpad?

The answer MUST NOT BE "dive into code".

From my experience, you have to create at least 3 to 4 different teams, each one of them having different levels of permissions and aiming at different tasks.

1. The "Admin team"

Usually, you start being the only admin. The admin in Launchpad is knowned as "the driver". He's the one that has the right to change the project title, summary, publishing announcements, etc. You may think having an admin team is pointless, but just imagine that you are away (for vacation, for example) and a big security fix is to be announced... If you are the only driver, this announcement may not reach the project page until you're back, and you had time to catch up with everything, etc. Having a backup plan (i.e. someone else involved) is a good idea (tm).

Since the members of this team can have a deep impact on the project status, you must hire its members carefully. That's the reason why I highly recommend this team to be "Invite Only". When creating the team, you must check the "Restricted" radio button.

2. The "Dev team"

Launchpad is about project management, right? Hence, coding. The "dev" team looks like a core requirement, then.

The dev team will be in charge of the "code" tab in Launchpad. This team must be the place where core coders and contributors may control the source code of your project. The "Project Dev Team" must be the owner of your "trunk" branch for example. If so, any member of this team may commit / push changes in trunk and eventually rollback whenever something is broken.

Once again, this team should fit the size and status of your project ; its members may be involved since the beginning, or may gain membership following the "meritocracy", i.e. they've showed major achievement by sending patches, registering many branches that landed into trunk, etc. The developers involved in this team should have also a vision about the project, and you may want to make sure that these persons are likely to work together, and know how not to mess with someone else's code (because any member of this team may commit/ push things into any team branch).

Again, this team may be "invite only", or at least "moderated team", because you must have control on its membership.

3. The "Team"

This team may look pointless, because its members usually don't have many permissions. But having this team makes at least one good point: its members are sharing something, they may be hackers, translators, they may write documentation, register bugs, send patches, or are just interested in getting in touch with your project.

Belonging to the team makes you feel you're part of the project, in a way or an other.

This team can be moderated or completely open. My personal preferences go to "moderated", with one single rule: "accept anyone". Okay, that sounds silly, but the fact that any candidate has "passed" the test means "I accept you as a member of the team, welcome aboard". This trick has a nickname: it's the "Bacon Trick". Of course, you may want to open it, which leads to the same.

As this team is more or less open, it may grow bigger ; but who cares? As your project community grows, everything looks good.

Usually, this team's name equals the name of your project.

4. The "Bug Squad".

In Launchpad, you can register a team to every bug report, and any change in every bug in your project. This is where the "Bug Squad" goes. Anyone interested in following the evolution of the bugs, without having to manually register to any of them may register this team.

As this team may receive quite a large amount of emails if the bug reports on this project, I would recommend you to leave this team "Open", since only volounteers may want to join it and/or leave it if they are getting annoyed by the number of emails.

In my opinion, you may make this team optional, because you may decide to register the "Dev Team" to these bug reports, since they're the ones able to triage, fix, close the bug. But in an other way, you may want to separate the teams, allowing non-developers to follow the bug reports as they want, without making them pass the "Dev Team" test. Eventually, having the "Dev Team" member of the "Bug Squad" forces every developer to follow the bug reports. I doubt they'd rant about that.

I knew this was optional. When you land on bugs.launchpad.net/my-project/, you have access to a link saying: subscribe to bug mail. There you can subscribe to the "email feed". Bingo.

Conclusion

It may sound silly to build 4 teams at the infancy of your "pet" project, but sometimes, and it happened to me as the founder of PyRoom, the number of contributors on a project can grow geometrically, and without these tools to handle it, you may be unable to manage branches and bugs correctly.

The naming scheme of your team is at your preferences, but I'd recommend:

• Team :
• Dev Team : -dev
• Admin Team : -admin
• Bug Squad : -bugsquad meh?

Of course, you may follow these indications or not, and eventually add many other teams to your project: Translators, Users, Designers, Usability Experts, whatever. It's up to you, but using teams in Launchpad seems impossible to avoid when it comes to be more that one person on a LP-based project