Hi all,
I've been working on a project to improve the categorization of
pictures in the Upload to Commons Android app
<https://phabricator.wikimedia.org/T115101> as part of the Outreachy
Dec '15 program, which is soon drawing to an end. To summarize, 3 new
features have been implemented in this app:
1. If a picture with geolocation is uploaded, nearby category
suggestions are offered (based on the categories of other Commons
images with similar coordinates)
2. If a picture with no geolocation is uploaded, nearby category
suggestions are offered based on the user's current location. This is
optional and only works if enabled in Settings.
3. Category search (when typing in the search field) has been made
more flexible, whereas previously this was done solely by prefix
search. E.g. now searching for 'latte' should be able to return 'iced
latte'.
The latest version of the app is v1.11 and can be downloaded at
<https://play.google.com/store/apps/details?id=fr.free.nrw.commons>.
Please feel free to leave feedback or bug reports at
<https://github.com/nicolas-raoul/apps-android-commons/issues>.
I have had an amazing time working on this app as part of the
Outreachy program, and I greatly appreciate all the support and help
that the WMF community has given me. :)
Cheers!
--
Regards,
Josephine
A significant update to https://phabricator.wikimedia.org is coming tonight!
I will be taking Phabricator offline for a short time during the regularly
scheduled maintenance window. This will take place between 01:00 - 03:00
UTC (5:00PM-7:00PM Pacific)
There are a whole lot of new features and bug fixes coming with this
update. Here are some of the most important bug fixes and requests for new
functionality which can will resolved after the update:
- T84833: When you close an unassigned task as "Resolved" from the
Comment action, Phabricator thinks you want to claim the task
<https://phabricator.wikimedia.org/T84833>
- T89675: Phabricator avatars should have high definition version for HD
displays <https://phabricator.wikimedia.org/T89675>
- T119708: setting security to software security bug excluded subscribers
<https://phabricator.wikimedia.org/T119708>
- T89335: Creating private tasks by filling a web form (for AffCom)
<https://phabricator.wikimedia.org/T89335>
- T876: @mentions in descriptions should autocomplete
<https://phabricator.wikimedia.org/T876>
- T77228: Let non-members watch projects
<https://phabricator.wikimedia.org/T77228>
- T87135: Phabricator should only notify changes to the "Security" field
if it is indeed changed <https://phabricator.wikimedia.org/T87135>
- T120903: investigate hiding the policy controls for phabricator
projects. <https://phabricator.wikimedia.org/T120903>
- T91529: Turning the sprint flag on should apply the expected icon and
color to the project <https://phabricator.wikimedia.org/T91529>
- T115017: For new Phab accounts, link to [[mw:How to report a bug]] at
the top of task creation form <https://phabricator.wikimedia.org/T115017>
- T91538: Make new tasks within a specific project use a template in
description field <https://phabricator.wikimedia.org/T91538>
For context, there has been some ongoing discussion about potential issues
at https://phabricator.wikimedia.org/conpherence/308/ - further
documentation of the changes and their implications will be published soon.
If you notice any serious issues after the update, please report them in
phabricator or via IRC in the #wikimedia-devtools channel, however, please
wait until the maintenance window is over before reporting any issues -
problems encountered during the maintenance window are to be expected and
reporting them will only serve as a distraction while the upgrade is
underway.
Thanks for your patience!
Mukunda Modell
Phabricator Release Engineer
Wikimedia Foundation
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-02-17
= 2016-02-17 =
== Technology ==
=== Analytics ===
* '''*Blocking'''*:
** Discovery with a pageview API bug: T127034, Dan is working on it right
now
** Multimedia with dumps parsing asks: T126808, T126809, Analytics will
triage hopefully soon (within one or two weeks, but backlog is huge)
* '''*Blocked'''*
** Services (known) because we need to refactor / move AQS (Analytics Query
Service) out of the restbase repo
* '''*Updates*'''*:*
** Same as last time, nothing new is ongoing
-
=== Architecture ===
[No update.]
=== Performance ===
[No update.]
=== Release Engineering ===
* '''*Blocking'''*:
** Nothing new
* '''*Blocked'''*:
** Looking for review on Phabricator ops/puppet role cleanup. See
https://phabricator.wikimedia.org/T125851
** Looking for a merge from Ops on scap3 provider changes. See
https://phabricator.wikimedia.org/T127215
* '''*Updates*'''*:*
** See wmf.14 group1 deployment blockers
https://phabricator.wikimedia.org/T125597
*** Save latency regression
** Progress on JS-based end-to-end (browser) tests in core. See
https://gerrit.wikimedia.org/r/#/c/256404/
=== Research ===
* '''*Blocking'''*:
** Nothing
* '''*Blocked'''*:
** ORES still blocked on Ops. See https://phabricator.wikimedia.org/T106867
* '''*Updates*'''*:*
** Reader survey test went live 16 Feb in 16:00-17:00 PST SWAT time (5:100K
sampling): for QA purposes
** Reader survey at full rate will go out 17 Feb 8:00-9:00 PST, for less
than 2 weeks, at a 1:500 sampling rate:
https://meta.wikimedia.org/wiki/Research:Characterizing_Wikipedia_Reader_Be…
=== Security ===
* '''*Blocking'''*:
** Nice to have: https://phabricator.wikimedia.org/T125382 (Maps)
* '''*Blocked'''*:
** None.
* '''*Updates*'''*:*
** 2FA for wikis progressing
** Security patches
=== Services ===
* '''*Blocking'''*:
** Nobody
* '''*Blocked'''*:
** Separate AQS off of RESTBase - https://phabricator.wikimedia.org/T126294
*** need to schedule a time with Analytics Ops for the move
** Mathoid - SVG to PNG support
*** librsvg(-dev) for Jessie
* '''*Updates*'''*:*
** RESTBase: dropping listing URIs (/pagr/html/ , ...)
** Cassandra multi-instance work _still_ undergoing
=== Technical Operations ===
* '''*Blocking'''*:
** ORES moving into production, finally hardware is in place
* '''*Blocked'''*:
** Nothing
* '''*Updates*'''*:*
** Ongoing discussions/work about the switchover goal
** Moved with LE cxserver to jessie and node 4.2
== Product ==
=== Community Tech ===
* '''*Blocking'''*:
** Nothing
* '''*Blocked'''*:
** Gadgets 2.0 - blocked on ResourceLoader cache invalidation issue
(Performance team) - https://gerrit.wikimedia.org/r/#/c/269901/
* '''*Updates*'''*:*
** PageAssessments
=== Discovery ===
; '''*Blocking'''*:
** none
; '''*Blocked'''*:
** none
; '''*Updates*'''*:*
** Building more analytics about user satisfaction in completion
** TextCat merged, A/B tests to follow
** WDQS Blazegraph 2.0 work still in progress, getting there
** Discussing adding caching layer, for ops attention:
https://phabricator.wikimedia.org/T126730
** Discussing QuickSurvey with ops
==== Maps & Graphs ====
*; '''Updates'''*
* Kartographer (maps) launched on beta cluster, getting ready to enable it
on Wikivoyage
** VE has been helping, thanks Ed Sanders
* Graphs can support WDQS, but might need caching (N.B. Operations)
* Created a page-views graph - can be placed on a talk page to show
corresponding view for the past N days.
https://en.wikipedia.org/wiki/Template:Graph:PageViews
*; '''Blockers'''*
* Security: need SVG sanitization lib review (Security) -
https://phabricator.wikimedia.org/T125382
** Note that Performance were thinking of shipping sanitised user-provided
SVGs to clients (instead of server-rendered PNGs), which would also need
this functionality.
*** Are we sanitizing SVG on upload/download? Or do we always convert them
in a sanbox env to PNG?
**** RIght now in production we always convert in a sandbox to PNG for
normal page views, and (?) don't sanitise at all for download of the
original SVG (on file pages).
**** We sanitize on upload, mostly show PNG's in articles. Raw svg's are
served from upload.wm.o (untrusted domain)
=== Editing ===
==== Collaboration ====
* '''*Blocking'''*:
** Dry run patch for external store migration is merged. Now we need to
set External Store up on Beta, then test the dry run patch there:
https://phabricator.wikimedia.org/T119567
* '''*Blocked'''*:
** Flow dump generation on dumps.wikimedia.org:
https://phabricator.wikimedia.org/T119511
* '''*Updates*'''*:*
** Human-readable name patch is almost done:
https://phabricator.wikimedia.org/T121936
** Will be enabling cross-wiki notifications on first set of wikis soon (
https://gerrit.wikimedia.org/r/#/c/265413/)
==== Language ====
* '''*Blocking'''*:
** Apertium packages?
* '''*Blocked'''*:
** None.
* '''*Updates*'''*:*
** cxserver migrated to Jessie with help of Alex
==== Multimedia ====
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** Thumbor deployment blocks ImageTweaks deployment. Currently not a
problem, as ImageTweaks is still rough.
** Security review of ImageTweaks pending, not currently ready to go, would
like it to happen sometime this quarter ideally - more updates coming.
https://phabricator.wikimedia.org/T126492
** Illustration metrics "blocked" but not urgent.
https://phabricator.wikimedia.org/T126809https://phabricator.wikimedia.org/T126808
* '''*Updates*'''*:*
** Labs instance with ImageTweaks and Thumbor currently up and running, a
bit of a demo as to what's coming to the cluster. See
http://multimedia-alpha.wmflabs.org/wiki/index.php/Main_Page
** OOUI performance issues being worked on by MatmaRex, as part of
UploadWizard performance improvements.
==== Parsing ====
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** None
* '''*Updates*'''*:*
** Work ongoing setting up mass visualdiff testing of rendering between 2
different mediawiki versions -- will appreciate help / feedback setting up
mediawiki VMs (one per wiki) that closely reflects production config
(extensions, skins, etc.). Currently considering vagrant, as well as manual
setup (via scripts).
** Awaiting additional reviews / merge on the path to serialize HTML while
using TemplateData settings (hopefully this week) -- first round of
reviewing and edits done.
==== VisualEditor ====
* '''*Blocking'''*:
** None.
* '''*Blocked'''*:
** Waiting on Design Research availability for user testing of Single Edit
Tab integration
* '''*Updates*'''*:*
** Will release the Single Edit Tab integration to a single wiki next
Tuesday (huwiki) and assess impact
** Working with *Performance* on assessing the performance impact of OOUI
on all read pages https://gerrit.wikimedia.org/r/#/c/271144/ – will update
next week on results.
** Otherwise, we're working on performance issues, bugs, and language
support, as normal.
=== Fundraising Tech ===
No blockers, most work is continued from last week
* Implemented updates for new CiviCRM financial tracking, filling in the
last missing pieces
* fixes and enhancements for backup credit card processor
* prep for Latin America fundraising expansion
* beefing up fraud filters
=== Reading ===
==== Android ====
* '''*Updates*'''*:*
** v2.1.141 published. Includes A/B test of readmore results.
==== Web ====
* '''*Updates*'''*:*
** Exploring surfacing references via API / lazy loading in web (see
https://phabricator.wikimedia.org/T123328) - making headway
==== Reading Infrastructure ====
* Nothing of note this week.
Thank you! I use regularly use this app and improvements are always
welcome.
On Wed, 17 Feb 2016 00:48:53 -0500, Josephine Lim
<josephinelim86(a)gmail.com> wrote:
> Hi all,
> I've been working on a project to improve the categorization of
> pictures in the Upload to Commons Android app
> <https://phabricator.wikimedia.org/T115101> as part of the Outreachy
> Dec '15 program, which is soon drawing to an end. To summarize, 3 new
> features have been implemented in this app:
>
> 1. If a picture with geolocation is uploaded, nearby category
> suggestions are offered (based on the categories of other Commons
> images with similar coordinates)
>
> 2. If a picture with no geolocation is uploaded, nearby category
> suggestions are offered based on the user's current location. This is
> optional and only works if enabled in Settings.
>
> 3. Category search (when typing in the search field) has been made
> more flexible, whereas previously this was done solely by prefix
> search. E.g. now searching for 'latte' should be able to return 'iced
> latte'.
>
> The latest version of the app is v1.11 and can be downloaded at
> <https://play.google.com/store/apps/details?id=fr.free.nrw.commons>.
> Please feel free to leave feedback or bug reports at
> <https://github.com/nicolas-raoul/apps-android-commons/issues>.
>
> I have had an amazing time working on this app as part of the
> Outreachy program, and I greatly appreciate all the support and help
> that the WMF community has given me. :)
>
>
> Cheers!
>
>
--
Baha
Now that we target PHP 5.5, some people are itching to make use of some new
language features, like the new array syntax, e.g.
<https://gerrit.wikimedia.org/r/#/c/269745/>.
Mass changes like this, or similar changes relating to coding style, tend to
lead to controversy. I want to make sure we have a discussion about this here,
to avoid having the argument over and over on any such patch.
Please give a quick PRO or CON response as a basis for discussion.
In essence, the discussion boils down to two conflicting positions:
PRO: do mass migration to the new syntax, style, or whatever, as soon as
possible. This way, the codebase is in a consistent form, and that form is the
one we agreed is the best for readability. Doing changes like this is
gratifying, because it's low hanging fruit: it's easy to do, and has large
visible impact (well ok, visible in the source).
CON: don't do mass migration to new syntax, only start using new styles and
features when touching the respective bit of code anyway. The argument is here
that touching many lines of code, even if it's just for whitespace changes,
causes merge conflicts when doing backports and when rebasing patches. E.g. if
we touch half the files in the codebase to change to the new array syntax, who
is going to manually rebase the couple of hundred patches we have open?
As can be seen on the proposed patch I linked, several of the long term
developers oppose mass changes like this. A quick round of feedback in the
architecture committee draws a similar picture. However, perhaps there are
compelling arguments for doing the mass migration that we haven't heard yet. So
please give a quick PRO or CON, optionally with some rationale.
My personal vote is CON. No rebase hell please! Changing to the syntax doesn't
buy us anything.
-- daniel
Hello!
MediaWiki-Codesniffer 0.6.0 has been released, here's what's changed:
* Add Generic.Arrays.DisallowLongArraySyntax to ruleset, autofix this
repo (Kunal Mehta)
* Add sniff to detect consecutive empty lines in a file (Vivek Ghaisas)
* Disable Generic.Functions.CallTimePassByReference.NotAllowed (Kunal Mehta)
* Update squizlabs/php_codesniffer to 2.5.1 (Paladox)
Notably, this release now requires []-style arrays, as well as PHP 5.5.9
or higher to run.
To help automatically migrate, you can use the "phpcbf" tool. I
recommend setting up a "composer fix" command (for example [1]). Running
just "composer fix" will try to auto-fix every file in the repo, while
"composer fix filename" will just check that filename.
[1] https://gerrit.wikimedia.org/r/#/c/271220/
Thanks,
-- Legoktm
Hi all,
I've been working on a project to improve the categorization of
pictures in the Upload to Commons Android app
<https://phabricator.wikimedia.org/T115101> as part of the Outreachy
Dec '15 program, which is soon drawing to an end. To summarize, 3 new
features have been implemented in this app:
1. If a picture with geolocation is uploaded, nearby category
suggestions are offered (based on the categories of other Commons
images with similar coordinates)
2. If a picture with no geolocation is uploaded, nearby category
suggestions are offered based on the user's current location. This is
optional and only works if enabled in Settings.
3. Category search (when typing in the search field) has been made
more flexible, whereas previously this was done solely by prefix
search. E.g. now searching for 'latte' should be able to return 'iced
latte'.
The latest version of the app is v1.11 and can be downloaded at
<https://play.google.com/store/apps/details?id=fr.free.nrw.commons>.
Please feel free to leave feedback or bug reports at
<https://github.com/nicolas-raoul/apps-android-commons/issues>.
I have had an amazing time working on this app as part of the
Outreachy program, and I greatly appreciate all the support and help
that the WMF community has given me. :)
Cheers!
--
Regards,
Josephine
If anyone has objections to Fabian, Maribel, and me continuing to mentor
http://mediawiki.org/wiki/Accuracy_review
under the GSoC program, please state your objections now.
Quim, thank you for your kind words on the IEG application.
---------- Forwarded message ----------
From: *'sttaylor' via Google Summer of Code Mentors List* <
google-summer-of-code-mentors-list(a)googlegroups.com>
Date: Tuesday, February 16, 2016
Subject: [GSoC Mentors] GSoC Org Apps close soon
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-list(a)googlegroups.com>
Just a quick reminder that the deadline to apply to be a GSoC 2016 mentor
organization is this Friday, February 19th at 19:00 UTC.
Visit our new website <https://g.co/gsoc> to apply as an organization
today. For helpful tips on what is expected as a mentor organization and as
a mentor or org admin for GSoC 2016 read the Mentor Manual
<http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/>.
We will not accept late applications under any circumstances.
Good luck to all org applicants!
Best,
Stephanie
--
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com
<javascript:_e(%7B%7D,'cvml','google-summer-of-code-mentors-list%2Bunsubscribe(a)googlegroups.com');>
.
To post to this group, send email to
google-summer-of-code-mentors-list(a)googlegroups.com
<javascript:_e(%7B%7D,'cvml','google-summer-of-code-mentors-list(a)googlegroups.com');>
.
Visit this group at
https://groups.google.com/group/google-summer-of-code-mentors-list.
For more options, visit https://groups.google.com/d/optout.
Hi all,
Over the weekend I worked on resolving
https://phabricator.wikimedia.org/T112895 ("Support installing composer
require-dev packages together with mediawiki/vendor").
With the help of Bryan Davis this has now been implemented and applied to
all mediawiki core and extension jobs (mediawiki-*, mwext-*).
Packages specified in mediawiki-core:/composer.json 'require-dev' section
will now be fetched and installed in Jenkins, and the exposed interfaces
are now available through the regular autoloader from Composer.
Key points:
* PHPUnit is now loaded from $WORKSPACE/vendor instead of the frozen legacy
copy at /srv/deployment/integration/phpunit.
* PHPUnit version has not yet changed (3.7.17). However upgrading is now as
easy as changing a number in MediaWiki's composer.json. And such change
will also be reflected in pre-merge test jobs, so that it can be verified
before merging. – See https://phabricator.wikimedia.org/T99982 and
https://gerrit.wikimedia.org/r/270485
* Aside from PHPUnit, one can now also other require-dev composer packages.
For example, we may want to consider using something like vfsStream for
file-system mocking in PHP. – https://phabricator.wikimedia.org/T86163
-- Krinkle
---------- Forwarded message ----------
From: Megan Neisler <mneisler(a)wikimedia.org>
Date: Tue, Feb 16, 2016 at 10:36 AM
Subject: Re: [Wmfall] February 2016 Lightning Talks
To: "Staff (All)" <wmfall(a)lists.wikimedia.org>, Engineering list <
engineering(a)lists.wikimedia.org>
Cc: Kevin Leduc <kevin(a)wikimedia.org>
Hi everyone,
Just a reminder that the February Lightning Talks
<https://www.mediawiki.org/wiki/Lightning_Talks#February_2016> start in
*25 minutes.*
Come join us in the 5th Floor Collab Space or follow along here:
http://www.youtube.com/watch?v=D3fyCgBWvFc
IRC: #wikimedia-tech
Hope to see you there!
Megan
On Tue, Feb 2, 2016 at 4:22 PM, Kevin Leduc <kevin(a)wikimedia.org> wrote:
> Hi All,
>
>
> The next Lightning Talks are scheduled for February 16th (two weeks from
> today). We hope at least 4 people will sign up for the talks by Friday
> February 12th otherwise we will postpone them another month. Lightning
> Talks are an opportunity for teams @ WMF & in the Community to showcase
> something they have achieved: a quarterly goal, milestone, release, or
> anything of significance to the rest of the foundation and the movement as
> a whole.
>
>
> Each presentation will be 10 minutes or less including time for questions.
>
> Sign up here: https://www.mediawiki.org/wiki/Lightning_Talks#February_2016
>
>
> Next round of Lightning Talks:
>
> When: Tuesday February 16, 1900 UTC
> <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks&is…>,
> 11am PST (We have added this Lightning Talk to the WMF Engineering, Fun &
> Learning, and Staff calendars)
>
> Where: 5th Floor
>
> Remotees: On-Air google hangout will be provided just before the meeting
>
> IRC: #wikimedia-tech
>
> YouTube stream: http://www.youtube.com/watch?v=D3fyCgBWvFc
>
>
> Thanks!
>
> Kevin Leduc, Megan Neisler, Brendan Campbell
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
--
Megan Neisler
Project Coordinator- Engineering
Wikimedia Foundation
mneisler(a)wikimedia.org <mguss(a)wikimedia.org>
--
Megan Neisler
Project Coordinator- Engineering
Wikimedia Foundation
mneisler(a)wikimedia.org <mguss(a)wikimedia.org>