Diff for "LEP/Sharing"

Not logged in - Log In / Register
Differences between revisions 1 and 13 (spanning 12 versions)
⇤ ← Revision 1 as of 2010-10-11 19:44:03 →
Size: 3984
Editor: sinzui
Comment:
← Revision 13 as of 2012-06-26 17:17:25 → ⇥
Size: 6974
Editor: sinzui
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Managing Disclosure = ## page was renamed from LEP/ManagingDisclosure
= Sharing =
Line 3: Line 4:
Project and distribution owners can grant or revoke user and team permissions
to access all private artefacts.		 Project and distribution owners can share and unshare restricted/private
data with users and teams.
Line 6: Line 7:
'''As a ''' project owner<<BR>>
'''I want ''' grant users and teams permission to see everything<<BR>>
'''so that ''' they do not need many subscriptions to access parts of
the project.<<BR>>		 Project and distribution owners need to see who restricted information
about their project is shared with.
Line 11: Line 10:
Project and distributions owners need to see who can access all or some of
their project. Owners need to grant and revoke access.

[[PrivateProjectsAndDistros]]		 [[PrivateProjectsAndDistributions]]
Line 20: Line 16:
way give access to hundreds of private project artefacts. way give share to hundreds of private project artefacts.
Line 22: Line 18:
This allows stakeholders to know who has access, and in a single action,
grant or revoke it. This is valuable to public project with default private
bug and branches--once a company team is granted access, all employees have
access to company information.		 Stakeholders need to know who they are sharing with, and in a single action,
share more or unshare. This is valuable to public project with default private
bug and branches--once restricted data is shared with a company team, all
employees have access to company information.

e.g. Steve Magoun from OEM would like to be able to see exactly who has access
to every component in his project.
Line 33: Line 32:
 * Landscape (Jamu Kakar)
 * UbuntuOne (Matt Griffin)		  * Landscape (???)
 * UbuntuOne (John Lenton)

== User stories ==

<<Anchor(commercial-stories)>>
=== Commercial stories ===

'''As a ''' commercial project owner<<BR>>
'''I want ''' to mark some data as proprietary that should not be shared with other projects<<BR>>
'''so that ''' information provided in confidence is not disclosed<<BR>>

'''As a ''' commercial project owner<<BR>>
'''I want ''' share proprietary information with users and teams<<BR>>
'''so that ''' my organisation and contractors can collaborate<<BR>

<<Anchor(canonical-stories)>>
=== Canonical stories ===

'''As a ''' member of ~canonical<<BR>>
'''I want ''' to share everything proprietary data in my project with ~canonical<<BR>>
'''so that ''' that members of my organisation are not blocked from collaborating<<BR>

'''As a ''' member of IS<<BR>>
'''I want ''' to add a new employee to the ~canonical team<<BR>>
'''so that ''' that he has access to all information shared with ~canonical<<BR>

'''As a ''' member of IS<<BR>>
'''I want ''' to run remove all things shared with a former Canonical member in Canonical projects<<BR>>
'''so that ''' that confidential data is not disclosed<<BR>


<<Anchor(oem-stories)>>
=== OEM stories ===

'''As a ''' maintainer of OEM projects (~pmteam)<<BR>>
'''I want ''' to share everything with ~oem-dev (the driver)<<BR>>
'''so that ''' they I can delegate all development to them<<BR>>

'''As a ''' driver OEM projects (~pmteam)<<BR>>
'''I want ''' to share some bugs and branches with a contractor<<BR>>
'''so that ''' he can fix the issues for us<<BR>>

'''As a ''' maintainer of OEM projects (~pmteam)<<BR>>
'''I want ''' to see all users who have some things shared with them<<BR>>
'''so that ''' I can share nothing with them if they are not under contract<<BR>>


<<Anchor(ubuntu-stories)>>
=== Ubuntu stories ===

'''As a ''' the maintainer of Ubuntu<BR>>
'''I want ''' to unshare user-data with maintainer and share user-data with the apport bot<<BR>>
'''so that ''' no human has access to personal user-data<<BR>

'''As a ''' the maintainer of Ubuntu<BR>>
'''I want ''' to unshare security with maintainer and share user-data ~ubuntu-security<<BR>>
'''so that ''' only trusted experts see security issues<<BR>>
Line 41: Line 96:
 1. A lists of all the users with full or partial access. <<BR>>
 The view must also show how the user has access: direct or via a team,
 contributor or user, subscription to artefacts or access to project.		  1. A lists of all the users with all or some things shared. <<BR>>
 The view must also show exactly ''how'' the user has access, for example: directly or via a team;
 as a (core?) contributor or as a user; by subscribing to some artefacts or through access to the whole project.
