Frankly, WMF has botched a number of releases in the past. In a way, this is great, because it means both WMF and volunteers are still eager to improve Wikipedia, we are still trying to make things better. On the other hand, it is never a good thing to irritate the most important group - our community. So there is always a compromise: when and what to roll out, how to make it least disruptive vs how to improve the usability and the content quality.

For wikis, there are two types of improvements: user interface and content. User interface features change how one views and edits site's content, so any change immediately affects everyone. We try to mitigate it with "Beta features" -- logged in users may enable new functionality before it is enabled by default for everyone, but the vast majority of the readers are not logged in, so when enabled, it is still a serious and instant change. Maps are not really a part of interface because they only appear as part of the page content, which is fully controlled by the community.

Content features allow editors to add new type of content - maps, graphs, sheet music, text formatting or new types of templates. There is no way to hide a new content feature behind a "beta flag" because everyone sees the same content, but content features are not disruptive because they depend on the editors to add them to the pages. Community has full control, and if it does not like a feature, or if it feels the feature is not ready yet, it will not be used. The only time content changes are disruptive is when the support for a widely used feature changes or gets disabled. This is clearly not the case with the maps roll out on Wikipedia.

The WOW effect, and marketing in general, have both positive and negative effect on a feature roll out. If a feature is quietly enabled, only the more engaged community members will experiment with it and discuss the feature's best usage, give feedback on how to improve it, and eventually enable it at its own pace. A massive marketing of a feature would attract a lot of attention and expedite adaption, but may also create some amount of negativity if the community feels the feature is not yet ready.

I also feel it is very dangerous to delay releasing new features until they are perfect. We (developers/PMs/...) may think we know what feature is needed, but most likely we are wrong. If we delay, we may spend a lot of resources on polishing something that is not needed. Instead, by releasing early, community's feedback would put us back on the right track. Yes, it may not be as good, but at least we will quickly change direction, producing a truly needed feature that can be polished later. Of course this is much easier to do with the content features rather than user interface changes (hence the UI's "feature flag").

In light of this, I feel it is better to continuously roll-out small content-related features without much publicity (e.g. Village pump is OK, blog might be less so), and continuously improve based on community feedback. Once the feature has been out for some time and there is a general consensus that the feature is good, we can start the marketing push. This approach creates less stress on the community lesions, developers, and servers. Feedback is received in smaller portions and can be properly acted on.