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 * 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
