Diff for "LEP/PermissionsAndNotifications"

Not logged in - Log In / Register
Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2010-04-22 12:49:02 →
Size: 1556
Editor: jml
Comment:
← Revision 2 as of 2010-04-22 13:10:15 → ⇥
Size: 3792
Editor: jml
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. = Separate permission, notification and ownership =
Line 3: Line 3:
'''''Talk to the product strategist soon after cutting a first draft of this document'''''

= $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]]''		 '''A clear, powerful permission, notification and ownership system for Launchpad.'''
Line 19: Line 7:
''Why are we doing this now?'' In Launchpad right now, for private resources "able to see" and "get told about all changes" are the same thing.
Line 21: Line 9:
''What value does this give our users? Which users?'' Similarly, for all resources, "total ownership" and "ability to write" are the same thing.

Further, we don't have a consistent approach to these things across resources, nor do we have a clear idea of what "resource" is, nor do we have systems for managing privacy across a whole project.

We need to sort this out.

Clearing all of this up will help our users, who are frequently confused by how to control commit access or bug status change access. It will help them organize their projects better, avoiding the massive proliferation of teams that frequently comes with managing a project on Launchpad.

It will also very much help private projects, that currently struggle to manage visibility and live under a constant worry of data being exposed.
Line 25: Line 21:
''Who really cares about this feature? When did you last talk to them?''  * Martin Pool, Bazaar
   * Fully open source project, complex team structure to enable permissions
 * Jamu Kakar, Landscape
   * Open source client, proprietary server
 * OEM Services
   * Totally private projects
   * Steve Magoun
   * Joey Stanford
   * Cody A. W. Somerville
 * ISD, Stuart Metcalfe
   * Initially private projects that are then open sourced. Collaboration across multiple teams.
Line 36: Line 43:
   * Separate visibility from subscription
   * Privacy for distributions and projects
 * Separate ownership from write
 * Better management of notifications
 * Access audit trail
 * Entitlement to make private "stuff"
 * Delete private membership teams
Line 56: Line 70:
''Put everything else here. Better out than in.'' Here's a rough list of the resources that we need to think about when thinking about privacy, permissions etc.

=== Containers ===

 * Team
 * Project
 * ProjectGroup
 * Distribution
 * Series?
 
=== Assets ===

 * Series?
 * Milestones?
 * Recipes
 * Source packages (release?)
 * Binary packages (release?)
 * Build records
 * Blueprints
 * Sprints
 * Questions
 * FAQs
 * Comments?
 * Mailing lists
 * Branches
 * Archives?
 * Merge proposals?
 * Bugs?
 * Tarballs (release files)?
 * Translations?
 * Attachments


== References ==

''Sorry, but many of these links are themselves private.'' -- jml [<<Date(2010-04-22T13:10:15Z)>>]

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

https://bugs.edge.launchpad.net/oem-process/+bug/372797

=== Existing privacy implementations in Launchpad ===

 * Branch privacy
 * Bug privacy
 * P3As

Separate permission, notification and ownership

A clear, powerful permission, notification and ownership system for Launchpad.

Rationale

In Launchpad right now, for private resources "able to see" and "get told about all changes" are the same thing.

Similarly, for all resources, "total ownership" and "ability to write" are the same thing.

Further, we don't have a consistent approach to these things across resources, nor do we have a clear idea of what "resource" is, nor do we have systems for managing privacy across a whole project.

We need to sort this out.

Clearing all of this up will help our users, who are frequently confused by how to control commit access or bug status change access. It will help them organize their projects better, avoiding the massive proliferation of teams that frequently comes with managing a project on Launchpad.

It will also very much help private projects, that currently struggle to manage visibility and live under a constant worry of data being exposed.

Stakeholders

  • Martin Pool, Bazaar
    • Fully open source project, complex team structure to enable permissions
  • Jamu Kakar, Landscape
    • Open source client, proprietary server
  • OEM Services
    • Totally private projects
    • Steve Magoun
    • Joey Stanford
    • Cody A. W. Somerville
  • ISD, Stuart Metcalfe
    • Initially private projects that are then open sourced. Collaboration across multiple teams.

Constraints

What MUST the new behaviour provide?

What MUST it not do?

Subfeatures

  • LEP/BetterPrivacy

    • Separate visibility from subscription
    • Privacy for distributions and projects
  • Separate ownership from write
  • Better management of notifications
  • Access audit trail
  • Entitlement to make private "stuff"
  • Delete private membership teams

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?

Here's a rough list of the resources that we need to think about when thinking about privacy, permissions etc.

Containers

Assets

  • Series?
  • Milestones?
  • Recipes
  • Source packages (release?)
  • Binary packages (release?)
  • Build records
  • Blueprints
  • Sprints
  • Questions
  • FAQs
  • Comments?
  • Mailing lists
  • Branches
  • Archives?
  • Merge proposals?
  • Bugs?
  • Tarballs (release files)?
  • Translations?
  • Attachments

References

Sorry, but many of these links are themselves private. -- jml [2010-04-22]

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

https://bugs.edge.launchpad.net/oem-process/+bug/372797

Existing privacy implementations in Launchpad

  • Branch privacy
  • Bug privacy

  • P3As

LEP/PermissionsAndNotifications (last edited 2011-05-18 12:33:21 by jml)