Social private teams

Permit private teams to participate in social activities

Contact: Curtis Hovey (Sinzui)
On Launchpad: Bug tags:disclosure+teams

Rationale

When we create private projects, users will want private teams to be in the project or artefact roles. The current implementation explicitly forbids private teams from being in some team or artefact role such as member or subscriber.

If the restrictions are not revised, public teams will be placed in these roles. This situation invites opportunities to disclose information, and will require people to maintain public and private teams with identical membership. The latter issue is already a burden for organisations because private teams cannot join other teams--private projects will exacerbate the situation.

Stakeholders

OEM IDS Linaro U1 Design Ubuntu

User stories

Private team membership in other teams

As a private team admin
I want I want to make my team a member of another team
so that the private team members are granted permissions and some social benefits in the other team

When a public team is in a project role, private team admins cannot add their team, even if the user admins both teams. Since project roles convey permissions that are needed to participate in a project, team admins often manage users in both teams instead of just one. Many communities require several levels of nested teams, which is a great burden on private team admins.

See Private teams are not able to join other teams (public or private)

Subscribe private teams to merge-proposals

As a member of private team
I want I want my private team to review my branch
so that all members of the private team are notified.

Private teams are not permitted to be subscribed to MPs even though they can be subscribed to branches. The team members cannot participate in all branch discussions and events.

See private team can't review merge proposals

Subscribe users to private team branches

As a private team admin
I want I want to subscribe a non-team member to my team's branch
so that the branch can be reviewed

This case is inverted from the common reasons cited to change private team restrictions. This case is similar to the case where users may subscribe to P3A owned by private teams. A private team may exist to create code, but it may submit it's branches to public projects. The P3A subscribers are granted access to all aspects of the private team, which is undesirable.

See subscribed team cannot view branch owned by (a different) private team

Private teams in package roles

As a private team member
I want I want to upload a package using my team's identity
so that it is clear who uploaded/maintains the package.

This issue is rare in in that it only affects PPAs, but is expected to be a common problem with private distros where most of the teams could be private and will upload to the distro archive.

The ppa case is a nonsensical issue; the private team owns the archive. having someone else listed as the maintainer would look very wrong if the user leaves the team.

See private teams cannot be package maintainers

Private teams bug and blueprint subscriptions

As a private team member
I want I want to subscribe my team bugs and branches
so that the team members get notification and access permission.

Private team members cannot only participate in notifications if someone subscribes each individual.

See Private teams not able to subscribe to bugs or blueprints for email updates

Constraints and Requirements

Must

1. Allow private teams to be in roles that facilitate member communication

2. Reduce the maintenance burden caused by managing multiple teams or memberships/subscriptions of team members.

Nice to have

1. Warn members that placing their private team in a role of a public artefact will make the team name and displayname know.

Must not

1. Do not permit private teams to spy.
Private team subscriptions must reveal the name and displayname of the private team to ensure that the team is not used to spy on projects. Without the revelation, there would be no means for users to verify what was automatically disclosed to whom before something is made private or security.

2. Do not hide the team name when it is a public role
When a private team is in a public role like maintainer, users need to know who this is. While the private team could have a nonsensical name, it is unique, thus cannot be impersonated. The obfuscated team name does not convey trust, and it an opportunity for man-in-the-middle attacks where ambiguous or deceptive names are used to mislead users to reveal information.

Out of scope

This is not about redesigning private teams. This feature is about reducing restriction places on private teams. In many cases this involves removing code and verifying that errors do not occur because secondary and tertiary objects will interact with private teams.

Subfeatures

None

Success

How will we know when we are done?

* Private organisational teams like ISD can join other teams. * Private teams can subscribe to bugs, blueprints, and merge proposals. * User can be subscribed to private team branches and merge proposals. * Non-private team members know the name of the private team that owns or drives a project.

How will we measure how well we have done?

* Measure the number of private teams that are members of other teams to learn how many groups saw this as an advantage. * Measure the number of users in private teams in an indirect membership to learn how many dual memberships are reduced. * Measure the number of private teams in blueprint, bug, and merge proposal subscriber roles. * Watch Answers and Bugs for reports about unwanted disclosure of information. * Watch the oops reports and Bugs for reports about 403 error looking at public pages

Thoughts?