https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule
Monday 26, 1:00pm
The existing ways of releasing user-facing features have proved to have severe limitations during the Media Viewer release. As someone who went through that storm, I feel like many of the organizational issues we encountered haven't been addressed yet. This is a critical issue, as years of hard work can potentially get a very hostile response when the release date comes, and unprepared engineers can find themselves with a big crisis to handle with many hotfixes to produce in a short period of time.
While some areas have been improved since, such as the introduction of the design research team as a way to validate changes, much still has to be discussed.
Slides: https://docs.google.com/presentation/d/1zAiBdDZnw1-JXWKkYlM1U8GdpuRuL5zaNCx5S9mWRoQ/edit?usp=sharing
Etherpad: http://etherpad.wikimedia.org/p/user-facing-feature-release-discussion
Concrete actionable suggestions surfaced during this session:
- Gradual deployment tools
- Advertising beta features
- Only use public mailing lists for product design and development
- Make meetings public by default, even if we think nobody will watch of be interested (weekly team meetings, etc.)
- Give unregistered (logged out) users access to beta features T76580
- Easier creation/signup/info for newsletters M12
- Publicly visible/editable product dashboard tracking acceptance criteria, and how/why those were set
- Allow time in product development process for learning and iteration (build / research / iterate / build)
- Reach out to subsections of the movement who don't currently have a voice (eg. readers, potential users)
- Set up a blocking set of criteria for technical fitness before release (eg. is the test coverage appropriate?)
- Executable acceptance tests written as user stories used for success measurement