= Social private teams =

''Permit private teams to participate in social activities''

'''Contact:''' ''Curtis Hovey (Sinzui)'' <<BR>>
'''On Launchpad:''' ''[[https://bugs.launchpad.net/launchpad/+bugs?field.tag=disclosure+teams&field.tags_combinator=ALL | 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 ==

<<Anchor(story-name>)>>

=== Private team membership in other teams ===

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

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 [[https://bugs.launchpad.net/launchpad/+bug/405277 | Private teams are not able to join other teams (public or private)]]


=== Subscribe private teams to merge-proposals ===

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

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 [[https://bugs.launchpad.net/launchpad/+bug/604831 | private team can't review merge proposals]]


=== Subscribe users to private team branches ===

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

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 [[https://bugs.launchpad.net/launchpad/+bug/605130 | subscribed team cannot view branch owned by (a different) private team]]


=== Private teams in package roles ===

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

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 [[https://bugs.launchpad.net/launchpad/+bug/611617 | private teams cannot be package maintainers]]


=== Private teams bug and blueprint subscriptions ===

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

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

See [[https://bugs.launchpad.net/launchpad/+bug/827902 | 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.

 3. Only permit private team *owners*, *members* and *owners of subteams* to cause disclosure of the private team.

 4. 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 ===

 1. Do not permit private teams to spy. <<BR>> 
 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 <<BR>> 
 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

== Thoughts? ==