Name: Feature Development Process
Owner: Launchpad Project Lead
We develop or re-work features for Launchpad all of the time. It turns out that there's quite a lot of stuff that we have to do for each feature. This process summarises what we do for most features, and links out to more detailed process documents.
0. Stakeholder process
Feature work starts by consulting Launchpad stakeholders to decide what feature we should work on next.
1. Analysis / LEP drafting / evidence gathering
- Announce that we are commencing work to the stakeholders
Create a LEP, see LaunchpadEnhancementProposalProcess.
2. Core development cycle (2 weeks)
- Plan work
User research / UI design
- Development (this is what happens when software engineers make software)
3. User acceptance testing with stakeholders
- Stakeholders should already be consulted at each checkpoint
- Announce to stakeholders that work is finishing up and that this is their last chance to review the feature
- Major changes strongly discouraged
- Purpose is to communicate that the feature is done and to help stakeholders feel ownership of it
4. Release & promote
- Ask the Squadron Leader to add a feature flag for ~launchpad-beta-testers.
- Announce a time-boxed beta period:
- briefly explain the feature
- warn of any known limitations
- link to where bugs should be reported and state the tag people should use.
- Prepare announcements:
- Record a screencast of the beta.
- Write an announcement blog post.
- Draft any documentation updates.
- If appropriate, contact press (OMG Ubuntu! is receptive) and get them excited about the feature. Draft something for them, if required.
- On the final day of the beta, check that the Squad is ready to take it live.
- On release day, coordinate with the Squad as to when they'll take the feature live. Post the announcement, screencast and documentation changes straight after release.
- If press are to be involved, contact them.
- Launchpad Product Strategist
- Feature squad