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?
rupert.
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
Hello all,
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
position.
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
believed).
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
community. :-)
All best,
Erik
--
Erik Möller
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
same.
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
MediaWiki subsystem that delivers JavaScript and CSS to your browser.
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
bulk.
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
another.
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.
Why?
----
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
MediaWiki. Yes!!
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
improved latency.
But seriously,
--------------
* 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
either.
* 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
breakage. If you know how to use your browser's JavaScript console,
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.
---
Ori Livneh
ori(a)wikimedia.org
Hi folks,
This is an attempt to summarize the list of RFCs that are listed under
this cluster:
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_t…
...and possibly get a conversation going about all of this in advance
of the Architecture Summit.
The main focus of all of these RFCs is around HTML generation for user
interface elements. This category is not about wikitext templates or
anything to do with how we translate wikitext markup
"Template Engine" is Chris Steipp's submission outlining the use of
Twig. From my conversations with Chris, it's not so much that he's
eager to adopt Twig specifically so much as standardize on
*something*, and make sure there's usage guidelines around it to avoid
common mistakes. He's seen many attempts at per-extension template
libraries that bloat our code and often start off with big security
vulnerabilities. There are many extensions that use Twig, and it
seems to be a popular choice for new work, so Chris is hoping to
standardize on it and put some usage standards around it.
"HTML templating library" is Ryan Kaldari's submission, promoting the
use of Mustache or something like it. His main motivation is to have
a Javascript template library for front-end work, but is hoping we
choose something that has both Javascript and PHP implementations so
that any PHP template system implementation is compatible with what we
use for Javascript templating.
"MVC Framework" is Owen Davis's description of Wikia's Nirvana
framework, which has been central to all of the user-facing work
they've been doing for the past 2-3 years. As Owen points out in the
talk page for this, it's really view-controller rather than full MVC.
A big plus of adopting this RFC is that it would make it much more
likely that Wikia-developed extensions (of which there are many) would
be of greater use to the larger MediaWiki community, and would
generally help facilitate greater collaboration between Wikia and the
rest of us.
"OutputPage Refactor" is another submission from Owen Davis, which
isn't really about templating, so much as taking the HTML generation
code out of OutputPage. Wikia has been maintaining a fork of
OutputPage for quite some time, so they already have quite a bit of
experience with the proposed changes. This is clustered with the
templating proposals, since I imagine the work that gets factored out
of OutputPage would need to be factored into whatever templating
system we choose.
The first three seem somewhat mutually exclusive, though it's clear
our task is likely to come up with a fourth proposal that incorporates
many requirements of those three. The OutputPage Refactor proposal,
given some fleshing out, may not be controversial at all.
Where should we go from here? Can we make some substantial progress
on moving one or more of these RFCs over the next few weeks?
Rob
Hi,
during the 30C3 Congress [1] in Hamburg - where neither Wikipedia
Foundation nor MediaWiki were formally present this year (but should be
next year)-
Jacob Appelbaum [2] - core member of the TOR project - complained in one
of his numerous talks that the (edit) access to Wikipedia via TOR is not
possible.
He requested that a way should be found to enable the TOR access
including edit access to Wikipedia.
I am just the messenger of this message.
Regards,
Tom
[1] https://events.ccc.de/congress/2013/wiki/
[2] https://en.wikipedia.org/wiki/Jacob_Appelbaum
We needed to write an npm module for mediawiki oauth, and we're about to
publish it to the npm registry. I just wanted to check whether we had a
wikimedia account on https://npmjs.org/. If not, do we want one?
Users are very confused and worried any time a new version of wiki software
is launched and tested, and some major or minor bug comes invariably out.
A clear message using central sitenotice, with links to doc pages listing
the changes at different levels of detail and to their talk pages to
discuss them and to alert for bugs, is mandatory IMHO. Tech news are
largely insufficient; evidence of work in progress should be clearly
visible into all pages of interested projects. It's a basic matter of
Wikilove.
Alex