Recently I spent some time on Commons, and I came across two things that I
especially appreciated.
The first is a story on Yann's user page
<https://commons.wikimedia.org/wiki/User:Yann>. While I think that
experience with participating on public Wikimedia projects is an important
qualification for many roles in the Wikimedia universe, this story reminds
the reader to place edit count into a wider perspective.
---
*A novice was once curious about the nature of the Edit Count. He
approached the Zen master and asked, "Zen master, what is the nature of the
Edit Count?""The Edit Count is as a road," replied the Zen master. "You
must travel the road to reach your destination, and some may travel longer
roads than others. But do not judge the person at your door by the length
of the road he has travelled to reach you."*
*And the novice was Enlightened.*
*---*
The second thing that I especially liked on Commons is this photo
<https://commons.wikimedia.org/wiki/File:Flooded_Albizia_Saman_(rain_tree)_i…>
that was taken in Laos by Basile Morin. As you can guess, I generally like
trees.
On a different subject, Markus Kroetzsch wrote
<https://lists.wikimedia.org/pipermail/wikidata/2018-October/012536.html>
to the Wikidata list that he is "happy to report that we" (Stanislav
Malyshev, Markus Krötzsch, Larry González, Julius Gonsior, and Adrian
Bielefeldt) "have just won the Best Paper Award of the In-Use track of this
year's International Semantic Web Conference (ISWC), for our description of
the SPARQL/RDF technology use on Wikidata. I keep telling people here that
the general awesomeness of Wikidata is the work of many, and in particular
of this great community of editors."
In older news, some time ago I was told about this video on Commons
<https://commons.wikimedia.org/wiki/File:BareBonesSearch.webm> by Trey
Jones that provides an introduction to full-text search. I thought that
presentation was very interesting.
What's making you happy this week? You are welcome to write in any
language.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
In the next couple weeks I'm planning to start switching our video
transcode output from WebM VP8/Vorbis to the newer WebM VP9/Opus profile,
which saves us about 38% on file size and bandwidth while retaining the
same quality.
This will not affect what kinds of files you upload; only the scaled
transcoded output files used for playback will change. All modern browsers
that support VP8 support VP9 as well, and our player shim for Safari and IE
will continue to work.
All the details:
https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/VP9_transition
Comments and questions welcome!
-- brion
There are no known users of the return value of OutputPage::adaptCdnTTL()
according to
https://codesearch.wmflabs.org/search/?q=adaptCdnTTL&i=nope&files=&repos=
But our all-seeing eye does not see everything. Be it known that
https://gerrit.wikimedia.org/r/450075, just merged, removed the return
value for OutputPage::adaptCdnTTL() and this is technically a breaking
change.
The value formerly returned by adaptCdnTTL() was arguably misleading:
callers would probably expect it to return mCdnMaxage, but instead it
(formerly) returned mCdnMaxageLimit. Since the return value was easily
misunderstoood *and* it was unused, we've decided to remove it.
@simetrical (Aryeh) wrote the patch and should get the credit (the test
coverage for OutputPage was also significantly increased! Yay, Aryeh!).
Krinkle and I thought it was worth a C+2, so if in fact
OutputPage::adaptCdnTTL() was vital to your way of life and we've ruined it
forever, we should get the blame.
--scott
--
(http://cscott.net)
Thanks, this looks like a nice addition that will cumulatively save people
a lot of time if used widely. I'm forwarding to the Commons and Wikitech
lists. I haven't tested it but the concept looks good.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
On Tue, Oct 9, 2018 at 10:14 AM Ananth Subray <ananth.subray(a)gmail.com>
wrote:
> Dear All,
>
> We are very happy to inform you all that Indic-TechCom has made a new tool
> to give a link to source file after doing the derivative work on commons.
> We all know that how important to mention the source file correctly after
> doing the derivative work. Based on the request of community members
> Indic-TechCom has created. To know more about the tool visit the meta
> page[1]. Indic-TechCom request you all to use it and spread the work to
> your community members. In case if you have suggestions, please let us
> know.
>
>
>
>
> [1]. https://meta.wikimedia.org/wiki/Indic-TechCom/Tools/FileLinkTool
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Hello everyone,
Today we've concluded the successful migration of our wikis (MediaWiki
and associated services) from our secondary datacenter (codfw) back to
the primary one (eqiad). During the most critical part of the switch
today, the wikis were in read-only mode for a duration of 4 minutes
and 41 seconds. That's a significant improvement over the 7 mins and
34 seconds we achieved during the inverse process we concluded a month
ago, which was already significantly better than last year. I 'd like
to believe that it's the result of the increasing amount of experience
we are building and trust we are putting in the process and tools that
we have developed for this.
Although the switchback process itself has been largely automated and
went pretty smoothly, there have been some issues that we experienced:
- CentralNotice banners stayed online for a longer time than necessary
due to miscommunication issues. This has now been documented and will
be avoided in the future.
- After the switchback we 've experienced increased load to all our
mediawiki application servers. The root cause has been identified and
mitigation against it will be put in place. The summary is non working
replication of parsercache between the 2 datacenters.
- Last, but not least and probably the most important of all issues, a
data inconsistency was detected in wikidata (s8). Namely some articles
that were present in codfw but were not replicated in eqiad. We are
still investigating the root cause of this while applying corrective
actions to mitigate the user impact as quickly as possible.
All wikis are now served from our primary data center again.
Should you experience any issue that is deemed related to the
switchover process, please feel free to file a ticket in Phabricator
and tag it with the Datacenter-Switchover-2018 project tag[1]. We will
monitor this tag closely and keep any and all issues updated.
We'd like to thank everyone for their hard work in ensuring any
(potential) issues got resolved timely, for automating the process
whenever and wherever possible, and for making this datacenter
switchover and switchback a success!
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
*https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-09-26
<https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-09-26>*
*= 2018-09-26 =*
== Callouts ==
Release Engineering:
* *Deployments of MediaWiki with scap cause a spam of "web request took
longer than 60 seconds and timed out"*
** https://phabricator.wikimedia.org/T204871
** Scap is checking canary servers in dormant instead of active-dc*
** Switchover process needs an update. Long term the list of canaries
should be in conftool.
** https://phabricator.wikimedia.org/T204907
* ComTech:
** We're starting to work on showing SVGs in page language -
https://phabricator.wikimedia.org/T205040
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
**Planning to be feature complete for 6.1 (
https://phabricator.wikimedia.org/tag/ios-app-v6.1-narwhal-on-a-bumper-car/) by
the end of this week
** Apps offsite next week,
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
**Working on productionising new navigation
**Apps offsite next week.
==== Readers Web ====
* Blocked by:
* Blocking:
* Updates:
** Mobile website (MinervaNeue / MobileFrontend):
*** SkinMinerva.php file logs "Undefined variable: returntoquery` error
T205449
*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFro…
**** Continue Webpack and test transition of mobile.startup T203817
**** Add more tests to mobile.startup files T203818
**** Simplify CategoryOverlay T191987
**** Add Sinon.JS configuration T204885
**** Update test file naming T197884
**** Bundle Hogan.js T205128 T205129
**** Enable client side error reporting T167699
*** Page issues
https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
**** Limited A/B test in progress T204609
**** ReadingDepth logging sometimes initializes before PageIssues T204144
**** Add new treatment opt-in query parameter override T204746
**** Don't cache config flag with HTML T205355
**** What % of pages feature issues? T201123
**** Increase sampling ratio for ReadingDepth T205176
*** Working with editing
*** Add share icon to beta T181195
*** Lighten default theme color T204691
*** Maintenance and bug fixes T199066 T204584 T197105 T198018 T205321
*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
**** Generate list of most used special pages T198218
**** Design and product continuing special pages work in Minerva
*** Data working on "better use of data" requirements
** PDF rendering (Proton)
https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality
*** Remaining work tracked in T186748
*** Working with Services on a Grafana dashboard T201158 T204055
*** Chromium-render doesn't handle browser connection abort well T181623
*** Miscellaneous maintenance and bug fixes
** Supporting Multimedia/Test hiring processes
==== Readers Infrastructure ====
* Blocked by:
* Blocking:
* Updates:
** PCS: Continue work on mobile-html endpoint.
** Maps
*** maps1004 migrated to stretch successfully
**** It will now receive OSM data load to start generating tiles T205462
*** Investigation of tilerator crash in eqiad has an workaround but still
need permanent fix T204047
==== Parsing ====
* Blocked by: None
* Blocking: None
* Updates: All code review requests from last week have been handled, thanks
** Will pass along: (Parsing) T205497 [Regression pre-wmf.23] REST API on
Beta cluster returns content of different pages than requested (breaks VE)
==== Multimedia ====
* Blocked by:
* Blocking:
* Updates
**
=== Contributors ===
==== Community Tech ====
* Blocked by:
* Blocking:
* Updates:
** We're starting to work on showing SVGs in page language -
https://phabricator.wikimedia.org/T205040 *Ping Parsing and SRE*
==== Anti-Harassment Tools ====
* Blocked by:
* Blocking:
* Updates:
**
==== Editing ====
* Blocked by:
* Blocking:
** Updates:
** Removed dedicated annotation operation types in the VE data model and
instead model annotation transactions using replacements
** Improved mobile dialogs in the visual editor
** Completed move of MobileFrontend's VisualEditor styles back to
MobileFrontend from Minerva
==== Growth ====
* Blocked by:
* Blocking:
* Updates:
**
==== Language ====
* Blocked by:
* Blocking:
* Updates:
** Preparing for ContentTranslation v2 continue.
=== Audiences Design ===
* Blocked by:
* Blocking:
* Updates:
**
==== UI Standardization ====
* Blocked by:
* Blocking:
* Updates:
** Special:Preferences OOUI rollout
** Resolving remaining typography/imagery quests on Design Style Guide
** Accessibility work on wikimediafoundation.org website
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
- Analytics team off-site
- Replacement of hadoop cluster node managers without issues
- 2 new metrics for Wikistats2: pages to date (total article count) and top
contributors, deploy before end of quarter
- Final work on Wikistats2 graph annotations (tricky UI), also deploy
before end of quarter
- Modern Event Data Platform internal discussions, tickets and naming
reworked for a clearer picture of what we will be working on
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Thanks to the people who are helping out with the MessageCache issue
affecting CentralNotice (Ian Marlier, Jaime Crespo, Daniel Kinzler, Niklas
Laxström et al)
** Got a patch out to support Amazon Alexa donations, just in time for
their announcement
** Working on distinguishing endowment gifts throughout the whole donation
pipeline
** Fixing a couple of issues in spreadsheet imports
** Interviewing for engineer position
=== Core Platform ===
* Blocked by:
* Blocking:
* Updates:
** Session management service design and implementation is being moved up
to this quarter to get to unblock multi-DC
*** Preparing for moving to production early Q3
** MediaWIki tarball release script updated
** Work starting on Excimer - New profiler for PHP to replace XHProf
https://phabricator.wikimedia.org/T205059
=== Performance ===
* Blocked by:
* Blocking:
* Updates:
**
=== Release Engineering ===
* Blocked by:
** 1.32.0-wmf.23 deployment blockers
*** (Readers Web) T205449 SkinMinerva.php file logs "Undefined variable:
returntoquery` error
**** Done
*** (Core Platform) T205469 Fatal error from LinkRenderer on special pages
("Object of class HtmlArmor could not be converted")
**** Done
*** (Search Platform) T205473 Fatal error "Invalid operand type" from
CirrusSearch LinksUpdate
**** Done
*** (Parsing) T205497 [Regression pre-wmf.23] REST API on Beta cluster
returns content of different pages than requested (breaks VE)
**** Done
* Blocking:
**
* Updates:
** Train Health:
*** Scap is checking canary servers in dormant instead of active-dc -
Switchover process needs an update. Long term the list of canaries should
be in conftool - https://phabricator.wikimedia.org/T204907
** Log Health:
*** We are seing a lot of T204871 "web request took longer than 60 seconds
and timed out" in `fatalmonitor`
** Code Health:
*** Creating communication channels (Phabricator
https://phabricator.wikimedia.org/tag/code-health-metrics/, IRC channel,
mailing list)
=== Research ===
* Blocked by: None
* Blocking: None
* Updates:
** Data collection for CitationUsagePageLoad at 33.3% (was 10% previously)
** Retaining de-identified CitationUsage data beyond 90 days
** Recommendation API service to MySQL connection:
https://phabricator.wikimedia.org/T205452
=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:
** PoolCounter is deployed everywhere, now the limit of parallel
connections is being enforced
** Started to work on improving logs in ores, specially sending them to
logstash
** Building javascript library in mediawiki to make requesting scores to
ores easier: https://phabricator.wikimedia.org/T201691
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
**Made sanetizer process to constantly reindex the wikis:
https://phabricator.wikimedia.org/T203622
**Implemented support for Lexemes in RDF (not enabled yet, waiting for
dumps): https://phabricator.wikimedia.org/T202459
**Finished evaluation of image quality as query-independent ranking signal:
https://phabricator.wikimedia.org/T202339
***Conclusion: positive, image quality is a good signal, will plan
implementation
** Upgraded ElasticSearch plugins for 6.3:
https://phabricator.wikimedia.org/T197960
** Added ntriples RDF dump for Wikidata:
https://phabricator.wikimedia.org/T144103
** Reindexing Wikidata to enable several newly deployed features
** Reindexed Esperanto wiki after new analysis enabled:
https://phabricator.wikimedia.org/T203005
** Working on calculating examination probabilities for completion queries:
https://phabricator.wikimedia.org/T205348
** Working on improving Korean analyzers:
https://phabricator.wikimedia.org/T178925
** Working on running multiple Elastic instances on the same hardware:
https://phabricator.wikimedia.org/T193654
** Working on searching for statement values without additional keywords
for Wikidata: https://phabricator.wikimedia.org/T163642
** Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
=== Security ===
* Blocked by:
* Blocking:
* Updates:
**
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Preparing for the switchback
** Finishing goals
== Wikidata ==
* Blocked by:
* Blocking:
* Updates:
**
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
**
== Multi-Content Revisions ==
* Blocked by:
* Blocking:
* Updates:
** "read new" enabled on testwiki
** "read new" being enabled on mediawiki.org this week
** waiting for DC switch back to enable "read new" on Commons and other
wikis
** reactive minor bug fixes
== SoS Meeting Bookkeeping ==
* Updates:
**
_in_the_Mekong.jpg){kind=link}