Hi all,
Version 2.10 of the Commons Android app has just been released to
production on the Google Play Store[1] (also downloadable on F-Droid[2]).
The update contains:
New features:
- Users can search for (and upload pictures for) places that need pictures
in any location, not just their current location
- Current ongoing campaigns, if any, are displayed on the main screen
- "Retry" button to easily re-upload failed uploads
Fixes:
- Optimized Nearby map loading time
- Fixed various bugs and crashes, including errors with "image taken" date
We're excited to announce that we've also had our recent Project Grant
proposal[3] approved. :) This means there will be lots of improvements
coming up in 2019, with focus on improving stability and the upload
experience for users.
Our first priority will be rewriting the legacy backend code to adhere to
modern standards and reduce complexity (especially the network layer, which
currently uses a deprecated API). This is aimed at resolving a few major
lingering bugs (especially upload failures for a few users), as well as
creating a solid technical foundation to base future improvements on.
Several new features are slated for release after that, including filters
and bookmarks for the "Nearby places that needs pictures" feature, a pause
and resume function for uploads, and a "limited connection" mode.
Thank you so much to everyone who has supported us thus far, especially in
the last rocky year! :) At the conclusion of this grant, we hope to deliver
a much better app to you.
Best regards,
Josephine / @misaochan (project maintainer)
[1]: https://play.google.com/store/apps/details?id=fr.free.nrw.commons
[2]: https://f-droid.org/repository/browse/?fdid=fr.free.nrw.commons
[3]:
https://meta.wikimedia.org/wiki/Grants:Project/Commons_app/Commons_Android_…
If you use these dumps regularly, please read and weigh in here:
https://phabricator.wikimedia.org/T216160
Thanks in advance,
Ariel Glenn
Wikimedia Foundation
ariel(a)wikimedia.org
Hi,
Wiki communities can ask to override their default configurations
(following consensus). The reasons to override may vary:
1. *customization* for community to align to community specific policy
(example: special namespaces / upload policy/user groups rights defined per
project and language version)
2. *technical dispute* where community and engineering don't agree
(example: VE as single tab for enwiki[1], disabling description tagline in
enwiki[2] etc).
Technical dispute are problematic - if the product is not good enough
engineering and community should ideally come with a solution how to
address the issues. We can define a plan to fix the product (disable till
task X is fixed), enable/disable feature in the USER level if it is a
matter of choice (not the site level) etc.
Anyway we should try to avoid letting specific communities override
defaults for long term if there is no community specific reason to override
the configuration. This create a jungle of configurations, inconsistent UI
across languages and more complex maintenance etc.
This is a call for action for the wiki communities and engineering:
- Engineering - consider to align all wikis to similar configuration if
it isn't community customization but "technical dispute"
- Communities - consider whether these configurations are old and can be
removed
Examples of issues found in wmf-config:
- VisualEditor tabs (wmgVisualEditorUseSingleEditTab 60 wikis "Deploying
slowly with community advanced notice"?
wmgVisualEditorSingleEditTabSecondaryEditor - enwiki overrides the default
editor)
- and more generally enabling VE deployments:
https://www.mediawiki.org/wiki/VisualEditor/Rollouts
- Patroling
- wgUseRCPatrol - disabled by default but ~80 wikis enable it. Should
be enabled for all wikis? (if not - what is missing from getting it
deployed in more wikis? are there alternative feature for it
used in other
wikis?)
- wgUseNPPatrol/wgUseFilePatrol - few wikis override it. Do we really
need to override it?
- wgImportSources
- Each wiki define arbitrary list of wikis it import from. We should get
rid of it and allow import between any Wikimedia site. See
https://phabricator.wikimedia.org/T17583
- wmgUseSandboxLink
- Enabled in 80 wikis. Why not enabling it everywhere?
- wmgUseWikiLove -enabled in ~50 wikis including enwiki. is there a
reason to not enable in all wikis?
Thanks,
Eran
[1] https://phabricator.wikimedia.org/T128478
[2] https://phabricator.wikimedia.org/T161805
[3] https://phabricator.wikimedia.org/T214678
https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-03-13
=*2019-03-13*=
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* Maps incident with geoshapes service:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20190308-maps
* (From RI) RelEng: Review needed for deploying
Extension:WikimediaEditorTasks to production (
https://phabricator.wikimedia.org/T218136 )
== Audiences ==
=== Contributors ===
==== Community Tech ====
* Blocked by:
* Blocking:
* Updates:
**
==== Anti-Harassment Tools ====
* Blocked by:
* Blocking:
* Updates:
**
==== Editing ====
* Blocked by:
* Blocking:
** Updates:
**
==== Growth ====
* Blocked by:
* Blocking:
* Updates:
**
==== Language ====
* Blocked by: Several CI failures but RelEng is taking care of them. Thanks!
* Blocking:
* Updates:
** Fixed various bugs in cxserver while ContentTranslation patches were
blocked due to CI issues.
** Manually purging old unpublished drafts from ContentTranslation. This
will likely to move to cronjob in 2 weeks.
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
**Working on 6.2.1 (
https://phabricator.wikimedia.org/tag/ios-app-v6.2.1-beluga-on-stilts/)
***bug fixes
***editing enhancements
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
** Working on the design changes of enhancing reading lists search
functions.
*** Bug fixes
*** Visual changes of "Suggested edits"
==== Readers Web ====
* Blocked by:
* Blocking:
* Updates:
** Summary: adding some features to QuickSurveys, tagging and UI changes
for Advanced Mobile Contributions, and continuing the MobileFrontend
Architecture investment project.
** Responsive website (MinervaNeue / MobileFrontend):
*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
**** Add history link to actions menu T213352
**** Tag Thanks actions with AMC tag T215477
**** Provide mechanism to allow dynamically tag log entries T215675
**** Add X-Analytics tag for AMC webrequests T212961
**** Cannot access user contributions when following red link to user page
on mobile T201339
*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFro…
Use the Overlay.make pattern for notification feature T217296
**** Refactor ImageOverlay T216198
**** Refactor TalkSectionAddOverlay T217102
**** Limit mobile.startup's mw.config variables T216848
*** QuickSurveys
**** Consultation with Research
**** Support sampling by country T213847
**** Support sampling by edits T139317
**** Remove templates T208605
**** Revise deprecated ResourceLoader API usage T216746
*** Miscellaneous bug fixes and maintenance T218098 T207618 T217820
** Desktop website (Popups)
*** Popups https://www.mediawiki.org/wiki/Page_Previews
**** WMDE reference previews review and support T67114
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
**** Bugfix for double pokey on some page previews T204627
==== Readers Infrastructure ====
* Blocked by:
** SRE: Sunsetting Wikipedia Zero stuff (
https://phabricator.wikimedia.org/T187716) is still blocked by
https://phabricator.wikimedia.org/T213769 (and possibly others); not
urgent, but we want this done this quarter if possible. (Repeat from
previous weeks)
** RelEng: Review needed for deploying Extension:WikimediaEditorTasks to
production (https://phabricator.wikimedia.org/T218136 )
* Blocking:
* Updates:
** mobile-html:
*** Changing URLs from https to be protocol independent because the iOS app
can handle that better when saving for offline.
*** Removing navboxes from mobile-html DOM
** Maps: incident with the geoshapes service
https://wikitech.wikimedia.org/wiki/Incident_documentation/20190308-maps
==== Multimedia ====
* Blocked by:
* Blocking:
* Updates
**
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
** Working on fast and spec-compliant HTML5 parsing and filtering
(querySelector) in PHP. If you are aware of code that could benefit from
this (probably anything that uses DOMDocument and related classes), please
add it to https://phabricator.wikimedia.org/T218183
==== UI Standardization ====
* Blocked by:
* Blocking:
* Updates:
** OOUI release in prep, we decide if minor or patch release, depending on
ongoing work by Multimedia team and Ed:
*** Bring StackLayout, MenuLayout, Tab*Layout, IndexLayout to OOUI PHP
https://phabricator.wikimedia.org/T215645
*** Quicken PHP tests
*** Make mixin configs extendable
** Unify error and system messages https://phabricator.wikimedia.org/T127405
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** db1002 is now decommissioned, so we consider the migration of the
analytics mysql replicas from the old to the new hosts complete
** the EventLogging database in Hive is now in compliance with the data
retention guidelines
** medium refactor in MediaWiki history reconstruction job to organize
code, improve performance and fix some issues
** working on Wikistats2 metrics list to bridge the gap between Wikistats1
metric definitions and Wikistats2 interface
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Upstreamed fixes for CiviCRM
** Reviewing audit code for main card processor to make sure we're catching
everything https://phabricator.wikimedia.org/T217582
** Fixing CentralNotice sanitization over-strictness
https://phabricator.wikimedia.org/T216150
** Better fraud attempt queries for CiviCRM
https://phabricator.wikimedia.org/T199268
** Tweaks to Thank You mail https://phabricator.wikimedia.org/T207674
** Building notification stream for changes to active CentralNotice banners
and included bits https://phabricator.wikimedia.org/T208511
** Working on recording opt-in choices even when payment attempt fails
https://phabricator.wikimedia.org/T216293
** Still trying to coordinate timing of payments-wiki upgrade to PHP7 & MW
1.31 https://phabricator.wikimedia.org/T184460
=== Core Platform ===
* Blocked by:
* Blocking:
* Updates:
** Encapsulate MW environment in Env class for Parsoid
** Program for EMWCon
** Upgrade phan to 1.2.6
** Session storage deployment prep
** completed T216159 (stale data/caching bug in revisions). Merged.
** completed T202352 (MultiHttpClient+Guzzle), deployed then reverted due
to bug
** Prometheus, request IDs, Helm for Kask
** WikiPEG to npm
** Merged "Remove unused method Title::validateFileMoveOperation" (T214316)
=== Performance ===
* Blocked by:
** Comms: W3C replied about communication around W3C membership
announcement. Waiting for Comms to tell Gilles what they plan to do.
** Legal:
*** W3C membership pending, Gilles provided everything Stephen asked for.
Now waiting for them to go ahead with it.
*** Gilles send email asking for green light on AS perf report *(Security
approved on 2019-03-12)*
*** Gilles filed task asking for data release review of research paper
dataset
** Language: CR for patch to reduce full table SELECTs of
translate_metadata
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Translate/+/494146/
** CPT: REVISIONID Parser optimisation/deprecation for large wikis.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/294774/
** Traffic:
*** Be able to distinguish between wiki and non-wiki reqs in mtail from
Varnish. - https://phabricator.wikimedia.org/T202479.
"This outcome of this task should be for the mtail/varnishrls metric
collector to only apply to traffic for hosts where ResourceLoader is
available,
so as to stop the data pollution from unrelated requests for hosts
where there is not meant to be an /w/load.php entry point"
*** Error handler on mwdebug servers not working. –
https://phabricator.wikimedia.org/T217846
*** Varnish thumbnail URL deduplication patch (prerequisite to Swift
auto-cleanup) https://gerrit.wikimedia.org/r/#/c/mediawiki/vagrant/+/489021/
* Blocking:
**
* Updates:
**
=== Release Engineering ===
* Blocked by:
* Blocking:
** Language: Several CI failures
** Readers Infrastructure: Review needed for deploying
Extension:WikimediaEditorTasks to production (
https://phabricator.wikimedia.org/T218136 )
** Search Platform: Thanks RelEng for working on
https://phabricator.wikimedia.org/T216689
* Updates:
** Work progresses on CI tool evaluation
https://phabricator.wikimedia.org/phame/post/view/149/work_progresses_on_ci…
** Train Health:
*** Last week: 1.33.0-wmf.20 - https://phabricator.wikimedia.org/T206674
*** This week: 1.33.0-wmf.21 - https://phabricator.wikimedia.org/T206675
*** Next week: 1.33.0-wmf.22 - https://phabricator.wikimedia.org/T206676
** Code Health:
*** SonarQube is available as an experimental job for all extensions
https://gerrit.wikimedia.org/r/c/integration/config/+/490950
=== Research ===
* Blocked by:
* Blocking:
* Updates:
=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:
=== Search Platform ===
* Blocked by: Thanks RelEng for working on
https://phabricator.wikimedia.org/T216689
* Blocking:
* Updates:
** New blog post:
https://wikimediafoundation.org/2019/03/12/the-anatomy-of-search-a-place-fo…
** WikibaseCirrusSearch tested on beta & testwikidata, some bugs fixed,
loaded on production, enabling soon
https://phabricator.wikimedia.org/T190022
** Blazegraph now can be tested on Jenkins CI:
https://phabricator.wikimedia.org/T216855
** Fixed Greek lowercasing, reindex pending:
https://phabricator.wikimedia.org/T203117https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Greek_and_Unexpected…
** TextCat version update fully finished and deployed:
https://phabricator.wikimedia.org/T216083
** Improved icinga monitoring for OOM conditions in elastic cluster:
https://phabricator.wikimedia.org/T76090
** Working on ES 6 upgrade: https://phabricator.wikimedia.org/T183282
** Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
** Working on moving CirrusSearch code out of Wikibase to a separate
extension: https://phabricator.wikimedia.org/T190022
=== Security ===
* Blocked by:None
* Blocking:None
* Updates:
**https://phabricator.wikimedia.org/T217289: TBD
**https://phabricator.wikimedia.org/T216692: TBD
**https://phabricator.wikimedia.org/T163827:complete by end of week
**https://phabricator.wikimedia.org/T216419:start by end of week
**https://phabricator.wikimedia.org/T211489:complete by end of week
**https://phabricator.wikimedia.org/T201492: TBD
**https://phabricator.wikimedia.org/T103011: TBD
**https://phabricator.wikimedia.org/T207990:TBD
=== Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Wrapping up on goals
== TechComm ==
* Updates:
** Updated Gerrit Privlege policy:
https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
** On Last Call: The Great Namespaceization and Reorg
https://phabricator.wikimedia.org/T166010 ending March 20 1pm PST (20:00
UTC, 21:00 CET)
** On Last Call: RfC: Standards for external services in the Wikimedia
infrastructure.https://phabricator.wikimedia.org/T208524 ending March 13
11pm PST (March 14 7:00 UTC, 8:00 CET)
** IRC Meeting Scheduled: RFC: Add a frontend build step to
skins/extensions to our deploy process
https://phabricator.wikimedia.org/T199004 March 20 2pm PST (21:00 UTC,
22:00 CET) in #wikimedia-office
** IRC Meeting Scheduled: RFC: Let's stop using QUnit as a mechanism for
integration tests https://phabricator.wikimedia.org/T212521 March 20 2:45pm
PST (21:45 UTC, 21:45 CET) in #wikimedia-office
== Wikidata ==
* Blocked by:
** none
* Blocking:
** none (we are aware of)
* Updates:
** Work continues on new responsive term view on items and property pages:
https://phabricator.wikimedia.org/project/board/3620/
** Preparing Server-Side Rendering service for use with the new Front End
Architecture: https://phabricator.wikimedia.org/T212189
** Work continues on Schema functionality (defining the "schema" Wikidata
items of particular kind should follow):
https://phabricator.wikimedia.org/project/board/3789/
** Musical notation data type to be enabled on wikidata.org tomorrow March,
14th: https://phabricator.wikimedia.org/T216730
** Investigating next steps to improvements in the storage layer
== German Technical Wishlist ==
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Rollback confirmation feature: it was already reviewed but put on hold
until today, waiting for a +2, which would then be rolled out to Beta.
** Finishing the Reference Previews feature of the Popups extension,
planned for Beta rollout later: https://phabricator.wikimedia.org/T217139
** Rolling out a bugfix release of Wikidiff2:
https://phabricator.wikimedia.org/T203069
== SoS Meeting Bookkeeping ==
* Updates:
**
This is just another small reminder that, because the servers which host
tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas) and overpass-wiki
run on a version of the OS (Ubuntu Trusty) that is no longer supported (and
hasn't been available for new instances since november 2017).
These services need maintainers and support by community members in order
to keep them alive after dec 18th (after which wmflabs will phase out those
versions) and before the EOL of early 2019 of the OS. Unfortunately it
seems no one is stepping up so far to convert these machines.
This issue is tracked at https://phabricator.wikimedia.org/T204506
As I was curious, I looked around on the tile server a bit and used what I
could find to update
https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
This is all the information that I could gather, but i'm FAR from sure if
that is complete information and if I would break anything with a rebuild
basing myself on that info, so any information on missing elements etc.
would be appreciated. I've not gotten around to looking at wikiminiatlas.
If the services are not rebuild then likely they will just disappear at
some point for all layer variants. This includes the mapnik, black and
white, hill shading, hike bike layers. As I have no idea how many users of
these services there are, it is hard to say what the effect of that would
be.
DJ
Hi all,
in my part of the Design team at Wikimedia Foundation, I'd like to
share an upcoming change in typography, that might be of interest for
you:
Improving reading experience on mobile [0] –
As many of our projects are putting textual content first, we are
consistently aiming at best possible reading experience for our users,
regardless of the device, software, or language of our readers.
Typography, and specifically font choices, build the base for
readability.
Therefore we have been proposing to rely on so-called system fonts as
our default mobile font choice in the mobile skin MinervaNeue. Both
major platforms, iOS and Android, but also operating systems like
macOS and Windows come out-of-box with better suited system fonts than
the general fallback `sans-serif`. Those specific fonts
- deliver a better native experience for readers,
- improve cross-platform and
- improve cross-language readability.
Please see the project page on mediawiki.org [0] for further technical
details of the changes and an overview of our wide-range testing. Our
current plan is to rollout the change to Beta-Cluster next week.
We welcome your feedback!
Best regards,
Volker
[0] – https://www.mediawiki.org/wiki/Design/Projects/Improve_mobile_reading_exper…
Senior UX Engineer, UI Standardization Lead (he/him)
Wikimedia Foundation
volker.e(a)wikimedia.org | @Volker_E
Hi All,
I noticed that ManualLogEntry items could have tags only when those entries
are published to `rc` or `rcandudp`. Then the extensions can attach tags
via RecentChange_save hook and everything works perfectly. The problem I
encountered happens when the log entry is published to `udp` only[1], then
tags are ignored. The only way to apply tags to the LogEntry is to call
`ChangeTags::addTags()` after log entry creation.
In the AMC[2] project we would like to tag user actions with `advanced
mobile edit`[3]. Some of those actions, like "Thanks" are not published as
RecentChange, and we want to keep it as it is right now[4].
What is the reason for this?
Can I safely add support for tagging log entries that are published to
udp only inside the ManualLogEntry class?
Otherwise, I'll need to update Thanks extension code and
- create a new hook that passes the LogEntry object, for
example, "ThanksLogEntryCreation"
- in the MobileFrontend listen to that hook and call the
`ChangeTags::addTags( [ 'advanced mobile edit' ], null, null, $logId );`
Doesn't sound that bad, but then I'll have to apply the same code to other
places where we create log entries that are not published as RecentChange.
It sounds like a technical debt to me. Also, the current implementation
feels broken, as code quietly ignores tags when logs are published to `udp`
only.
It looks like the ChangeTags already supports adding tags to LogEntries
only - both rc_id and rev_id are nullable, and the only question is how to
tag logs published to the RecentChange (do we add tags to both LogEntry and
RecentChange objects?).
Additionally, I'd like to introduce a Taggable interface[6], that provides
a one way to tag objects (right now RecentChange exposes addTags() method
but the ManualLogEntry exposes setTags() method).
[1]
https://github.com/wikimedia/mediawiki/blob/278ac40e9609b0b226a85e020f5e574…
[2] https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
[3] https://phabricator.wikimedia.org/T212959
[4] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Thanks/+/493740/
[5]
https://github.com/wikimedia/mediawiki-extensions-Thanks/blob/ac1c3906efabd…
[6] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/493464/
--
*Piotr Miazga* (he/him)
Fullstack Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi,
Over the past years, Wikimedia Germany’s Technical Wishes team has been
working on new and improved tools for the diverse communities and users of
the Wikimedia projects. Apart from developing software, we also developed
methods and approaches for building software in a collaborative
environment. We learned lots and wrote the most important parts of it down.
So, if you’re interested in software development that involves a diverse
community, please have a look at our white paper. It is version 1.1 of the
paper we published in December 2018.
You can find it on Meta wiki:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Approach/Lessons_lear…
and a PDF version on Wikimedia Commons:
https://commons.wikimedia.org/wiki/File:White_Paper_Technical_Wishes_2018.p…
We hope you’ll find our shared learnings helpful. If you have any
questions, please reach out to us on this talk page:
https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Approach/Lessons…
For the Technical Wishes team of Wikimedia Germany
Birgit, Michi, Lea and Johanna
--
Johanna Strodt
Project manager community communication for the Technical Wishlist
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.