= Basic Entitlement =
Launchpad does know who should be permitted to create private projects
and teams, nor does it know who should be permitted to configure
privacy. Users (and organisations) rely on Launchpad's Admins to do this.
Since it is not obvious that users must ask for privacy features, users
and organizations are disclosing proprietary information. It might take
several days to configure privacy and can cost organisations millions
in contracts.
'''Contact:''' Curtis <
>
'''On Launchpad:''' [[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=disclosure+entitlement&field.tags_combinator=ALL| disclosure + entitlement]]
== Rationale ==
Confidential information is disclosed when a user is not intricately
familiar with Launchpad's privacy features. They were not designed for
users to create and configure, so without the assistance of an Launchpad
Admin, there is a tremendous amount of risk of starting a private project.
Canonical staff disclosed confidential information several times in 2011
because Launchpad did not permit them to do their job.
While Launchpad does not know who should be permitted to have commercial
features enabled, Launchpad Admins apply a few rules to determine
entitlement that might be codified.
== Stakeholders ==
* PES
* Steve Magoun
* Cody A.W. Somerville
* Hardware enablement
* Chris Van Hoof
* Linaro
* Kiko
* ISD
* Stuart Metcalfe
* Swift <>
* Monty Taylor
== User stories ==
<)>>
'''As a ''' member of team associated with an organisation<
>
'''I want ''' to create projects and teams with my organisation's name<
>
'''so that ''' It is clear who owns the project or team.
'''As a ''' member of Canonical<
>
'''I want ''' to create a private team<
>
'''so that ''' I can start work immediately.
'''As a ''' maintainer of a commercial project<
>
'''I want ''' to configure default private bugs<
>
'''so that ''' my proprietary data is not disclosed.
'''As a ''' maintainer of a commercial project<
>
'''I want ''' to configure default private branches<
>
'''so that ''' my proprietary data is not disclosed.
== Constraints and Requirements ==
These rules come from the common questions asked by Launchpad Admins to
decide when to create or configure commercial features.
A commercial project with a current commercial subscription.
An organizational team is one that is considered to be the owner of a
space.
=== Must ===
* Members of an organisation (represented by a team) may create projects
and teams with the organisations blacklisted name.
* Maintainers and drivers must be permitted to enable default private
bugs and branches if the project has a commercial subscription.
* Users who maintain a commercial project may create private teams.
* Users who maintain a commercial project may configure private PPAs.
=== Nice to have ===
* Launchpad could make it easier to get a commercial subscription so that
it is easier setup private features.
* Launchpad could identify Canonical owned projects and extend the
commercial subscription to after the year 2020.
=== Must not ===
* Do not allow a non-commercial project to enable commercial features.
* Do not allow non organisational users to create or rename projects
using the organization's name.
* Do not allow non-organisational users to create private teams or PPAs.
* Do not expose users to the arcane BranchVisibilityPolicy because the
notion that teams get private branches, not projects, is orthogonal to
what users want to do. Branch multi-tenancy is no longer supported.
=== Out of scope ===
* Expedited Commercial Subscription purchasing process.
* A New project registration process that integrates purchases though the
Canonical store.
* Private PPA owners may not access the same features as Launchpad Admins.
== Subfeatures ==
* Automatically award 30-day commercial subscriptions to projects when
they choose a proprietary license.
* Send out commercial subscription expiration notifications.
* Deactivate commercial projects or commercial features as needed.
== Success ==
We want Canonical staff to Confidentially work on Launchpad. A good
entitlement solution will work with any organisation/group with a
commercial project.
=== How will we know when we are done? ===
* A Canonical employee can create a teams named ~canonical-xxx
* A Canonical employee can create a private team
* A Canonical employee can create a project, state it is Canonical or
proprietary and the project is awarded a commercial subscription.
* A Canonical employee can configure private bugs.
* A Canonical employee can configured private branches.
* A ~pmteam member (not Cody) can register a PES project and configure
private bugs.
=== How will we measure how well we have done? ===
* More than one ~pmteam member can create and configure PES projects.
1 person can do this, but all members are responsible for doing this.
* Reduce the number of support requests to configure projects each month.
* Reduce the time it takes to configure a private project from days to
minutes.
* Reduce the number of incidences where confidential information is leaked
while a project is being setup. Better still, end all leaks.
== Thoughts? ==
If commercial subscriptions are automatically awarded, then a mechanism
is needed to notify and handle expiration so that the maintenance
burden does not increase.