Diff for "LEP/Sharing"

Not logged in - Log In / Register
Differences between revisions 8 and 10 (spanning 2 versions)
⇤ ← Revision 8 as of 2011-06-29 11:27:09 →
Size: 5704
Editor: jml
Comment:
← Revision 10 as of 2012-02-02 14:29:43 → ⇥
Size: 6115
Editor: sinzui
Comment:
Deletions are marked like this. Additions are marked like this.
Line 31: Line 31:
 * UbuntuOne (???)  * UbuntuOne (John Lenton)
Line 35: Line 35:
<<Anchor(seeing-legacy)>>
=== Seeing legacy disclosure ===		 <<Anchor(commercial-stories)>>
=== Commercial stories ===
Line 38: Line 38:
'''As a ''' project owner<<BR>>
'''I want ''' to see who has access (is subscribed to) private bugs and branches within my project<<BR>>
'''so that ''' I can make sure that everyone who needs to have access has it, and no one who shouldn’t doesn’t<<BR>>		 '''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>>
Line 42: Line 42:
<<Anchor(granting)>>
=== Granting disclosure ===		 '''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>
Line 45: Line 46:
'''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>>		 <<Anchor(canonical-stories)>>
=== Canonical stories ===
Line 49: Line 49:
<<Anchor(seeing)>>
=== Seeing disclosure ===		 '''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>
Line 52: Line 53:
'''As a project owner'''<<BR>>
'''I want ''' to see users with permission to see all of the private items in my project<<BR>>
'''so that ''' I can maintain control over who has access to my project.<<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>
Line 56: Line 57:
<<Anchor(withdrawing)>>
=== Withdrawing disclosure ===		 '''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>
Line 59: Line 61:
'''As a project owner'''<<BR>>
'''I want ''' to prevent a user from accessing to my project or a bug/branch<<BR>>
'''so that ''' private information is not disclosed and that owners can respond to a disclosure issue immediately
<<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 85: Line 111:
   * ''Why not also remove the user from the team?'' -- jml
Line 89: Line 113:

 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.
   * ''Why do they care?'' -- jml
Line 99: Line 118:
   * ''Please unpack this for me'' -- jml
Line 103: Line 121:
 1. Revoking a user or team not allow the user to have partial access.<<BR>>  1. Revoking a user or team must not allow the user to have partial access.<<BR>>
Line 106: Line 124:
   * ''Is this another way of saying "revoke" means "revoke"?'' -- jml
Line 125: Line 142:
 1. Failing to grant access to a team that is public or a member team
 is a public

   * ''Ditto for open teams, right?'' -- jml		  1. Failing to grant access to a team that is open or a member team
 is open
Line 160: Line 175:
 1. Owner, drivers, an bug supervisors are assumed to have full access.
 1. We should geta team within Canonical to beta test


=== jml ===

 * What about an equivalent view for artefacts? i.e. who can see it, owners can revoke privs etc.
 * You distinguish between 'contributor' and 'user' a bit. I sense that you've loaded 'contributor' with special meaning. Would like to know more.		  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

Managing Disclosure

Project and distribution owners can grant or revoke user and team permissions to access all private artefacts.

Project and distribution owners need to see who can access all or some of their project. Owners need to grant and revoke access.

PrivateProjectsAndDistributions

Rationale

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

Stakeholders need 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.

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 full or partial access.
    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 has access: direct or via a team.

  3. A way to grant a user or team full access to a project.
    When a owner grants access to a team, the view should show who gains access.

  4. A way to revoke all access to 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 revoke permissions.

Nice to have

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

Must not

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

  2. Granting access must not cede control of disclosure.
    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.

Subfeatures

None

Workflows

  1. Viewing a list of users and a summary for a single user.
  2. Granting access to a user or team
  3. Failing to grant access to a team that is open or a member team is open
  4. Revoking access to a user with full access.
  5. Revoking access to a user with partial access.
  6. Revoking access to a contributor?

Success

How will we know when we are done?

  1. An owner can see all users who have access to a private project.
  2. The owner can see how the use acquired access.
  3. The owner can see a summary of what the user knows.
  4. The owner can revoke a user and see what the user was unsubscribed from everything too.

How will we measure how well we have done?

  1. The canonical team is subscribed to all canonical projects.

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)