Moving to mobile-l. Discuss.
-Adam
On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> cc. reading-list. You'll get more feedback there :)
> Short reply: There are lots of bugs and larger problems here that need
> to be solved.
>
>
> On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers <jrogers(a)wikimedia.org>
> wrote:
> > Hi Jon,
> >
> > James A suggested you might be the right person to talk with about
> improving
> > the readability of the WMF privacy policy on mobile devices. Currently,
> it's
> > pretty difficult to look at. It starts with the massive language list,
> the
> > disclaimer renders 1-2 words a line, and the blue boxes also render in
> hard
> > to read lines as well as pushing the main section to scroll off the
> screen.
> >
> > If you are the right person, what I'm hoping we can do is make the
> language
> > list into an expandable menu, get rid of the blue boxes on the sides if
> > necessary, and possibly make the examples into an expandable view rather
> > than have everything shown by default.
> >
> > If you're not the right person to this, could you forward me on to
> someone
> > that might be able to help?
> >
> > Many thanks,
> > Jacob
> > --
> >
> > Jacob Rogers
> > Legal Counsel
> > Wikimedia Foundation
> >
> > NOTICE: This message might have confidential or legally privileged
> > information in it. If you have received this message by accident, please
> > delete it and let us know about the mistake. As an attorney for the
> > Wikimedia Foundation, for legal/ethical reasons I cannot give legal
> advice
> > to, or serve as a lawyer for, community members, volunteers, or staff
> > members in their personal capacity. For more on what this means, please
> see
> > our legal disclaimer.
> >
>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
*** CALL FOR PAPERS ***
The Second International Conference on Digital Information Processing, Data
Mining, and Wireless Communications (DIPDMWC2015)
Islamic Azad University, Academic City, Dubai
Dubai, UAE
December 3-5, 2015
http://sdiwc.net/conferences/dipdmwc15/
All registered papers will be included in SDIWC Digital Library.
===========================================================
The conference aims to enable researchers build connections between
different digital applications.
The event will be held over three days, with presentations delivered by
researchers from the international
community, including presentations from keynote speakers and
state-of-the-art lectures.
RESEARCH TOPICS ARE NOT LIMITED TO:
• Digital Information Processing
Adaptive Signal Processing
Artificial Intelligence
Bioinformatics & Biomedical Imaging
Natural Language Processing
Computer-Aided Surgery
Speech Recognition, Analysis and Synthesis
Biometric and Pattern Recognition
Face Recognition and High-Resolution Imaging
Network and Cyber Security
E-Learning
E-Marketing
Parallel Programming & Processing
Expert Systems
Information Security and Cryptography
Multimedia Signal Processing
Biomedical Signal Processing
Neural Networks and Genetic Algorithms
Data Compression and Watermarking
Energy Minimization in Cluster-Based Wireless Sensor Networks
Video Compression and Streaming
Object Detection, Recognition and Categorization
Data Modeling for Cloud-Based Networks
E-Commerce
E-Banking
•Digital Information Processing
Data Mining Techniques
Risk Management and Analysis
Multi-Task Learning
Data Cleaning and Processing
Data Mining for Complex Dataset
Data Mining for Customer Retention
Data Mining for Business Intelligent
Data Mining for Network Intrusion Detection
Online Algorithms for Data Mining
Ethics of Data Mining
Data Classification and Clustering
Feature Extraction and Data Reduction
Optimization Techniques
Text and Web Mining
Data Mining for Network/Cyber Security
Data Mining for Climate Change and Impacts
Data Mining for Social Network Analysis
Data Mining for Traffic Control
Data Mining and Cloud Computing
•Wireless Communication
Energy Minimization in Cluster-Based Wireless Sensor Networks
Coding and Modulation
Vehicular Wireless Networks
Wireless Sensor Networks
Wi-Fi and Wi-MAX B3G/ 4G Wireless Networks
Bluetooth and Personal Area Networks
Mobile Management in Wireless Networks
IP Multimedia Sub-Systems
Mobile/ Wireless Network Modeling and Simulation
Wireless Network Standard and Protocols
Bioinformatics and Scientific Computing
Mobile IP Networks/ Ad-hoc Networks
Security and Robustness in Wireless Networks
Network Management
Wireless Local Area Networks
Wireless System Architecture
Mobile Database Access and Design
Key Management Protocols
Mobile / Wireless Network Planning
Digital Right Management and Multimedia Protection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMPORTANT DATES:
Submission Deadline : Open from now until October 30, 2015
Notification of Acceptance: 3- 4 weeks from the submission date
Camera Ready Submission : Open from now until November 15, 2015
Registration Deadline : Open from now until November 15, 2015
Researchers are encouraged to submit their work electronically.
All papers will be fully refereed by a minimum of two specialized referees.
Before final acceptance, all referees comments must be considered.
Paper Submission:
http://sdiwc.net/conferences/dipdmwc15/openconf/openconf.php
Registration: http://sdiwc.net/conferences/dipdmwc15/registration
Conference Email Ad: dipdmwc2015(a)sdiwc.net
The Reading Web team will be taking time every Monday to QA the mobile site.
We're currently lining up work around improving our development, testing,
and release processes. In fact, work on improving our browser testing
infrastructure has already begun [0]. This work is all about reducing the
size of a critical feedback loop: from a developer submitting a patch to a
bug being reported. Taking a day every sprint to QA each others work on the
beta cluster isn't ideal but it does help us to reduce the size of the
feedback loop until we're finished improving our workflows.
Here's what I sent out to the team members in the QA Day invite:
According to the deployment schedule [1], our latest and greatest code will
> be hitting group 0 wikis on a Tuesday. I strongly encourage you to take the
> time to test a few common and uncommon workflows across the myriad features
> new and old and report any bugs you uncover before the train starts
> rolling. You might also want to take a look at a few of the group 0 wikis
> on Tuesday too while our development environments don't replicate that of
> production. If you find the time after all of this, then perhaps you could
> try translating one or two workflows into browser tests (!!!)
[0] https://phabricator.wikimedia.org/T100293
[1] https://wikitech.wikimedia.org/wiki/Deployments/One_week
<https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2F…>
We've been stalled for years on adding media playback to the Wikipedia iOS
app due to the impasse between Wikimedia's insistence on free formats and
Apple's insistence on only supporting patented formats.
I'm trying to route around that impasse by getting Ogg and WebM playback up
and running on iOS through a native widget library, which I've been
cleaning up to ready it for CocoaPods packaging.
Here's the high-level library:
https://github.com/brion/OGVKit
and provisional CocoaPods specifications for the low-level open-source
libraries it needs:
https://github.com/brion/OGVKit-Specs
Once I finish some further fixes and do an API cleanup (version 0.5 on my
provisional milestones <https://github.com/brion/OGVKit/milestones>) I plan
to publish my podspecs and write a patch to the Wikipedia app that uses
OGVKit to handle media playback.
Rough patch plan:
* add OGVKit as dependency
* enhance the photo carousel view to instantiate a player view for
audio/video files, just like on Android
* add content CSS to clean up those video thumbnail 'Play media' links
* add a JS click handler for 'Play media' links to launch the carousel
* add a JS click handler for <audio> and <video> elements in content
* add a bunch of libraries to the list on the about page
Ideally this should be a "surgical" patch and relatively minimal, though an
update of the Pods dir will pull in a lot of files. :)
-- brion
Cross posting. Really neat stuff!
-Adam
---------- Forwarded message ----------
From: Timo Tijhof <ttijhof(a)wikimedia.org>
Date: Thu, Jun 25, 2015 at 10:05 AM
Subject: [Ops] How Flickr improved image scaler performance
To: ops Wikimedia List <ops(a)lists.wikimedia.org>
Flickr shared their story about speeding up resizing of images to near
real-time.
http://code.flickr.net/2015/06/25/real-time-resizing-of-flickr-images-using…
TL;DR:
* Switch to GraphicsMagick a mature fork of ImageMagick (started in 2002)
that is more efficient, smaller code base, more secure, runs faster. (Also
used by Etsy).
* Switch again, to Ymagine. Another 2X improvement over GraphicsMagick.
* Switch again, to a GPU-based tool. Another 4X improvement. This GPU tool
doesn't appear to be open-sourced, however.
* Only reliably store thumbnails of 2048px (if the original is larger).
Generate the rest on-the-fly (from the 2048 one), with HTTP caching only.
http://www.graphicsmagick.org/http://www.graphicsmagick.org/benchmarks.htmlhttps://github.com/yahoo/ygloo-ymagine
— Timo
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops
Moving this discussion to mobile-l. Ori, are you on mobile-l?
Let's also be mindful to model (client side or router rate limiting is
easiest) realistic connection scenarios (i.e., 2G and 3G and clogged wifi
connections). Shaving off 3-4 seconds on fast connections makes a world of
difference, and so does shaving off 10-15 seconds on slow ones, for getting
the user to be able to interact with the page.
-Adam
On Thu, Jun 25, 2015 at 5:10 AM, Joaquin Oltra Hernandez <
jhernandez(a)wikimedia.org> wrote:
> Hi,
>
> Ori Livneh, Sam Smith, Adam Basso and Joaquin Hernandez met to further
> talk about the performance work that's being scheduled for the following
> quarter.
>
> I've parsed my notes and written down what I've learned, and wanted to
> share them to create a shared understanding of how this planning is going.
> Not sure if this should go to other more public mailing lists at this
> stage, feel free to share wherever you think it should go.
>
>
> - Don't brainstorm and blindly implement ideas. Usually any ideas we
> can come up with will imply complex changes (like only loading the lead
> section) but won't have the expected return.
> - Measure and report, identify key metrics.
> - Performance work is hard to measure (predict outcomes) beforehand,
> you usually never know how it's going to unfold.
> - Suggested workflow is: 1. Measure and analyze. 2. Formulate
> hypothesis based on concrete data. 3. Implement hypothesis and goto 1.
> - Seems like for being effective on accomplishing performance
> goals, a continued effort through quarter will be needed (considering ^
> previous point) instead of a laser focused half quarter effort.
> - Broad first-sight insights:
> - Server side time (only accountable if cache miss or logged in) is
> negligible compared to other factors.
> - Browser side performance is mobile's site biggest bottleneck.
> Roughly half time (~2s) parsing script and (~3s) rendering.
> - Looks like there's wins to be gained from optimizing on
> browser performance.
> - We need to research and communicate before hypothesizing.
> - Tools:
> - Besides Grafana dashboards using the graphite data we'll
> coordinate with the Performance team to track other types of metrics coming
> from other tools like,
> - Speedcurve.com for browser/front-end based performance reports.
> - Maybe sitespeed.io for tracking regressions.
> - How to do it:
> - Measure, establish baseline data.
> - Plan hypothesis.
> - Implement, local measuring. If good deploy.
> - Measure with change deployed. Evaluate impact. Write down results.
> - Go to 1 or 2.
>
> Going forward we'll be communicating and syncing regularly with the
> performance team on our data, hypothesis, plans and results to stay in sync
> and help each other. (Is there a performance mailing list? Should we use
> wikitech-l?).
>
> Regarding numbered metrics and considering what we learned from these
> meetings it is going to be hard to set numbers for the goals to reach,
> we'll do our best and communicate back.
>
> Cheers
>
> ps: If I've mistaken or missed anything on my notes please call me out on
> it and correct me!
>
>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
> It's currently working via a script that you can find here:
> /srv/mediawiki/extensions/Gather/tests/browser/Barry.sh
It would be great to have the script in a public version control system (e.g. github?), especially for people, e.g. volunteers, who can't ssh to gather-browser-tests.eqiad.wmflabs[1]
[1] all people, who're not members of https://wikitech.wikimedia.org/wiki/Nova_Resource:Mobile-smoketests
Best,
Florian
-----Original-Nachricht-----
Betreff: [WikimediaMobile] [Update] Browser tests per patch
Datum: Thu, 18 Jun 2015 03:27:32 +0200
Von: Jon Robson <jrobson(a)wikimedia.org>
An: "QA (software quality assurance) for Wikimedia projects." <qa(a)lists.wikimedia.org>, mobile-l <mobile-l(a)lists.wikimedia.org>
Background: mobile wants to gain more confidence in its browser tests
by running a subset of browser tests on a case by case basis [0].
Good news: I've got a proof of concept running and Barry the browser
test bot has given some legitimate helpful reviews to Gather [1].
Even better news: It's proving itself valuable already [2].
As you can see in the messages the bot has posted on [3] we have a
couple of options on display option format for his reviews.
So.. hopefully this short experience has sold you all already.
This script is currently a manual job and needs a bit of tweaking
before we can put it in a cron job/run it always - it needs to watch
for new commits and then run a modification of the above script on a
per case basis (if two versions of it run in parallel we have an
issue).
Definitely something we should push for next sprint!
Long live Barry bot!
Devs... (everyone else now of what follows is likely to be useful):
I got the labs instance up and running on:
http://gather-browser-tests.wmflabs.org/wiki/Main_Page
Most of you in readership team should be able to ssh
gather-browser-tests.eqiad.wmflabs
Let me know if you have no access.
It's currently working via a script that you can find here:
/srv/mediawiki/extensions/Gather/tests/browser/Barry.sh
[0] https://phabricator.wikimedia.org/T100293
[1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c…
[2] https://gerrit.wikimedia.org/r/#/c/218731/
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
+mobile-l
Hi Android devs,
For non-Android devs who are wondering what the issue is: Android string
resource syntax for parameters is based on Java + printf syntax. So, we end
up with parameter placeholders like %s %2$s %.2f . Some translators just
think they can use $1, $2, like with PHP or iOS.
Looks like the days of invalid parameter formats from translators are
numbered, or at least the likelihood will be reduced since
https://gerrit.wikimedia.org/r/#/c/220418/ got deployed a few minutes
ago. While
we have an automated test for that in the Android test suite, it's better
to have the checks run closer to the source.
According to Niklas:
> Translators see warning above the text area about incorrect or missing
> parameters while they are translating. Checks also get run when translation
> is saved and updated, and the translation is marked as fuzzy/outdated if
> the checks fail.
Cheers,
Bernd
Hello everyone - our latest and greatest as just gone live in the app
store. You can check it out here:
https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8
This release has further UX refinements, better visibility of article
translations, and several stability improvements (Fixed a nasty crash bug
for our users in Norway)
Please check it out and let us know what you think.
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation