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: 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 <<Commercial example>>
- 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.