Project Affiliation

Blueprint: Project/Team Affiliations

Launchpad has projects (formerly known as products) that are the central organizing object for an open source application, bringing together bugs, code, translations, answers, etc.

Launchpad also has teams, which are ways to organize the people who want to be involved in a project. Teams are used in some cases to control access to project artifacts (e.g. private bugs, code branches) and as a forum for audiences that want to participate in the project (e.g. mailing lists).

The problem is that there is no association between teams and the projects they revolve around. It can therefore often be difficult for an interested user to find the team they want to join in order to participate in a project.

This spec addresses this problem by introducing project affiliations, a way for teams to be (optionally) associated with a specific project.

Rationale

How often have you gone to a project page and wondered what teams exist that relate to this project? When you're looking for a way to participate, you naturally want to find the related teams and mailing lists, but this is currently fairly difficult. If the teams share a name with the project, you might get a lucky guess. Or your search might turn up something useful. Or you might be able to follow the obscure trail from various project artifacts and permissions to the teams controlling them. Ultimately though, because these relationships are not explicit, this is all left to luck, chance, and The Googles.

Wouldn't it be nice if a project owner could link specific teams with the project? Then on the project page you would see an list of related teams. Similarly, from the team page, you would see a link to the related project. This makes these relationships (which already exist implicitly) explicit and easily discovered. As a new user looking to participate in the project, there's much less guesswork in finding the channels for this participation.

Data model

We will provide for optional links between teams and projects.

It is proposed that we create a new table called TeamPillarAffiliations which link a team (really a Person) to a pillar. For the first cut, we'll support only projects but in the future we should at least also support project groups and possibly distributions as well.

Notes:

• We considered allowing for many-to-many relationships, but for now we're going to limit this so that a single team can only be affiliated with one project. A project can have many teams affiliated with it. Think foo-users, foo-dev, foo-announce, foo-bugs, foo-commits, etc. Should we need to support a team being affiliated with multiple projects, probably the most common use case would be to allow for affiliation with project groups.
• It must be possible to create the link between team and project after the fact. Should it be possible to do from both a project page and a team page? I think the u/i for the latter is easier, but both present interesting challenges. Further, the approval model works better if it is always the project owner initiating affiliation.

Stories

Here then are some stories for breaking down the work and estimating their level of effort.

Project affiliation for teams

As a project owner
I would like to be able to affiliate a team with a project
So that it is easier for people to discover this relationship, and discover the ways they can participate in the project.

As a team owner, I would like to be able to affiliate my team with a project so that it is easier for me and others to discover this relationship and learn how to participate in the project.

• Add to Person table a project_affiliation foreign key column.

• Add to IPerson interface and Person content object a project_affiliation attribute, settable only for teams.

• Add method to IProduct to query for and return the set of affiliated teams.

Open questions:

• Should it be possible to associate a team with many projects? Do we need an association table? Recommendation: no.

Story points: 2

View project affiliation

As a Launchpad user I would like to be able to view the project affiliation for a team, so that I can more easily decide how I want to participate in the project.

• On the team index page, add a link to the affiliated project.
• On the project index page, add a section listing all the teams that are
  • affiliated with the project.

Story points: 2

Edit project affiliations

As a project or team owner, I would like to be able to make and break links from project to teams, so that I can more clearly communicate to users what these relationships are.

• When a project owner visits any team page, they see an action called "Affiliate with project". Clicking on this action takes them to a page with a pull down menu containing a list of all the projects they own. They can then affiliate the team to one of those projects. Or, if this team is already affiliated with a project, they see a form that allows them to break that affiliation.
• Should it be possible to create this link from the project page? If so, you clearly can't see every team on LP. I guess you could give them an edit box with the pop up to select a team name. Or you could just prompt them with all the teams they own. I think the u/i is problematic in this case.

Story points: 5

Open questions

• Do you need approval from both the project owner and the team owner to create this affiliation? If so, this definitely complicates the database model.
• It's easy to create teams (no approval is necessary), but harder to create projects, because those are reviewed. Should we allow only project owners to create these affiliations so as to reduce the temptation for affiliation-spam?
• Should we assume the worst and have some kind of affiliation work flow? Or do we assume the best and allow these to be made, knowing they are easy to make and break?
• Should we send an email notification to both the team and project owner when an affiliation is made or broken?
• Do you have to break an affiliation before reassigning it?
• Do sub-teams show up as affiliated if their super-team is affiliated with a project?
• What about project groups? The thought is that the use case of a single team being affiliated with multiple groups is largely covered by allowing affiliations with project groups. Should this spec include project group affiliations or leave that for now as an uncommon use case?
• How does this fit into Curtis's plan for team roles? If/when we ever get team roles would that subsume this role-agnostic affiliation? Should the list of affiliated teams be deduced from existing links (bug contact, branch reviews, etc.)?