On 20 November 2012 17:19, James Forrester <jforrester(a)wikimedia.org> wrote:
TL;DR: We're proposing a more formal, but more
limited, statement of browser
'support' for the cluster; thoughts appreciated.
To clarify this a little more, as I think a little of the nuance has been
getting lost in the discussion:
* We currently don't focus our work on making MediaWiki, and in particular the
Wikimedia cluster, work with browsers very well. This means we spend time or
other resources on things we don't need, and not on areas that need more
attention.
* This is a proposal to bring in a new level of work above our current efforts,
called "support". This level would involve WMF Engineering spending donor
funds until we have 100% of the functionality of everything we do, unless that
area (e.g. the VisualEditor, or PediaPress) has a local policy.
* This is a very high commitment for any organisation, and particularly high for
one which funded by charitable giving, and so can only be applied sparingly.
* Just because a browser is not in the "support" list does not mean that it
will
suddenly stop working, or that WMF Engineering will not test it to ensure that
it continues to work. In fact, under this policy we would commit to only
deliberately breaking functionality with a proper justification, and providing
new functionality as "progressive enhancements" wherever possible.
* I said that "[e]ach piece of feature development and platform work would
explicitly say whether it was to inherit this top-level policy or chose its
own", which was because I felt that it wasn't my place to dictate how other
parts of WMF Engineering choses to spend their resources. That said, I think
it's very likely that Platform's work on basic writing (load, render, edit and
save the wikitext edit form) might target at the 0.1% level, and reading (as I
said, "article-namespace reading, history viewing and diffing") would target
even below this 0.1%.
* However, this policy does mean that some people's currently-favoured browser
set-ups will be unsupported, and at some point might cease to work. Though a
pain, this is not the end of the world; there are normally simple work-arounds
(e.g. switching browser) rather than more complex ones (like switching their
Operating System). Is this perfect? No, but what is?
As a way forward, to steal Martijn's idea and put the numbers in:
| WMF Enginering will support all versions released in the past 6 months of
| those browser products with 4% or more overall market share, and any one
| browser version with more than 2%
However, this would mean (as of 23.11.2012):
Desktop:
Chrome 23 - 20
Firefox 16 - 13
MSIE 10 and 9 - 7 (own merits)
Safari (latest version only)
Opera 12.02 (own merits)
Tablet
Safari (latest version only)
Android (latest version only)
Mobile
Safari (latest version only)
Android 4 and 2.3 (own merits)
… which seems to be a little harsh on the mobile and tablet fronts, and overly-
generous on the MSIE side given their exceptional costs to support per %age of
users, but not too terrible.
(Note that I tweaked the input numbers from the suggestion so that they included
Android, which is 'just' 4.25%, and they ignore lots of older versions of Chrome
and Firefox with less than 0.5% useage.)
If this works for people, I'll put it up on
MediaWiki.org and start helping
colleagues to plan and justify their own local support matrices next week.
J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester