• 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

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

• LEP/AuditTrail

• Separate ownership from write
• Better management of notifications
• Entitlement to make private "stuff"

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

• 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 [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