launchpad development
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 can 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
- Allow private teams to be in roles that facilitate member communication
- Reduce the maintenance burden caused by managing multiple teams or memberships/subscriptions of team members.
- Only permit private team *owners*, *members* and *owners of subteams* to cause disclosure of the private team.
- Never disclose the private team without warning - warn members that placing their private team in a role of a public
artefact will make the team name and displayname know.
Must not
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.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/404 error looking at
public pages
