Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Phabricator users,
this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
this.
https://phabricator.wikimedia.org/T238593
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
Hi all,
I was happy to be invited by the Wikimedia Foundation to the Wikimedia
Technical Conference 2019 in Atlanta~[1]. At this conference, I represented
the technical needs of the mathematical community~[2]. Apart from a lot of
great achievements for the whole Wikimedia movement with regard to the five
focus areas of the conference~[3], there were also several math-specific
achievements. In this message, I will focus on those aspects:
1) Bold italic capital greek symbols are now possible. Please join me in
thanking Petr Kadlec (aka. Mormegil) for his perennial effort to make this
possible~[4].
2) We will - very soon - have a demo on the Wikimedia beta cluster enabling
links from formulae to a dedicated special page that displays definitions and
explanations regarding mathematical objects of interest, i.e., identifiers,
symbols, terms. Thank you André Greiner-Petter for the implementation of this
feature~[5].
3) In a session on 'Integrating contributions from other teams or volunteers`
organized by Christoph Jauera (aka. Fisch). We derived definitive action items
on improving the participation opportunities to the Math on wikis~[6].
4) We discussed the future of Math rendering with Petr Pchelko (WMF) which
will simplify the setup of mathoid and eventually get rid of fallback images
while maintaining support for MathML disabled browsers~[7].
I am grateful to the Wikimedia Foundation and the organizers of the event, in
particular, Rachel and Greg to get the chance to enjoy this well-organized
conference with amazing people and a wonderful program.
All the best
Moritz (physikerwelt)
http://moritzschubotz.de | +49 1578 047 1397
[1]:https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019
[2]:https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math
[3]:https://phabricator.wikimedia.org/T238406
[4]:https://phabricator.wikimedia.org/T218295
[5]:https://phabricator.wikimedia.org/T208758
[6]:https://phabricator.wikimedia.org/T234662#5660102
[7]:https://phabricator.wikimedia.org/T237516
Some more details on item 4, from my personal, biased perspective:
I started working on the Math extension in 2012 and implemented the
main functionality
of the new rendering method which is based on MathJax rather
than on LaTeX in 2013 at the Wikimedia Foundations Headquarter in San
Francisco. At that time the vision was to replace the monolithic PHP based
framework MediaWiki, with a large number of small dynamic JavaScript modules.
The idea was that those modules are developed as isomorphic platform-independent
components using interfaces of a management framework that takes
care of caching and efficient execution. The long-term goal was that the
functionality could be executed either on the client or on the server and that
the management layer would figure out the best execution strategy based on the
current prerequisites. In the first step, a framework based on HTTP requests was
set up to handle services such as math rendering. Mathoid the math rendering
service was one of the first instances of this service template. From the
retro perspective that might have been too early. Neither a convenient type and
schema description language existed, nor a way to specify rich metadata on the
execution characteristics existed. However, a fine-grained I/O schema seems
desirable for implementing robust and durable services. Moreover, rich
metadata on the execution characteristics such as runtime, memory footprint,
I/O data distributions seem required to allow an execution management layer
for effective execution strategy planning. After the services went into
production schema improvement was difficult and never happened.
Today, it seems pretty certain that MediaWiki will be PHP based for the
foreseeable future. Given this situation, we did now plan to improve Math
support by making the best use of the build-in MediaWiki core functionality. We
will rely on the MediaWiki core caching functionality to continue providing an
instant user perception of math rendering and continue using a stateless
node-based math rendering service. Our hope is that by incorporating the 'new`
MathJax 3 rendering mode 'common HTML` also MathML disabled browsers will be
able to display high-quality mathematical formulae without to rely on
disturbing images. We plan to enable this rendering mode as opt-in in a first
step and thereafter have a community vote if the new imageless rendering mode
should become the default. If that won't work, we will need to
evaluate inline SVG
images that would require either SVG or JavaScript support on the client.
Given the situation that only a very small number of visitors use browsers
that neither support SVG images nor allow JavaScript this second alternative
seems to an ethical option as well.
I will update the associated ticket phabricator ticket~[7] as soon as we have
derived a more detailed plan for the implementation.
Hi All,
On* 5, December 2019, 8 PM UTC*, we'll welcome Camille Fournier for a
special edition of Wikimedia Tech talks! Camille will share insights from
her career and discuss her book, “The Manager’s Path: A Guide for Tech
Leaders Navigating Growth and Change
<https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth-ebook/dp/B06…>
.”
Camille Fournier is the head of Platform Engineering at Two Sigma, a
financial company in New York City. Prior to joining Two Sigma, she was
the Chief Technology Officer of Rent the Runway
<https://www.renttherunway.com/>, a transformative brand that offers
unprecedented access to designer fashion, disrupting the way millions of
women get dressed.
She is an Open Source contributor and project committee member for both
Apache ZooKeeper and the Dropwizard web framework. Prior to working for
Rent the Runway, Camille served as a software engineer at Microsoft, and
most recently, spent several years as a technical specialist at Goldman
Sachs, creating distributed systems for managing risk analysis and firmwide
infrastructure.
She has a BS in Computer Science from Carnegie Mellon University and an MS
in Computer Science from the University of Wisconsin-Madison. Camille is a
well-respected voice within the tech community, speaking on a variety of
topics such as engineering leadership, distributed systems, scaling teams,
and technical architecture.
You can view the talk live and ask questions here:
https://www.youtube.com/watch?v=mNtFUt0vR58
Questions will also be taken through #wikimedia-office IRC
*Feel free to share this announcement! *
Kindly,
Sarah R. Rodlund
Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Next Wednesday, December 4th, at 00:00 UTC (4pm San Francisco) there will be
a Phabricator upgrade window that might last up to 2 hours.
While we expect downtime to be much shorter than that Phabricator might be
unreachable in that time frame.
We are switching the production Phabricator server to a buster (Debian
stable) machine.
https://phabricator.wikimedia.org/T238956
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
The Cite extension implements an API `action=query&prop=references`[1],
which was written to support a reference lazy-loading feature for mobile
clients but never used. This was a beta feature and the API was never
enabled on Wikimedia sites.[2] If you query it, you'll see nothing but an
error response.
My team is currently refactoring the Cite extension, and we would prefer to
remove the API rather than continue maintaining dead code. Please respond
by the end of the week if you know of any non-Wikimedia sites where the API
is enabled and in use, otherwise we'll continue with the plan to remove it
without a deprecation period.
Thank you,
Adam
[1]
https://en.wikipedia.org/w/api.php?action=help&modules=query%2Breferences
[2] https://phabricator.wikimedia.org/T222373
--
Adam Wight - Developer - Wikimedia Deutschland e.V. - https://wikimedia.de
Hi all,
We're having terrible trouble with the Cirrus search maintenance script
for initialising the elastic indexes:
forceSearchIndex.php --skipLinks --indexOnSkip...
It's happening with MW 1.31 .. 1.33, we're using redis job queue and a
single instance of Elastic on the same host (these are low traffic
wikis). Debian 10.2, PHP 7.3.
No matter what parameters we use (--queue or not, different --maxJobs,
or --fromId/--toId, --batchSize etc etc) we're always finding that
hundreds of elastic docs are not being created.
There's nothing about the articles themselves that are preventing it, if
we run the maintenance script on just a single missing one afterwards it
gets created no problem, and also each time this problem happens, there
are many differences in the missing docs.
Please if anyone has heard of this kind of things and could point us in
the right direction here that would be awesome!
Thanks a lot,
Aran
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, Dec 6th, 2019
Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Hope to talk to you in a week!
*Note that our January Office Hours will be on January 8th.*
Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
UTC-5 / EST
Hello Wikitech-l,
Usually I send emails that announce Wikimedia Café meetings only to
WIkimedia-l, but because December's meeting agenda includes discussing the
documentation for Wikitext, I am forwarding this announcement to WIkitech-l.
Regards,
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
---------- Forwarded message ---------
From: Pine W <wiki.pine(a)gmail.com>
Date: Fri, Nov 29, 2019 at 10:50 PM
Subject: Wikimedia Café online meeting for December 2019
To: Wikimedia Mailing List <Wikimedia-l(a)lists.wikimedia.org>
Hello colleagues,
For the next Wikimedia Café online video meeting, agenda items include:
* Documentation for Wikitext <https://en.wikipedia.org/wiki/Help:Wikitext>
* The NavWiki <https://outreach.wikimedia.org/wiki/NavWiki> project
Last month's Wikimedia Café had a problem with an inaccurate time
conversion from USA Eastern time to UTC. People attempted to join the
meeting at different times based on whether they referred to UTC or to US
Eastern time. I apologize for the error, and I think that it has been
corrected for December.
The meeting style for the Café will emphasize discussion rather than
presentation. People are welcome to participate as listeners only if they
prefer.
Please see the page on Meta
<https://meta.wikimedia.org/wiki/Wikimedia_Caf%C3%A9> for more information
about the Café. Please watch the page for any updates, particularly to the
schedule or the agenda. Signing up for the meeting is optional, but is
helpful to the organizers so that we can estimate how many people will
attend. Signing up for the meeting also informs us who we should notify
individually if there are significant changes, such as to the schedule.
If there are any problems with connecting to the meeting or if you have any
questions or comments then please write on the Meta talk page.
Regards,
Pine
( https://meta.wikimedia.org/wiki/User:Pine )