Differences between revisions 4 and 49 (spanning 45 versions)

Disclosure

Scope

Out of scope

LEP/AuditTrail
Bug linking will now be a separate project

Deliverables

Item	Owner	Expected date	Status
Signed off LEPs	jml		DONE
Person pickers (person-picker)	sinzui	2011-09-21	DONE
Target pickers (target-picker)	sinzui	2011-10-13	DONE
Harden bugs and teams	sinzui	2011-12-14	DEVELOPMENT
Managing disclosure	sinzui	2012-01-30	DEVELOPMENT
social private teams
Private projects
Private distributions
Basic entitlement
Feature documentation	danhg
Blog post	danhg

Action items for next checkpoint

Harden bugs and teams

[purple] Modify the footgun feature flag to keep multi-tenancy for security bugs.
[purple] Enable footgun feature flag to reduce growing the number of private bugs with multiple projects

Manage disclosure

[danhg] User-test the dynamic +managing-disclosure mock-ups
[huwshimi] Should we change the bug tags to look like these new tags?
[purple] Implement a draft +manage-disclosure UI
[purple] Populating and maintaining the access policy data

Actions for later

[purple] Turn on +manage-disclosure and security through the access policy: LATER

Notes

Resources

User research

https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/
https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/CodySommerville
https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/SteveMagoun
Dan's rough notes from +manage-disclosure with tags for policies paper prototyping research.

Exploratory testing

Still needed

How are we going to link from deliverables to LEPs?

User stories in a LEP can be grouped, can be individual. Either way, must be able to be referenced
A deliverable can correspond to a group of user stories or a single user story
Product team uses the user stories when evaluating progress on feature

-  ⇤ ← Revision 4 as of 2011-06-14 14:10:30 → 
  Size: 2677
  Editor: jml
  Comment:
+   ← Revision 49 as of 2011-11-30 20:03:25 → ⇥
  Size: 3413
  Editor: flacoste
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 5:
+'''Squad started:''' 2011-05-23<<BR>>
'''Current week:''' 25<<BR>>
'''Next [[PolicyandProcess/FeatureDevelopmentCheckpoint|checkpoint]]:''' 2011-12-14
-Line 7:
+Line 10:
- * [[LEP/BugLinking]]
-Line 12:
+Line 14:
+ * [[LEP/SocialPrivateTeams]]
-Line 16:
+Line 19:
- * Private teams work out of scope, except where necessary to enable above
 * Any complicated bug linking beyond the bare case for cloning
+ * Bug linking will now be a separate project
-Line 19:
+Line 21:
-== Blockers ==

== Special actions ==

 * jml to go through LEPs, organize along roadmap lines, convert as many requirements to stories as make sense
-Line 29:
+Line 26:
-|| Person pickers || || 2011-06-16 || INPROGRESS ||
|| Project pickers || || ||
|| Feature documentation || mrevell || || ||
|| Blog post || mrevell || || ||
+|| [[LEP/TrustedPickers#person-pickers|Person pickers]] ([[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=person-picker|person-picker]]) || sinzui || 2011-09-21 || DONE ||
|| [[LEP/TrustedPickers#project-pickers|Target pickers]] ([[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=target-picker|target-picker]]) || sinzui || 2011-10-13 || DONE ||
|| Harden bugs and teams || sinzui || 2011-12-14 || DEVELOPMENT ||
|| [[LEP/ManagingDisclosure|Managing disclosure]] ||sinzui || 2012-01-30 || DEVELOPMENT ||
|| [[LEP/SocialPrivateTeams | social private teams]] || ||  || ||
|| [[LEP/PrivateProjectsAndDistributions#projects|Private projects]] || || || ||
|| [[LEP/PrivateProjectsAndDistributions#distributions|Private distributions]] || || || ||
|| [[LEP/PrivateProjectsAndDistributions#entitlement|Basic entitlement]] || || || ||
|| Feature documentation || danhg || || ||
|| Blog post || danhg || || ||
-Line 34:
+Line 37:
-. Person pickers
 1. Project / distribution pickers
 1. As a developer, I want to be able to clone a bug from one project to another project so that I can have separate conversations about the bug, each with their own disclosure level
 1. As a project owner, I want to see who has access (is subscribed to) private bugs and branches within my project, so that I can make sure that everyone who needs to have access has it, and no one who shouldn’t doesn’t.
 1. (2 cycles) As a project owner, I want to give users permission to see all of the private items in my project so that I have a simple way to induct new members into my private project.
 1. As a project owner, I want to see users with permission to see all of the private items in my project so that I can maintain control over who has access to my project.
 1. As a project owner, I want to prevent a user from accessing to my project or a bug/branch, so that private information is not disclosed and that owners can respond to a disclosure issue immediately
 1. (2 cycles) alpha level, opt-in only private projects
 1. Private distributions
 1. As a person with rights over a blacklisted name, I want to create a private project or distribution with a blacklisted name without any Launchpad admin intervention or any other privileges, so that I can just get my stuff done and not accidentally destroy everything
+== Action items for next checkpoint ==
-Line 45:
+Line 39:
-== XXX - missing bits ==
+=== Harden bugs and teams ===
-Line 47:
+Line 41:
- * Deliverables
   * Any user testing sessions
   * Any RTs
   * Maybe feature-level deliverables (e.g. 'person pickers')
 * Where does exploratory testing go?
 * Where do mockups go?
 * Somehow fit in two week cycle -- https://wiki.canonical.com/Launchpad/PolicyandProcess/FeatureDevelopment
 * Turn into template
+  * [purple] Modify the footgun feature flag to keep multi-tenancy for
  security bugs.
  * [purple] Enable footgun feature flag to reduce growing the number
  of private bugs with multiple projects

=== Manage disclosure ===

  * [danhg] User-test the dynamic +managing-disclosure mock-ups
  * [huwshimi] Should we change the bug tags to look like these new tags?
  * [purple] Implement a draft +manage-disclosure UI
  * [purple] Populating and maintaining the access policy data

== Actions for later ==

  * [purple] Turn on +manage-disclosure and security through the access policy: LATER

== Notes ==

<<PageList(regex:^Projects/Disclosure/Checkpoint-*)>>

== Resources ==

=== User research ===

 * https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/
 * https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/CodySommerville
 * https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/SteveMagoun
 * [[/ManageDisclosureTagsInitialResearch|Dan's rough notes]] from +manage-disclosure with tags for policies paper prototyping research.

=== Exploratory testing ===

 * [[/QA/ExploratoryTesting/Disclosure/TrustedPickers|Trusted pickers]]
 * [[/QA/ExploratoryTesting/Disclosure/ManagingDisclosure|+manage-disclosure mock up testing]]
 * [[QA/ExploratoryTesting/Disclosure/|Bug fixes exploratory testing]]

=== Still needed ===


=== How are we going to link from deliverables to LEPs? ===

 * User stories in a LEP can be grouped, can be individual. Either way, must be able to be referenced
 * A deliverable can correspond to a group of user stories or a single user story
 * Product team uses the user stories when evaluating progress on feature

launchpad development

Diff for "Projects/Disclosure"

Disclosure

Scope

Out of scope

Deliverables

Action items for next checkpoint

Harden bugs and teams

Manage disclosure

Actions for later

Notes

Resources

User research

Exploratory testing

Still needed

How are we going to link from deliverables to LEPs?