Line 46: Line 102:
 The view must also show how the user has access: direct or via a team.  The view must also show how the user was shared: direct or via a team.
Line 48: Line 104:
 1. A way to grant a user or team full access to a project.<<BR>>
 When a owner grants access to a team, the view should show who gains access.		  1. A way to share everything with a user or team.<<BR>>
 When a owner shares with a team, the view must show who who is being
 shared with and how many members (person-picker).
Line 51: Line 108:
 1. A way to revoke all access to a user or team. <<BR>>  1. A way to unshare everything with a user or team. <<BR>>
Line 55: Line 112:
 remove either the user or the team to revoke permissions.  remove either the user or the team to unshare.
Line 60: Line 117:
 1. A way to see how the user knows about the project. <<BR>>
 Owners often want to know if the user has email subscriptions to understand
 if the user is getting information via email too.

 1. List the users who have full access via the owner or driver team. <<BR>>		  1. List the users who everything is shared via the owner or driver team. <<BR>>
Line 66: Line 119:
 owner can revoke access to an owner/driver, then the user must be removed  owner can unshare with an owner/driver, then the user must be removed
Line 68: Line 121:
Line 72: Line 124:
 1. Revoking a user or team not allow the user to have partial access.<<BR>>  1. Unsharing with a user or team must not allow the user to have some things shared.<<BR>>
Line 76: Line 128:
 1. Granting access must not cede control of disclosure.<<BR>>
 Public teams may not be direct or indirect members of a private project.
 Open teams allow anyone to choose to become a member, which undermines the
 owner's power to manage disclosure.		  1. Sharing must not cede control of what is shared.<<BR>>
 Inclusive teams (open and delegated) may not be shared with.
 Inclusive teams allow anyone to choose to become a member, which undermines the
 owner's power to manage the information disclosure.
Line 84: Line 136:
None  1. Replace bug and branch privacy mechanism with a common way classify the data
    * private and security/branch visibility do not interact with each other
    or meet the needs of sharing all of a kind of restricted data.
    * Use Public, Unembargoed Security, Embargoed Security, User data
    to describe the existing kinds of privacy
 1. Introduce the Proprietary kind of privacy that is not multi-tenant.
 1. Introduce a choice picker that support descriptions with the terms.
Line 89: Line 147:
 1. Viewing a list of users and a summary of an single user.  1. Viewing a list of users that the project is shared with
 and a summary for a single user when some things are shared.
Line 91: Line 150:
 1. Granting access to a user or team  1. Share a kind of information with a user or team
Line 93: Line 152:
 1. Failing to grant access to a team that is public or a member team
 is a public		  1. Failing to share with a team that is inclusive.
Line 96: Line 154:
 1. Revoking access to a user with full access.  1. Unsharing with a user with all things shared.
Line 98: Line 156:
 1. Revoking access to a user with partial access.  1. Unsharing with a user with something things shared.
Line 100: Line 158:
 1. Revoking access to a contributor?  1. Unsharing with a team with something things shared.
Line 107: Line 165:
 1. An owner can see all users who have access to a private project.  1. An owner can see all users that restricted information is shared with.
Line 109: Line 167:
 1. The owner can see how the use acquired access.  1. The owner can see is the information was shared to the user, via team, or via a bug or branch.
Line 111: Line 169:
 1. The owner can see a summary of what the user knows.  1. The owner can see a summary of the artefacts that were shared.
Line 113: Line 171:
 1. The owner can revoke a user and see what the user was unsubscribed from
 everything too.		  1. The owner can unshare a user and see what the user was unsubscribed from
 everything.
Line 119: Line 177:
 1. The canonical team is subscribed to all canonical projects.  1. All canonical projects with proprietary data are shared with ~canonical.
 1. Ubuntu only shares User Data with ~apport and Embargoed Security with ~ubuntu-security
 1. OEM projects share all kinds of data with drivers
Line 124: Line 184:
 1. Owner, drivers, an bug supervisors are assumed to have full access. === jml ===

 1. Owner, drivers, security contacts and bug supervisors are assumed to have full access.
 1. We should get a team within Canonical to beta test

Sharing

Project and distribution owners can share and unshare restricted/private data with users and teams.

Project and distribution owners need to see who restricted information about their project is shared with.

PrivateProjectsAndDistributions

Rationale

With the introduction of private projects and distributions, owner need a way give share to hundreds of private project artefacts.

