launchpad developmentThe purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess.
Dynamic Configuration
Launchpad has a registry of configuration options that can be changed by admins through the web ui, without restarting Launchpad.
As a Launchpad developer/operator
I want to turn features on and off without a heavyweight deployment
so that I can more adroitly test and deploy new features
and so that I can recover from emergencies by cutting-off problem features
As a Launchpad developer/operator
I want to limit some features to subsets of users
so that I can do A:B testing, or long-running closed betas.
- This is not a mechanism for general per-user configuration
- This is not a complete replacement for static configuration or other parts of the deployment process
- This only affects new code that specifically uses it; it doesn't magically affect existing code
- This may become a replacement for things that are currently done through SQL queries or configuration files
Link this from LEP
Rationale
Why are we doing this now?
What value does this give our users? Which users?
Stakeholders
Who really cares about this feature? When did you last talk to them?
Constraints and Requirements
Must
What MUST the new behaviour provide?
Nice to have
Must not
What MUST it not do?
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
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?
Thoughts?
Put everything else here. Better out than in.
