launchpad development|
⇤ ← Revision 1 as of 2010-04-21 14:20:45
Size: 1603
Comment:
|
Size: 4976
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| The purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess. | SCOPE: * Privacy * Permission management * Notification * "Ownership" |
| Line 3: | Line 7: |
| '''''Talk to the product strategist soon after cutting a first draft of this document''''' | = Better Privacy = |
| Line 5: | Line 9: |
| = $HEADLINE = ''Short description of feature'' '''As a ''' $PERSON<<BR>> '''I want ''' $FEATURE<<BR>> '''so that ''' $BENEFIT<<BR>> ''Consider clarifying the feature by describing what it is not?'' ''Link this from [[LEP]]'' |
|
| Line 19: | Line 12: |
| ''Why are we doing this now?'' | Canonical's internal business relies more on Launchpad each day. Much of this business ''must'' be conducted in private. Launchpad currently provides some of what Canonical needs, but not all. What it does provide is often inconsistent and hard to understand. These inconsistencies increase the chance of privacy leaks, which could do irreparable harm to our business. |
| Line 21: | Line 18: |
| ''What value does this give our users? Which users?'' | |
| Line 25: | Line 21: |
| ''Who really cares about this feature? When did you last talk to them?'' | * OEM Services * Joey Stanford (February 2010?) * Steve Magoun (February 2010?) * Ubuntu One * ??? * ISD * Stuart Metcalfe * Landscape |
| Line 30: | Line 33: |
A way of running projects in total privacy. e.g. Any OEM project (note these are often better expressed as distributions) A way of running software projects that have public client components and proprietary server components e.g. Landscape, Ubuntu One A way of running projects that do much of their work in private, but do some in public. e.g. code is closed but bugs can be filed A way of sharing access to private projects across other teams e.g. initial openid provider work A way that allows anyone to ask a question, but for that question to be kept private initially. (The UX team asked for this, but jml can't recall why) Need logs of who has accessed private stuff in case of privacy breach Only people who pay us can get privacy * No tiered payment system yet -- out of scope Security bugs, security branches, security patches etc??? Privacy settings must be easy to change ''But'' making "accidental" mistakes has to be hard Minimal on-going developer burden Minimal on-going LOSA burden An intern should be able to control this Privacy doesn't matter for almost everything, it should not clutter up the page |
|
| Line 56: | Line 95: |
| ''Put everything else here. Better out than in.'' | Useful to distinguish between containers (e.g. project, distro) and artifacts (e.g. bugs, code)? We have a bit of a mess right now on hiding completely (e.g. raising a 404) and denying access (e.g. raising a 403). The "team exists across all projects" thing is going to confuse people OEM people are confused by the fact that a team exists across project. Why can't you create a team which only makes sense within a team. Team privacy and project privacy are orthogonal. Useful for use cases like DX, but less useful of OEM. Standard way of showing a link to a private object * when you cannot see it? * when you ''can'' see it? What are our encryption requirements? What are our legal requirements? Probably need to have a "GRANT" permission or something similar Prior art in web ACLs? What about projects that go open source? What about projects that go closed source? Might be necessary to distinguish between READ access and VIEW ACL accces. Ask OEM how important this is? Really convulated for the bug case. Hypothesis is that ACL system is distinct from the subscription levels. * Probably want to do clever thing like automatically grant access when subscribing. === Containers === * Team * Project * ProjectGroup? * Distribution * Private project/distribution means that everything related to that object should be private. * Privacy support at the asset level * Must allow be able to override the . * === Assets === * Series? * Milestones? * Recipes? * Source packages * Binary packages * Build records * Blueprints * Questions * FAQs? * Comments? * Mailing lists * Branches * Archives? * Merge proposals? * Bugs? * Tarballs? * Translations? * Attachments == References == https://wiki.canonical.com/Launchpad/PrivacyFeatures https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=privacy https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=p3a https://bugs.edge.launchpad.net/malone/+bugs?field.tag=oem-services https://bugs.edge.launchpad.net/malone/+bug/388084 => jml, talk to OEM a bit more * how important? * how common? * involve the bugs team == Actions == |
SCOPE:
- Privacy
- Permission management
- Notification
- "Ownership"
Better Privacy
Rationale
Canonical's internal business relies more on Launchpad each day. Much of this business must be conducted in private. Launchpad currently provides some of what Canonical needs, but not all. What it does provide is often inconsistent and hard to understand. These inconsistencies increase the chance of privacy leaks, which could do irreparable harm to our business.
Stakeholders
- OEM Services
- Joey Stanford (February 2010?)
- Steve Magoun (February 2010?)
- Ubuntu One
- ???
- ISD
- Stuart Metcalfe
- Landscape
Constraints
What MUST the new behaviour provide?
A way of running projects in total privacy.
- e.g. Any OEM project (note these are often better expressed as distributions)
A way of running software projects that have public client components and proprietary server components
- e.g. Landscape, Ubuntu One
A way of running projects that do much of their work in private, but do some in public.
- e.g. code is closed but bugs can be filed
A way of sharing access to private projects across other teams
- e.g. initial openid provider work
A way that allows anyone to ask a question, but for that question to be kept private initially. (The UX team asked for this, but jml can't recall why)
Need logs of who has accessed private stuff in case of privacy breach
Only people who pay us can get privacy
- No tiered payment system yet -- out of scope
Security bugs, security branches, security patches etc???
Privacy settings must be easy to change
But making "accidental" mistakes has to be hard
Minimal on-going developer burden
Minimal on-going LOSA burden
An intern should be able to control this
Privacy doesn't matter for almost everything, it should not clutter up the page
What MUST it not do?
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
Workflows
What are the workflows for this feature? Provide mockups for each workflow.
You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.
Success
How will we know when we are done?
How will we measure how well we have done?
Release Note
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. It is mandatory.
Thoughts?
Useful to distinguish between containers (e.g. project, distro) and artifacts (e.g. bugs, code)?
We have a bit of a mess right now on hiding completely (e.g. raising a 404) and denying access (e.g. raising a 403).
The "team exists across all projects" thing is going to confuse people
- OEM people are confused by the fact that a team exists across project. Why can't you create a team which only makes sense within a team.
Team privacy and project privacy are orthogonal. Useful for use cases like DX, but less useful of OEM.
Standard way of showing a link to a private object
- when you cannot see it?
when you can see it?
What are our encryption requirements?
What are our legal requirements?
Probably need to have a "GRANT" permission or something similar
Prior art in web ACLs?
What about projects that go open source?
What about projects that go closed source?
Might be necessary to distinguish between READ access and VIEW ACL accces. Ask OEM how important this is? Really convulated for the bug case.
Hypothesis is that ACL system is distinct from the subscription levels.
- Probably want to do clever thing like automatically grant access when subscribing.
Containers
- Team
- Project
- Distribution
- Private project/distribution means that everything related to that object should be private.
- Privacy support at the asset level
- Must allow be able to override the .
Assets
- Series?
- Milestones?
- Recipes?
- Source packages
- Binary packages
- Build records
- Blueprints
- Questions
- FAQs?
- Comments?
- Mailing lists
- Branches
- Archives?
- Merge proposals?
- Bugs?
- Tarballs?
- Translations?
- Attachments
References
https://wiki.canonical.com/Launchpad/PrivacyFeatures https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=privacy https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=p3a https://bugs.edge.launchpad.net/malone/+bugs?field.tag=oem-services
https://bugs.edge.launchpad.net/malone/+bug/388084
=> jml, talk to OEM a bit more
- how important?
- how common?
- involve the bugs team
