launchpad development|
Size: 6354
Comment:
|
Size: 3997
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Private Projects and Distributions = | ## page was renamed from LEP/PrivateProjectsAndDistributions = Private Projects = |
| Line 3: | Line 4: |
| Projects and distributions can be made private and all subordinate artefacts are also private. Owners can grant users and team permission to view all the the project and its contents. Owner can grant users a teams permission to |
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 |
| Line 7: | Line 8: |
'''As a ''' project owner<<BR>> '''I want ''' hide my project from all users except those I allow<<BR>> '''so that ''' development activity are not disclosed to competitors<<BR>> |
|
| Line 28: | Line 25: |
| Private projects and distros allow Canonical to control who it shares | Private projects allow Canonical to control who it shares |
| Line 34: | Line 31: |
| * OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville) | * PES (Steve Magoun, Cody A.W. Somerville) |
| Line 37: | Line 34: |
| * Landscape (Jamu Kakar) * UbuntuOne (Matt Griffin) |
* Landscape (???) * UbuntuOne (???) * Swift <<commercial example>> (Monty Taylor) == User stories == <<Anchor(projects)>> '''As a ''' project maintainer<<BR>> '''I want ''' hide my project from all users except those I allow<<BR>> '''so that ''' development activity are not disclosed to competitors |
| Line 50: | Line 55: |
| 1. A way of managing who can view a private project/distribution.<<BR>> Owners can grant users and teams permission to access and view all parts of the project. [[LEP/ManagingDisclosure]] 1. Owners can see all the user that have full access to the project. 1. Owners can revoke access for a user or a team. 1. This applies to '''private and public projects''' 1. A way to granting users and teams access to bugs and branches. <<BR>> Owners can grant users and teams access to a bug or branch and trust that the users can only learn the names of the things connected to it. 1. Always remind users that the information is confidential. <<BR>> When viewing the page of something that is private (either because it is private or the project/distro that is belongs to), the user can always '''see''' and '''know''' that they are responsible for not revealing the information to Non-privileged users. 1. Does not let users easily disclose project information <<BR>> Launchpad must guard how private artefacts are linked to public artefacts. 1. It must not be possible to grant permission or assign to a public team. 1. Launchpad must explain that assigning something like a blueprint to a non-privileged user will disclose information. Maybe assigning is not possible until permission is granted. 1. Artefacts like blueprints, bugs, and questions cannot be retargeted to another project. 1. Bugs cannot be shared (ie, multiple BugTagets) because that can disclose information in comments. [[LEP/BugLinking]] |
|
| Line 81: | Line 57: |
| manage private projects and distros. Ideally, their current responsibilities | manage private projects. Ideally, their current responsibilities |
| Line 86: | Line 62: |
1. Entitled users can create their own private projects and distros. <<BR>> Commercial admins can create and manage private contexts/artefacts now. Canonical stakeholders could do this themselves to ensure projects are procured quickly and minimize the involvement of commercial admins. 1. An intern can understand how to manage a private project. <<BR>> A good design will convey the what is private, how mange disclosure, and inform about the consequences of a change so that little experience is needed to use privacy. |
|
| Line 105: | Line 71: |
| 1. Privacy must not require recipes to configure projects and distros. | 1. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI. |
| Line 113: | Line 79: |
| 1. Private distros are out of scope. | |
| Line 117: | Line 85: |
| 1. [[LEP/TrustedPickers]] 1. [[LEP/PrivacyTransitions]] 1. [[LEP/HardenedBugsProjectsTeams]] 1. [[LEP/Entitlement]] |
|
| Line 120: | Line 96: |
| 1. [[LEP/BugLinking]] Cloning and linking a private project bug to another project. |
1. [[LEP/BugLinking]] |
| Line 126: | Line 102: |
| 1. Entitling a user to create private projects and distros. | 1. Entitling a user to create private projects. |
| Line 128: | Line 104: |
| 1. Registering a private project or distro. | 1. Registering a private project. |
| Line 144: | Line 120: |
| 1. An entitled user can register a private project or distribution. 1. The owner can grant access to to his company team so that everyone can view the entire project, including private bugs and code on public projects. 1. An owner/driver can subscribe a user to a branch or bug to grant access only to that item. 1. An owner can view the list of granted users, and in a single action, revoke access. |
|
| Line 157: | Line 121: |
| project or distribution. | project. |
| Line 169: | Line 133: |
| 1. All OEM and HWE owned projects are private <<BR>> | 1. All PES and HWE owned projects are private <<BR>> |
| Line 174: | Line 138: |
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
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.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
- Privacy doesn't matter for almost everything, it must not clutter up the page for public things.
- Privacy must not add a significant performance penalty.
- Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
- Privacy must not require elaborate team hierarchies to manage access.
- Privacy must not prevent company employees from seeing company information.
- Must not require a DB query to circumvent a black listed name.
- Private distros are out of scope.
Subfeatures
LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
Workflows
- Entitling a user to create private projects.
- Registering a private project.
- Granting full access to a user or team.
- Granting partial access to a user or team via a bug or branch.
- Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
- Cloning and linking a private project bug to another project.
Success
How will we know when we are done?
- A non-privileged user cannot see the name or know the URL of a private project.
- 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?
The canonical team is granted access to all Canonical projects.
This will be knowable via a DB query.All PES and HWE owned projects are private
We may want to restrict this to new projects or to active projects.
