On Tue, Nov 20, 2012 at 5:19 PM, James Forrester <jforres...@wikimedia.org> wrote: > All, > > *TL;DR: We're proposing a more formal, but more limited, statement of > browser 'support' for the cluster; thoughts appreciated.* > > In WMF Engineering, we've been struggling with what we mean by 'supporting' > browsers, and how we can match limited developer time to our natural desire > to make everyone happy. > > Right now our 'support' for user agents varies between existing features > and in particular between different developing products, but we lack a > single framework in which to consistently express what works and - more > importantly - what our users should expect to work. We have a > chronically-misleading page on > MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that > currently claims we will support any browser which gives us more than 0.01% > of users (an extremely-expensive claim) - this was changed in > August<https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid=571244> > from > the 0.1% threshold you see around more often, or the 1% one that we started > with. > > So, the new proposal: > > There would be a "top level" outline policy - a small number > of browsers are supported (i.e., WMF will keep spending money until they > work): > > * Desktop: Current and immediately-previous versions of Chrome, Firefox, > MSIE and Safari
I hate to make our job more difficult, but I think Faidon had a good point -- <Quote> Agreed. IE 9 is only supported from Vista onwards and Windows XP is 21.29% of our user base according to the latest stats¹. I'm not sure it's realistic to say that 20% of our user base may just "happen to work" by luck. </Quote> Perhaps a percentage of use threshold system would be a bit better? I don't see a breakdown of a % of requests per client type (desktop/phone/tablet) here - http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm , but it should be creatable and hopefully bring a balance between trying to come up with crazy workarounds for old clients and keeping functionality for the vast majority of users. Leslie > * Tablet: Current versions of iOS/Safari; Current and immediately-previous > ones of Android > * Mobile: Current versions of iOS/Safari; Current and the five previous > ones of Android[*] > > Anything not in this list may "happen to work" but WMF Engineering will not > spend resources (read, developer time) on it. If a volunteer is willing to > work like hell to make, say, the VisualEditor work in Opera we would try to > support them by reviewing/accepting patches, but nothing more than that. It > doesn't mean we would go out of our way to break previous browsers as they > leave support, but we would not hold ourselves back from useful development > solely because it might break browsers that we've actively decided not > to support. > > Each piece of feature development and platform work would explicitly say > whether it was to inherit this top-level policy or chose its own. This > would be based on what technical needs the product has and the user > goals/break-down. These product support policies would be reviewed by the > team every now and then and can go further or less far than the main policy > depending on circumstances - that's the decision of the team involved. > > For example, the Mobile team's work might want to go further and support > mobile Opera, but might not care about breaking desktop support (as it's > not a target for them). As another example, for "basic" functionality in > Platform - I'm thinking specifically about just article-namespace reading, > history viewing and diffing - we might well want to be very broad in our > support, down even below the historic "0.1%" level. > > I have created a browser > matrix<https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser_matrix> > for > VisualEditor to identify the browser support that our team will be able to > provide. This is a table with ticks or crosses for support > of grouped browsers, gated at the 0.1% threshold (so browsers used by fewer > than 0.1% of our readers like IE 5.0 don't show up). This is now actually a > template which is as not-ugly as you can make it in wikitext[+]; I'm happy > to commit to updating its data every month as it's released so teams can > create their own, though finding a way to get this created automatically > would be nice too. > > So, to turn this mass of text into an 'ask', I would love the thoughts of > this list about this. Do you think this might work? Is "making sure all the > different parts of MediaWiki keep working with <browser I love>" something > you'd see yourself volunteering to do? > > I'd be happy to talk through the individual browser-level decisions but it > might be easier to agree that we want to focus browser support before we > decide the exact focus of this. :-) That said, do you think we should > support fewer browsers than those I've proposed (and if so, which and > why)? Different ones (again, why)? More (and if so, what do you propose we > stop doing instead)? Feedback would be very helpful. > > > [*] - This is what is meant when people bemoan "Android fragmentation". > [+] - Ironically for a page about the VisualEditor, creating wikitext that > it will likely forever struggle to edit. > > J. > -- > James D. Forrester > Product Manager, VisualEditor > Wikimedia Foundation, Inc. > > jforres...@wikimedia.org | @jdforrester > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
