Wikimedia Apps/Team/Android/AndroidReleasePhases

Development Timeline
At any given time, however, two releases are underway. The timeline, considering multiple releases.

Android team development cycle
The following is an outline of the team's standard process. It is important to ensure that everyone has a shared understanding of what each phase means. There are no pre-set dates or durations for phases, as the team will discuss timing as they work and agree together on when to move from one phase to the next.


 * 1) Initialisation
 * 2) * Discuss concept with PM/engineers/UX research/analytics/RI and other teams to be informed
 * 3) * Prepare rough concepts/wireframes as needed to aid discussion
 * 4) * PM/analytics/UX research agree initial set of research questions (qual and quant)
 * 5) Research
 * 6) * Present design proposal to engineers/design research/analytics for feedback
 * 7) * Engineers begin technical discussions
 * 8) * Write placeholder Epics
 * 9) * Create prototype for user testing (preferably using InVision or similar)
 * 10) * Initial evaluative user testing
 * 11) Specification
 * 12) * Engineers agree on technical implementation details (and create mock APIs, etc)
 * 13) * Finalised designs and user flows completed and available in Zeplin (feedback to design as needed from engineers)
 * 14) * Analytics specifies tagging scheme based on research questions
 * 15) * Break out Epics into sub-tasks and link related designs to Phab tasks
 * 16) * Conceptual document available on-wiki, linked to related Phab tasks, etc
 * 17) * Most major unknowns should be identified, remaining work is understood
 * 18) Development
 * 19) * Most functionality delivered to internal users for dogfooding/feedback
 * 20) * Scope trimmed to final size (remove tickets from board as necessary)
 * 21) Feature Freeze
 * 22) * Only minor bugs and edge cases remain or added are to scope
 * 23) * Initial QA and design review completed on all epics
 * 24) Code Freeze
 * 25) * Do pre-release smoke test and beta
 * 26) * Monitor beta release crash reports for at least three days before another beta release
 * 27) * Remove all “nice to haves” from the board
 * 28) * Only new tickets come from QA or tester feedback
 * 29) * Create a new branch from develop named as the version number for the release; any changes to the release are done as pull requests/patches targeted to this branch
 * 30) * Finalise marketing messages and materials, update app store assets
 * 31) Release Call
 * 32) * Final check with engineers
 * 33) * Actual release happens
 * 34) * Release notes publicised
 * 35) * Documentation updated
 * 36) Release
 * 37) * Duties should be rotated amongst engineers so that everyone understands the process.
 * 38) *Minor/bug-fix releases will be once per month, incorporating whatever bugs have been fixed and minor improvements have been made, that have passed QA and design review by the time we cut the beta. We will submit to beta on the Monday of the last week of the month, monitor for a few days, and submit to prod on the last Thursday if crashes/ratings/etc look fine.
 * 39) *Major feature releases will go out as and when the feature is completed as per checklist above, and needn't wait till the end of a month.

Rituals
These meetings ensure that the team maintains regular communication and has time for planning and board upkeep.