On Sun, Aug 25, 2013 at 7:46 PM, Yuvi Panda <yuvipanda(a)gmail.com> wrote:
> Hey rupert!
> On Sun, Aug 25, 2013 at 10:21 PM, rupert THURNER
> <rupert.thurner(a)gmail.com> wrote:
>> hi brion,
>> thank you so much for that! where is the source code? i tried to
>> search for "commons" on https://git.wikimedia.org/. i wanted to look
> Android: https://git.wikimedia.org/summary/apps%2Fandroid%2Fcommons.git
> iOS: github.com/wikimedia/Commons-iOS
>> if there is really no account creation at the login screen or it is
>> just my phone which does not display one, and which URL the aplication
> Mediawiki doesn't have API support for creating accounts, and hence
> the apps don't have create account support yet.
created https://bugzilla.wikimedia.org/show_bug.cgi?id=53328, maybe
you could detail a little bit more how this api should look like?
I would like to have an open IRC meeting for RFC review, on Tuesday 24
September at 22:00 UTC (S.F. 3pm).
We will work through a few old, neglected RFCs, and maybe consider a
few new ones, depending on the interests of those present.
The IRC channel will be #mediawiki-rfc.
-- Tim Starling
I’m delighted to announce that Ken Snider is joining the Wikimedia
operations team. He will start as an international contractor working
remotely from Toronto, Canada on June 10, and will be visiting SF in
the week of June 17. We’re currently in the process of seeking work
authorization in the United States in the Director of TechOps
CT has graciously agreed to support the ops leadership transition
full-time through June, and part-time through July. We’ll be starting
the handover while Ken is working remotely.
A bit more about Ken: Ken was apparently genetically predisposed to
become a sysadmin since he joined one of Canada’s first large ISPs,
Primus, straight out of school in 1997 and helped build their
infrastructure til 2001. He then joined a startup called OpenCOLA in
2001 which was co-founded by Cory Doctorow and developed early P2P
precursors to tools like BitTorrent and Steam. It’s best known today
for the development of an open source (GPL’d) cola recipe which is
still in use (more than 150,000 cans sold if Wikipedia is to be
Ken got involved in one of Cory’s pet projects, BoingBoing.net which
some of you may have heard of ;-), and has been their sysadmin since
2003. After a stint from 2001-2005 at DataWire, Ken became Director of
Tech Ops at Federated Media, a role he held from 2005-2012.
Federated Media is an ad network that was founded to support high
traffic blogs and sites that want to stay independent of large
publishers, with a network that supports more than 1B requests/day.
One of the unusual challenges at FM was that the company grew through
acquisitions of various blogging and publishing networks. This led to
the challenge of integrating very heterogeneous operations and
engineering infrastructure, including multiple geographically
distributed ops teams and data-center locations. As DTO, Ken led these
efforts, such as OS standardization, development of a unified
deployment infrastructure, etc. Ken also ensured that the operations
group partnered effectively with the various engineering teams
developing site features and enhancements.
I want to again take this opportunity to thank CT Woo for his tireless
operations leadership since December 2010. I’d also like to thank
everyone who’s participated in the Director of TechOps search process.
Please join me in welcoming Ken to the Wikimedia Foundation and the
VP of Engineering and Product Development, Wikimedia Foundation
Can we deprecate usage of '!ask' on IRC?
> ori-l: !ask
> wm-bot: Hi, how can we help you? Just ask your question.
It's annoying when people ask to ask, but the people who do so do it out of
insecurity or lack of experience, and so they're the last people we should
be siccing our bots on.
I've used '!ask' a lot before but I'm going to stop. I hope others do the
The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
inaugurate the era of ResourceLoader module storage -- an era which
will be marked by terrifying and hilarious new bugs, intermittent
client-side failures, and generally inexcusable disruptions to user
experience. Sounds exciting? Read on!
What is it?
"Module storage" refers to the use of localStorage in ResourceLoader
as an auxiliary to the browser cache. ResourceLoader, remember, is the
One of its primary functions is to minimize the total number of
network requests that your browser needs to make in order to render
the page, and to make the remaining requests as slim as possible. One
of the ways ResourceLoader does this is by making a list of all the
different components your browser needs and then transmitting them in
The downside of this approach is that a small update to MediaWiki's
code, touching perhaps one or two components, will often force the
browser to throw out (and re-retrieve) a bunch of unrelated modules
that did not change and did not ostensibly need to be re-retrieved.
This is because the browser cache operates on the level of network
requests; it is not intelligent enough to decompose a request into its
constituitive parts and to cache these parts separately from one
Starting with the 1.23wmf2 branch, ResourceLoader will check if your
browser implements localStorage, a mechanism for storing structure
data. If it does, ResourceLoader will use it as an auxiliary cache,
capable of versioning individual components.
The primary goals are:
* Destabalize MediaWiki's front-end code, by coupling it to an
inconsistently-implemented and poorly-understood HTML5 API.
* Make debugging fun again, by adding another layer of caching to
However, as with all new features, unintended side-effects are
possible. Specific concerns for module storage include the risk of
making the network footprint of page loads smaller, resulting in
* Module storage is enabled only if the underlying browser supports
localStorage (~89% of browsers in use, according to
<http://caniuse.com/#feat=namevalue-storage>). Users with older
browsers will not see a benefit, but they will not suffer a penalty
* Module storage may or may not improve site performance. We need to
test it against a wide range of browsers and platforms to know for
certain. If it doesn't improve performance, we'll blame it on you,
your poor choice of browsers, and your uncooperative attitude, but
then we'll scrap it.
How can I test it?
Glad you asked! Module storage is enabled by default on the beta
cluster, and on test & test2 wikis. The simplest way you can help is
by being alert to to performance regressions and front-end code
you can get stats about module storage usage on the current page by
checking the value of 'mw.loader.store.stats'.
When the code is rolled out across the cluster, it will be disabled by
default, but you will be able to opt-in by manually setting a cookie
in your browser. I will follow up with the exact details. If module
storage proves stable enough for production use, we'll seek to asses
its utility by running a controlled study of some kind. If we can
demonstrate that module storage leads to a significant improvement in
performance, we'll enable by it default.
Hi, Google Code-in is about to start:
We have currently 72 tasks published and 13 mentors. We are still
looking for more mentors and tasks. If you are interested, contact me.
This is the first time Wikimedia participates in this program and the
only certain prediction at this point is that we all will learn a lot.
We have been warned that especially the first two weeks will be quite
messy, with many impatient newcomers landing in our community channels
and asking for help / feedback / review. Please be kind with them.
Things will eventually settle down, partially because our documentation
will be better, partially because the students interested in Wikimedia
will be familiar with the basics and will know where/how to ask.
Ideally https://www.mediawiki.org/wiki/Google_Code-In should contain
answers and links to answers for the frequently asked questions. Try to
answer GCI students with links to the appropriate pages, and try to
assure that such links are available at our GCI wiki page.
Thank you for your patience. I have no doubt that your direct or
indirect help will pay off with better documentation for all kinds of
newcomers interested in many areas of contribution.
/me goes to prepare a hot beverage. It is going to be fun.
Technical Contributor Coordinator @ Wikimedia Foundation
As many of you might be aware, etherpad.wikimedia.org has been
migrated a couple of months ago from the old and no longer supported
etherpad software to the new, actively supported, etherpad-lite
software. The move also involved the migration of pads from the old
software to the new, a process which was quite successful, albeit not
without glitches. Since then the old installation has been kept around
under http://etherpad-old.wikimedia.org in a read-only state in order
to facilitate people to access pads that, for whatever reason, may not
have made it to the new installation unscathed (or at all). This
service will be discontinued and taken offline on Monday, 30 December
2013. That grants 30+ days to people to copy out any necessary pads.
With that in mind, the operations team would like to remind everyone
that etherpad.wikimedia.org was never intended to be a permanent
storage for pads. Preservation of a pad is up to the people interested
in preserving that pad in another format.
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
As folks may be aware, over in the Wikimedia Mobile Apps team we're
starting a refresh of the Wikipedia mobile apps for Android and iOS, which
have not been updated in a while and are now wayyy behind the mobile web in
features and UI awesomeness.
The new apps are using native UI around the content web view, which lets us
integrate with the system better than the old PhoneGap-based HTML app, and
provide long-desired features like pinch-to-zoom in the article view.
Our first 2-week work sprint is finishing up, and builds of current state
* iOS: on testflightapp.com (email notifications sent to our recently
trimmed beta list)
Both versions are pretty bare-bones, so don't be surprised by missing
icons, toolbar buttons that don't work, or incomplete design. :)
This first feature sprint concentrated on getting search & basic content
loading working. You can type into the search box, the search results
include thumbnails, and you can select a search result to load the article.
You can also click on internal links in both iOS and Android versions,
though they get a little flaky from there out. :) Back/forward is not yet
implemented on iOS; back works on Android but there's no forward.
Note also the pretty animation when following links on Android -- neat!
Next sprint's release should look more polished, as we'll have some more
navigation working, and the first sprint stuff prettied up to better match
For in-progress design & UX ideas for the new app, see
Note that you may or may not need to manually uninstall the old app if it's
If you want to try the iOS version and aren't on the beta list you'll have
to build it yourself on a Mac with XCode 5, and then you can only install
it on your device if you are a registered iOS developer (thank Apple's
restrictions on third-party app installations!):
$ git clone https://gerrit.wikimedia.org/r/apps/ios/wikipediaapps-ios-wikipedia
(Unfortunately we cannot add new people to the iOS beta list until Apple
clears out old entries from our 100-max device database, either at the end
of the calendar year or in February when our membership rolls over. Yeah,
And of course you can build the Android version too, and run it with no
$ git clone https://gerrit.wikimedia.org/r/apps/android/wikipediaapps-android-wikipedia
Note that there's separate work going to revitalize the Wikipedia app for
Firefox OS, which will remain HTML5-based as that's how native Firefox apps
work! That's being spearheaded by the Wikimedia Mobile Partnerships &
Wikipedia Zero team.
The Architecture Summit will be upon us in less than two months. To make
sure that this Summit is going to be productive it is important that we
discuss the right RfC's. Before deciding which RfC's should be discussed at
the Summit I want to make sure that
https://www.mediawiki.org/wiki/Requests_for_comment contains all RfC's and
that all important topics have an RfC.
If you have a Mediawiki related RfC in a personal notepad, on your User
Page, in your mind then this would be a great moment to write or move it
under https://www.mediawiki.org/wiki/Requests_for_comment and add an entry
to the table. If you don't have 'move' rights then please let me know and I
can move it for you.
If you know of a topic that *should* have an RfC but does not yet have an
RfC then please reply to this list mentioning the topic. I will check with
Tim/Brion to see how these topics can get an RfC.
Once we have collected all relevant RfC's under
https://www.mediawiki.org/wiki/Requests_for_comment then I will make a page
where everybody can express their interest in which RfC's should be
discussed at the Summit.
Questions? Let me know!
Several MediaWiki extensions, such as Maps and Semantic MediaWiki, are now
installable via Composer. Lately I've been getting quite a few questions
from developers on how to have their extensions support this awesome
dependency manager, and decided to write down the most important points
that are not obviously evident in the Composer documentation down.
Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3