• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Private Projects

Projects can be made private and all subordinate artefacts are also private. Maintainers can grant users and team permission to view all the the project and its contents. Maintainers can grant users and teams permission to view a branch or bug.

This feature is about managing the disclosure of information to ensure companies can develop software without revealing their intentions to rivals. Trusted users and teams, such a company employees have unrestricted access to view all aspects of the project. Clients or developers can be permitted to view specific bugs or branches, revealing only the names of the connected artefacts.

This is a part of the LEP/BetterPrivacy.

Rationale

Canonical is developing a greater number of projects with a greater number of partners. Canonical needs to prevent disclosing its plans to its rivals, and between its partners in cases where they rival each other.

Private projects allow Canonical to control who it shares information with in Launchpad.

Stakeholders

• PES (Steve Magoun, Cody A.W. Somerville)
• Hardware enablement (Chris Van Hoof, Hugh Blemings)
• ISD (Stuart Metcalfe)
• Landscape (???)

• UbuntuOne (???)

• Swift <<commercial example>> (Monty Taylor)

User stories

As a project maintainer
I want hide my project from all users except those I allow
so that development activity are not disclosed to competitors

Constraints and Requirements

Must

1. A way of running projects in total privacy.
   Non-privileged users cannot know the project's name or see anything that belongs to the project.

2. Does not increase LOSAs and commercial admins involvement.
   LOSAs and commercial admins should not take on new responsibilities to manage private projects. Ideally, their current responsibilities or involvement will decrease.

Nice to have

Must not

1. Privacy doesn't matter for almost everything, it must not clutter up the page for public things.
2. Privacy must not add a significant performance penalty.
3. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
4. Privacy must not require elaborate team hierarchies to manage access.
5. Privacy must not prevent company employees from seeing company information.
6. Must not require a DB query to circumvent a black listed name.
7. Private distros are out of scope.

Subfeatures

1. LEP/TrustedPickers

2. LEP/PrivacyTransitions

3. LEP/HardenedBugsProjectsTeams

4. LEP/Entitlement

5. LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.

6. LEP/BugLinking

Workflows

1. Entitling a user to create private projects.
2. Registering a private project.
3. Granting full access to a user or team.
4. Granting partial access to a user or team via a bug or branch.
5. Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
6. Cloning and linking a private project bug to another project.

Success

How will we know when we are done?

1. A non-privileged user cannot see the name or know the URL of a private project.
2. A non-privileged user cannot see private project artefacts like bugs, branches, blueprints, questions, milestones, and series when searching or listing collections.

How will we measure how well we have done?

1. The canonical team is granted access to all Canonical projects.
   This will be knowable via a DB query.

2. All PES and HWE owned projects are private
   We may want to restrict this to new projects or to active projects.

Thoughts?