The "release" stage in this model doesn't seem to distinguish between adding a feature that can be used, and adding a feature that must be used (or must be manually disabled/worked around to avoid it) -- a distinction that I think was at the core of past fights over MultimediaViewer and VisualEditor.
Topic on Talk:WMF product development process
Pushed post too early. :) Needs more explicit calling out of iterative releases: open-beta style opt-in testing, ability to see old and new versions side by side and select among them.
And also needs to call out what happens to "old" features -- discontinuing things that are obsoleted/replaced by a new feature, or new work that gets tested for a while and then discontinued, itself has consequences. (And failing to trim out those thigns has its own consequences.)
Good points. The idea of this entire flow is that it could be applied to a beta/alpha/production. In that line of thought then something in Maintain as a task to graduate? or evaluate? Evaluate may be better as it could apply to old features or new beta's that perform.
I agree that this stage is critical and needs clear definition. @JAufrecht (WMF) @Greg (WMF), your thoughts here are welcomed.
In the context of Wikimedia, releases are frequently very complex because they involve waves (not all wikis get the same releases at the same time), and different methods for opt-in / opt-out at a wiki level and at an individual level. I bet not many people at the WMF are aware of all the options available, leave alone among our communities, and as far as I know they are not documented in a single place.
When a project enters the Release stage, it is communicating an intention to become a new product/feature in production. This should trigger a communication to our communities, so they can prepare accordingly and optionally provide their feedback. Some requirements should be fulfilled to enter the Release stage, such as a functional prototype available, a list of release blockers and quality criteria, a release plan, and a communication plan.
Can we consider that a project enters the Release stage for the first time when it requests deployment to test.wikipedia.org? (equivalents must be defined for mobile apps etc). Labs prototypes would be part of Build. Beta features would be definitely part of Release.
The release plan could be as simple as following a default timeline for beta features, A/B testing, and release waves (to be defined, unless a systematic process already exists). Projects with special needs would customize this default process, proposing alterations in the deployment waves (e.g. some wikis to be prioritized, some wikis to be moved to later waves), providing special methods for user opt-in / opt-out, etc.
Communities should have a chance to influence this plan, proposing release blockers and non-blockers specific to them (not all issues impact equally all types of projects and languages), or choosing a different wave (some communities will be socially more excited about a certain product, or more stressed about it).
When the release plan is defined, another communication to the communities would be sent. From that point, releasing as planned should be a matter of checking against the quality criteria agreed, and deploying when the criteria have passed.
FYI, there are two tasks in Phabricator that depend on the details about the Release stage: