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
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?
Following the recent outage, we've had a new series of complaints
about the lack of improvements in CX, especially related to
server-side activities like saving/publishing pages.
Now, I know the team is involved in a long-term effort to merge the
editor with the VE, but is there an end in sight for that effort? Can
I tell people who ask "look, 6 more months then we'll have a much
better translation tool"?
Is there a publicly available roadmap for this project and more
generally, for CX?
Please join for the following talk:
*Tech Talk**:* A Gentle Introduction to Wikidata for Absolute Beginners
*Presenter:* Asaf Bartov
*Date:* February 09, 2017
*Time: *19:00 UTC
Link to live YouTube stream <https://www.youtube.com/watch?v=eVrAx3AmUvA>
*IRC channel for questions/discussion:* #wikimedia-office
*Summary: *This talk will introduce you to the Wikimedia Movement's latest
major wiki project: Wikidata. We will cover what Wikidata is, how to
contribute, how to embed Wikidata into articles on other wikis, tools like
the Wikidata Game, and how to query Wikidata (including SPARQL examples).
Extension:Math removed client side MathJax support after MW 1.25. This
makes setup of the Math extension considerably more difficult. Mathoid was
fairly straightforward, but RESTBase seems like it is much more
complicated. Is RESTBase a hard requirement? Is there any way to connect to
Mathoid directly, the way VE can connect to Parsoid directly?
Hi, the Wikimedia Foundation has published a draft of its Annual Plan
and it welcomes your review.
I want to highlight here the improvements that we are proposing to the
developer events (co)organized by the WMF. From local to global:
The Technical Collaboration team proposes to combine multiple activities
(often disconnected) in a single program focusing on onboarding new
want to work with the Wikimedia technical community to bring a new wave of
developers to our projects, and events play an important role.
Local developer events
We want to support developers and organizations willing to reach out to
specific groups and geographies. We are hoping to see many local developer
meetups and small hackathons or workshops around the World, starting small
and simple. We should be able to offer introductory materials, contacts
with Wikimedia developers in the region, maybe travel budget to send
experienced volunteers to help mentoring the in the bigger events, maybe
travel budget to invite the best newcomers to our regional and global
Adding tech to regional Wikimedia events
Last year we experimented organizing technical workshops in WikiArabia, and
others have done similar efforts in other regional events (for instance, a
small hackathon next to WikiConference India). We want to work with the
organizers of these regional events in order to attract experienced
Wikimedia developers and newcomers, organize developer activities, and also
improve the collaboration between the technical and non-technical
contributors in these regions.
Better retention of newcomers at the Wikimedia and Wikimania hackathons
Although we don't expect major changes in the organization of the Wikimedia
Hackathon and the hackathon at Wikimania, we want to focus better on new
developers onboarding and retention. In every Hackathon we meet many new
developers, but the retention rates are very low. We want to review what we
can do before, during, and after these apparently successful events in
order to retain newcomers better. One hypothesis is that we should focus
call for participation, scholarships, and Wikimedia Foundation
participation in providing a great experience to new volunteers who have
gone through local and regional events, and also "junior" developers coming
from wiki projects through the development of bots, gadgets, tools,
A smaller and more focused Wikimedia Developer Summit
After some discussions between Community Engagement, Technology, and
Product, we have decided to propose a different approach for the Wikimedia
Developer Summit. Organized by the Technology department as part of
efforts, we want the Summit to finally become the venue where the toughest
technical problems are discussed between the stakeholders directly related.
We want to reduce the size/budget of the event, separate it from the WMF
AllHands, and define its main themes well in advance.
A Program Committee <https://phabricator.wikimedia.org/T160996> would
decide these main themes to be discussed at the Summit. We also want to
explore the possibility of tackling some of these themes at the Wikimedia
Hackathon and Wikimania, where we could get most stakeholders involved with
just a little extra effort (since many of them would be attending anyway).
We believe that this approach will serve better the Wikimedia technical
community that we have, and also the the community that we want to have,
with a new wave of developers joining our various projects.
Engineering Community Manager @ Wikimedia Foundation
You may have heard already that, like last year, we are planning to
switch our active datacenter from eqiad to codfw in the week of April
17th and back to eqiad two weeks later, on the week of May 1st. We do
this periodically in order to exercise our ability to run from the
backup site in case of a disaster, as well as our ability to switch
seamlessly to it with little user impact.
Switching will be a gradual, multi-step process, the most visible step
of which will be the switch of MediaWiki application servers and
associated data stores. This will happen on April 19th (eqiad->codfw)
and May 3rd (codfw->eqiad), both at 14:00 UTC. During those windows, the
sites will be placed into read-only mode, for a period that we estimate
to last approximately 20 to 30 minutes.
Furthermore, the deployment train will freeze for the weeks of April
17th and May 1st, but operate normally on the week of April 24th, in
order to exercise our ability to deploy code while operating from the
Compared to last year we have improved our processes considerably, in
particular by making more services operate in an active/active manner,
as well as by working on an automation and orchestration framework to
perform parallel executions across the fleet. The core of the MediaWiki
switchover will be performed semi-automatically using a new software
that will execute all the necessary commands in sequence with little
human involvement, and thus lowering the risk of introducing errors and
Improving and automating our processes means that we're not going to be
following the exact same steps as last year. Because of that, and
because of other changes introduced in our environment over the course
of the year, there is a possibility of errors creeping into the process.
We'll certainly try to fix any issues that arise during those weeks and
we'd like to ask everyone to be on high-alert and vigilant.
To report any issues, please use one of the following channels:
1. File a Phabricator issue with project #codfw-rollout
2. Report issues on IRC: Freenode channel #wikimedia-tech (if urgent, or
during the migration)
3. Send an e-mail to the Operations list: ops(a)lists.wikimedia.org (any time)
Principal Operations Engineer
Acting Director of Technical Operations