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 a team to (optionally) specify which project they are associated with.

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 (optionally) link specific teams with the project? Then on the project page you would see an explicit 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 foreign key link from team (really Person) to project (sorta really Product). This is a database schema change.

Open questions:

• It certainly makes sense for a project to have more than one related team. Think foo-users, foo-dev, foo-announce, foo-bugs, foo-commits, etc. Does it make sense for a team to be related to more than one project? I think this will not be a common use case and would say "no", although one way to work around that would be through the use of 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.

Stories

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

Project affiliation for teams

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.)?