2573
Comment:
|
3407
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
'''Squad started:''' 2011-05-23<<BR>> '''Current week:''' 4 |
|
Line 23: | Line 26: |
* jml to create a project picker LEP | |
Line 29: | Line 33: |
|| Person pickers || || 2011-06-16 || INPROGRESS || || Project pickers || || || |
|| [[LEP/TrustedPickers|Person pickers]] || || 2011-06-16 || INPROGRESS || || Project pickers || || || || || [[LEP/BugLinking|Bug cloning]] || || || |
Line 48: | Line 53: |
* https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/ * https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/CodySommerville * https://wiki.canonical.com/Launchpad/UserResearch/Disclosure/SteveMagoun |
|
Line 52: | Line 60: |
=== How are we going to link from deliverables to LEPs? === * Change LEPs to have multiple users stories in a section after the intro and before the constraints * 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 |
Disclosure
See also disclosure tag
Squad started: 2011-05-23
Current week: 4
Scope
Out of scope
- Private teams work out of scope, except where necessary to enable above
- Any complicated bug linking beyond the bare case for cloning
Blockers
Special actions
- jml to create a project picker LEP
- jml to go through LEPs, organize along roadmap lines, convert as many requirements to stories as make sense
Deliverables
Item |
Owner |
Expected date |
Status |
Signed off LEPs |
jml |
|
DONE |
|
2011-06-16 |
INPROGRESS |
|
Project pickers |
|
|
|
|
|
||
Feature documentation |
mrevell |
|
|
Blog post |
mrevell |
|
|
- Person pickers
- Project / distribution pickers
- 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
- 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.
- (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.
- 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.
- 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
- (2 cycles) alpha level, opt-in only private projects
- Private distributions
- 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
XXX - missing bits
- Link to user testing sessions
- Link to exploratory testing
- Link to mockups
Somehow fit in two week cycle -- https://wiki.canonical.com/Launchpad/PolicyandProcess/FeatureDevelopment
- Turn into template
How are we going to link from deliverables to LEPs?
- Change LEPs to have multiple users stories in a section after the intro and before the constraints
- 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