Affiliations

Blueprint: Project/Team Affiliations

Launchpad has projects (née products) that are a central organizing principle for open source development, bringing together bugs, code, translations, answers, etc. Projects are the seeds around which communities in Launchpad grow.

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 people/teams and the projects they revolve around. It can therefore often be difficult for an interested user to find the person they need to communicate with, or the team they want to join in order to participate more fully in a project's development.

This spec addresses this problem by introducing affiliations, a way for teams and people 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 people and teams controlling them. Ultimately though, because these relationships are not explicit, this is all left to luck, chance, and The Googles.

Similarly, you might have a fantastic idea for improving the user interface for a web application, or you have a branch of code that fixes an obscure bug, and you'd like to get it reviewed and merged into the project's mainline. You can usually find a person who is involved with the project, bug can you always find the right person? Maybe you want to contact the lead architect, or the user interface designer, or the documentation guru, or the BDFL. Launchpad doesn't provide a way to designate these arbitrary community-recognized roles.

Wouldn't it be nice if a project owner could link specific people and teams with the project? Wouldn't it be nice if relationships between people/teams and their projects could be described in terms that make sense to, and have been agreed upon by, the project's community? Wouldn't it be nice if, on the project page you could see a list of related people and teams, and know exactly who was in charge of documentation, or the web site design, or wiki gardening, or internationalization? Similarly, from a person or team's, would you like to see a link to their related projects?

Making these relationships, which often already exist implicitly, explicit and easily discovered opens up a new world of collaboration on Launchpad. For users looking to participate in the project, there's much less guesswork in finding the channels for this participation.

These relationships that people and teams can have with a project model that project's community of contributors. By allowing us to specify and describe the affiliations between people/teams and projects, we can capture arbitrary community structure without imposing a rigid semantic on this structure. We let communities self-organize, evolving from small projects with individual people in key roles, to large, complex, and mature projects with teams filling many of those same roles.

Data model

To support affiliations, two key concepts (and their associated tables) are proposed for adding to the Launchpad data model. These tables support the optional links between people/teams and projects, and the descriptions of these affiliations.

The first proposed table is PersonAffiliation. This table contains a link to a Person and a link to a PillarName. By linking to PillarName we allow for affiliations to projects, project groups (née projects) and distributions, although for the first cut we will support only projects.

The PersonAffiliation table contains a creation date for the affiliation and a status (see below). It also contains a link to the AffiliationDescription table.

AffiliationDescription is the second proposed table, and this contains a link back to its PillarName, along with a text description, a creation date and a priority. By assigning a priority, we can sort the affiliation descriptions when displaying them on a project's home page. For example, for the Python project you might have the following affiliation descriptions and priorities:

|description|priority| |BDFL|1000000| |Release manager|1000 |Platform guru|200| |Documentation guru|150| |Core developer|50|

On the Python project page, we'd display those affiliations in the order of decreasing priority, with alphabetical sorting for duplicates.

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 the ways they can participate in the project.

• Add a TeamPillarAffiliation table containing at least these columns:

  • pillar

  • team

  • status (enum: Proposed, Rejected, Accepted)

• Add to ITeam interface and `Person content object, a project_affiliation attribute.

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

Note:

• For now, teams cannot be affiliated with project groups or distributions. In the future, we may add this.

Story points: 2

View project affiliation

As a Launchpad user
I would like to be able to view the project affiliations 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, including teams that are implicitly affiliated, e.g.
  • answer contact
  • bug contact
  • driver
  • maintainer
• Implicit affiliations, as well as those that have been accepted by the team

  owner are listed as official with a special icon.

• Teams are displayed with their name and description, with links to the team's index page.

Notes:

• Sub-teams do not show up as affiliated even when their super team is affiliated.

Story points: 2

Add affiliation

As a project owner
I would like to be able to propose a team affiliation
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 propose an affiliation of the team to one of their projects.

• If the project owner is also the team owner, the affiliation is immediately accepted.
• If the project owner is not the team owner, an email message is sent to the team owner informing them of the proposed affiliation. While this proposal is pending, the team still shows up on the project page's affiliations list,

  but without the official badge.

• The team owner can click on the link in their email to accept or reject the

  affiliation proposal. If accepted, the team is made official. If rejected, then the affiliation is removed and it's as if it was never made.

Notes:

• 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

Remove affiliation

As a project or team owner
I would like to be able to break a team affiliation
So that it is clear there is no longer a relationship between the team and the project.

• A project owner can go to a team page to break that team's affiliation with the project. In this case, the affiliation is immediately removed and an email notification is sent to the team owner (if the project owner is not also the team owner).
• A team owner can go to the team page to break the team's affiliation with the project. In this case, if the team owner is also the project owner then of course the affiliation is removed immediately. If not, then the

  affiliation is made unofficial and an email notification is sent to the project owner.

Notes:

• You must break an existing affiliation before you can reassign it.

Open questions

• TBD