On Nov 21, 2012 7:13 AM, "Leslie Carr" <lcarr(a)wikimedia.org> wrote:
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester
<jforrester(a)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&a…
> 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
I think a best of both worlds would be preferable. I haven't seen the
stats, but I'd assume market share of IE 10 will be quite low. Still it
would be silly to not strive to support it. How about any browser released
in the last n months whose browser family has more then x % market share
plus any individual browser version with more then m % market share for
some sensible figures n, x and m?
> * 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…
> 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.
jforrester(a)wikimedia.org | @jdforrester
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l