On Tue, Nov 27, 2012 at 4:37 AM, Roland Unger
<roland.unger(a)soziologie.uni-halle.de> wrote:
> we bought wikivoyage.com in September to transfer it to
> the WMF. Since October 7, 2012 it is hosted at Hetzner
> and shows to our association's servers.
Hi Roland,
yes, I'm aware - but it'd be good to point wikivoyage.com to the new
site, or to update the nameservers to ns[0-2].wikimedia.org so we can
do so, while we're waiting for the lock to expire.
Having it point to the read-only old site is highly confusing.
If nothing else, you could just disable it until it's transferred.
Thanks,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
On 27 November 2012 21:58, rexx <rexx(a)blueyonder.co.uk> wrote:
> The ability to turn this on or off for your browser is unfortunately hidden
> away in a tab in the 'Filter preferences ...' of ABP. There's also an
> individual whitelist there. It's probably worth reading the developer's blog
> at http://adblockplus.org/blog/typo-correction-feature-in-adblock-plus for a
> good overview of how it all works.
It looks like this feature is rather too enthusiastic.
metlife.com->fetlife.com ...
- d.
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…>
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…>
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
Adam Hyde from the booktype project will be in San Francisco in the
week of 12/10-12/14, so could potentially do an in-person brown bag
with remote participation on Thursday 12/13 in our usual weekly chat
time slot.
booktype is doing some interesting open source work to create book
quality rendering in the browser using open web technologies like CSS
regions, see BookJS: http://bookjs.net/
Some of this could be relevant to the future of MediaWiki technologies
that serve the same purpose (e.g. an alternative to the current
PediaPress mwlib library).
I'll ask him to do this in our weekly time slot if I can get at least
5 additional sign-ups here by the end of the week:
https://www.mediawiki.org/wiki/Meetings/Guest_speakers
Cheers,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hi, if you joined the MediaWiki / Wikimedia tech community in 2010 or
later please consider taking this survey:
Newcomer experience and contributor behavior in FOSS communities
https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151&lang=en
The survey is open for sporadic contributors or full time Wikimedia
employees, developers or any other profile. Anybody is welcome to
leave their feedback as long as you have started contributing to this
community in the past 3 years.
11 mature and well established open source projects are taking part in
this survey: Debian, FreeBSD, GNOME, Gentoo, KDE, Mozilla, NetBSD,
OpenSUSE, Python, Ubuntu and Wikimedia. Some of them started some days
ago and have more than hundred responses by now. The data of this
survey is anonymous and will be released under a ‘share-alike’ Open
Data Commons Open Database License (ODbL).
Some background:
>From Kevin Carillo, the researcher:
http://kevincarillo.org/survey-invitation/
>From OpenHatch, a non-profit working on the bridge between free
software projects and new contributors:
https://openhatch.org/blog/2012/a-research-project-to-understand-what-does-…
PLEA
If you, like me, became a bit tired of survey requests like this
please consider filling this one anyway. It focuses in a specific area
where we don't have much data. As fresh technical contributor
coordinator at the WMF I'm looking forward to the results of this
research and the lessons it will bring.
Thank you. :)
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation
TL;DR: Please add feedback to
<https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated>
Since MediaWiki 1.20 has been released, a discussion (opened by hexmode)
is ongoing on how to make our release notes better so that users
understand what improvements there are and why they should update:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/65080
(please join if you didn't yet).
Another problem, however, is making the tarball, which is what most
sites use, actually useful. After the first in 1.18, no more extensions
have been bundled: Wikimedia projects use no less than 140 extension
(most of them functioning) but the tarball ships only 7.
A problem that many MediaWiki users have is that they don't understand
how vital many extension are, at least for any wiki open to the web.
I'd like 1.21 to include some more, so I ask you to join the
brainstorming on our good old
<https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated>
There are already a few suggestions on it; my personal pet peeve is that
MediaWiki is perhaps the software with the best localisation existing
but very few use it well because we don't ship LocalisationUpdate.
Topic for another discussion would be to solve some problems with the
installer/upgrader like "set up cron for TorBlock" (?) or "check the
compatibility of extensions"...
Nemo
I received the same error when I visited
http://incubator.wikimedia.org/ , suggesting that I wanted to go to
incubator.wikipedia.org , and asking if I wanted to block
wikimedia.org
On Sat, Nov 24, 2012 at 11:46 PM, Andy Mabbett
<andy(a)pigsonthewing.org.uk> wrote:
> On 24 November 2012 16:41, Tom Morris <tom(a)tommorris.org> wrote:
>
>> AdBlock Plus has a facility to protect users from typosquatting
>> (as in, typing "poopal.com" rather than "paypal.com")
>>
>> http://cl.ly/image/0M1l1D0K1x0g
>
> Ouch.
>
>> Does someone want to work out how to complain to the relevant parties?
>
> Is there no facility to report false positives on their website?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> _______________________________________________
> Wikimedia UK mailing list
> wikimediauk-l(a)wikimedia.org
> http://mail.wikimedia.org/mailman/listinfo/wikimediauk-l
> WMUK: http://uk.wikimedia.org
--
John Vandenberg
Hello!
While working on my improvements to MediaWiki Import&Export, I've
discovered a feature that is totally new for me: 2-phase backup dump.
I.e. the first pass dumper creates XML file without page texts, and the
second pass dumper adds page texts.
I have several questions about it - what it is intended for? Is it a
sort of optimisation for large databases and why such method of
optimisation was chosen?
Also, does anyone use it? (does Wikimedia use it?)