On Mon, May 6, 2013 at 7:43 PM, Erik Moeller <[email protected]> wrote: > On Mon, May 6, 2013 at 7:20 PM, MZMcBride <[email protected]> wrote: > >> The reason I ask about a distinction is that there have been a lot of >> changes to Wikimedia wikis lately and likely more to come, as the >> Wikimedia Foundation has gotten larger and has more dedicated tech >> resources. Overall, this is great. But big new features come with big >> changes, and these changes sometimes need a bit of breathing room. I've >> read a lot of pushback lately against rapid changes (usurping usernames, >> getting rid of the new message indicator, etc.). A lot of this seems >> mostly outside the scope how often to deploy (and I don't want to shift >> the focus of this thread), but it gets confusing (to me, at least) to make >> a distinction between new code/features on Wikimedia wikis and how often >> to branch MediaWiki core/extensions. > > A lot of this could potentially be addressed in a consistent manner > across wikis if we applied the alpha->beta->prod (or just beta->prod > for starters) channel model that's used on the Wikimedia mobile sites. > Then features (whether in core or extensions) could be flagged for > alpha or beta readiness, and users would only get them if they've > decided to opt into either of those channels. We could still flip the > switch from beta->prod, but that decision could be decoupled from the > weekly deployment cycle. > > This would likely be done for features & changes which have > significant user-facing impact, and where segregation into "on" and > "off" modes is possible (not always the case). >
I think this is awesome for features ... but if we're putting work into this, I would love even more to have a clustered a+b production environment, such that 10% of folks are put on the new release (cluster a) and then it gets pushed over to cluster b. Then we can also test performance in a real world environment, and breakages only happen for 10% (PS the 10% number was pulled out of thin air). The opt-in beta is much too limited, as well as being inapplicable to the vast majority of our traffic (logged in users are such a small percentage) to make proper comparisons. You could also see the impact of features on usage for average users. > We may want to consider at least putting some such scaffolding for > beta->prod desktop modes into place before shifting to weekly > deployments, although if that holds up this change significantly, I'd > be in favor of making the shift first and then iterating. > > Right now we have lots of individual "experimental" prefs, some dark > launch URL parameters (&useNew=1 for the account creation forms etc.), > some changes that are announced widely but then rolled out immediately > (section edit link change), etc. What would be the disadvantage of > having a single "I'd like the latest and greatest changes once they > come in" preference for our users? The main disadvantage I see is that > we'd need to temporarily retain two codepaths for significant > user-facing changes, potentially increasing code complexity a fair > bit, but perhaps reducing post-launch cost in return. And we'd need to > consider more carefully if/when to make the beta/prod switch -- not > necessarily a bad thing. ;-) > > Have there been any negative experiences with this model on the mobile sites? > > Erik > > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