Stakeholders need to know who they are sharing with, and in a single action, share more or unshare. This is valuable to public project with default private bug and branches--once restricted data is shared with a company team, all employees have access to company information.

e.g. Steve Magoun from OEM would like to be able to see exactly who has access to every component in his project.

Stakeholders

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

  • UbuntuOne (John Lenton)

User stories

Commercial stories

As a commercial project owner
I want to mark some data as proprietary that should not be shared with other projects
so that information provided in confidence is not disclosed

As a commercial project owner
I want share proprietary information with users and teams
so that my organisation and contractors can collaborate<<BR>

Canonical stories

As a member of ~canonical
I want to share everything proprietary data in my project with ~canonical
so that that members of my organisation are not blocked from collaborating<<BR>

As a member of IS
I want to add a new employee to the ~canonical team
so that that he has access to all information shared with ~canonical<<BR>

As a member of IS
I want to run remove all things shared with a former Canonical member in Canonical projects
so that that confidential data is not disclosed<<BR>

OEM stories

As a maintainer of OEM projects (~pmteam)
I want to share everything with ~oem-dev (the driver)
so that they I can delegate all development to them

As a driver OEM projects (~pmteam)
I want to share some bugs and branches with a contractor
so that he can fix the issues for us

As a maintainer of OEM projects (~pmteam)
I want to see all users who have some things shared with them
so that I can share nothing with them if they are not under contract

Ubuntu stories

As a the maintainer of Ubuntu<BR>> I want to unshare user-data with maintainer and share user-data with the apport bot
so that no human has access to personal user-data<<BR>

As a the maintainer of Ubuntu<BR>> I want to unshare security with maintainer and share user-data ~ubuntu-security
so that only trusted experts see security issues

Constraints and Requirements

Must

  1. A lists of all the users with all or some things shared.
    The view must also show exactly how the user has access, for example: directly or via a team; as a (core?) contributor or as a user; by subscribing to some artefacts or through access to the whole project.

  2. A summary everything an user may know about the project.
    The view must also show how the user was shared: direct or via a team.

  3. A way to share everything with a user or team.
    When a owner shares with a team, the view must show who who is being shared with and how many members (person-picker).

  4. A way to unshare everything with a user or team.
    Revocation removed all subscriptions to individual artefacts be default. The owner many choose to keep some subscription so that partial access is allowed. If the user has access via a team, the view must explain how to remove either the user or the team to unshare.

Nice to have

  1. List the users who everything is shared via the owner or driver team.
    The owner may need to know about contributors as well as users. If the owner can unshare with an owner/driver, then the user must be removed from the team and assignments and subscriptions are removed too.

Must not

  1. Unsharing with a user or team must not allow the user to have some things shared.
    Revoking access to a user must remove the individual subscriptions that provide partial access.

  2. Sharing must not cede control of what is shared.
    Inclusive teams (open and delegated) may not be shared with. Inclusive teams allow anyone to choose to become a member, which undermines the owner's power to manage the information disclosure.

Subfeatures

  1. Replace bug and branch privacy mechanism with a common way classify the data
    • private and security/branch visibility do not interact with each other or meet the needs of sharing all of a kind of restricted data.
    • Use Public, Unembargoed Security, Embargoed Security, User data to describe the existing kinds of privacy
  2. Introduce the Proprietary kind of privacy that is not multi-tenant.
  3. Introduce a choice picker that support descriptions with the terms.

Workflows

  1. Viewing a list of users that the project is shared with and a summary for a single user when some things are shared.
  2. Share a kind of information with a user or team
  3. Failing to share with a team that is inclusive.
  4. Unsharing with a user with all things shared.
  5. Unsharing with a user with something things shared.
  6. Unsharing with a team with something things shared.

Success

How will we know when we are done?

  1. An owner can see all users that restricted information is shared with.
  2. The owner can see is the information was shared to the user, via team, or via a bug or branch.
  3. The owner can see a summary of the artefacts that were shared.
  4. The owner can unshare a user and see what the user was unsubscribed from everything.

How will we measure how well we have done?

  1. All canonical projects with proprietary data are shared with ~canonical.
  2. Ubuntu only shares User Data with ~apport and Embargoed Security with ~ubuntu-security
  3. OEM projects share all kinds of data with drivers

Thoughts?

jml

  1. Owner, drivers, security contacts and bug supervisors are assumed to have full access.
  2. We should get a team within Canonical to beta test

LEP/Sharing (last edited 2012-06-26 17:17:25 by sinzui)