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?
I've been meaning to document this for a while.
If you're finding yourself visiting Special:Export/Import often for the
purpose of MediaWiki development there is a much better way to get content
into your local wiki for testing purposes.
This short video explains how MobileFrontend extension provides tooling to
help you debug live on-wiki content via $wgMFContentProviderClass 
Hope it saves someone lots of time!
Senior Software Engineer
One update regarding this.
We enabled using the new table for Special:Tags in several large wikis
which caused a massive improvement in the performance of the page. For
example loading Special:Tags on Wikidata used to take around a minute and
now it takes less than a second. English Wikipedia is down from ten seconds
to less than one and so on.
There is a lot of work needs to be done and maintenance scripts is being
ran to backpopulate the ct_tag_id column in change_tag table (If you want
to follow the progress, see https://phabricator.wikimedia.org/T193873) and
then we need start reading from the new table in mediawiki and finally we
can drop ct_tag column entirely. If you want to help in review, writing
code or anything, just let me know.
On Wed, 27 Jun 2018 at 15:15, Léa Lacroix <lea.lacroix(a)wikimedia.de> wrote:
> Hello all,
> Our team is refactoring some code around the change tags on Recent
> Changes. This can impact people using the database on ToolForge.
> Currently, the tags are stored in the table change_tag in the column
> In the next days, we will add a column ct_tag_id with a unique identifier
> for these tags. A new table change_tag_def that will store the tag id,
> the message, and more information like how many times this tag is used on
> the local wiki.
> On the long term, we plan to drop the column ct_tag since the tag will be
> identified with ct_tag_id.
> This change will happen on:
> - French Wikipedia: Monday July 2nd
> - All other wikis: from July 9th
> If there is any problem (trouble with saving edits, slow down of recent
> changes…) please create a subtask of T185355
> <https://phabricator.wikimedia.org/T185355> or contact Ladsgroup
> Léa Lacroix
> Project Manager Community Communication for Wikidata
> Wikimedia Deutschland e.V.
> Tempelhofer Ufer 23-24
> 10963 Berlin
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt
> für Körperschaften I Berlin, Steuernummer 27/029/42207.
> Wikidata-tech mailing list
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
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.
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
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:
Comments and questions welcome!
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?
On 6th July 2017, we made an announcement  about our plans to replace
with RemexHtml on the Wikimedia cluster.
On 5th July 2018, we made the final switchover from Tidy .
For those of you interested, we published a blog post  documenting the
process and steps in this project.
RemexHtml is the default in MediaWiki since 1.31.
We are in the process of removing all traces of Tidy from Wikimedia's
configuration files and from MediaWiki itself. We'll keep the
extension enabled in its current form for another couple of months.
period, the ParserMigration extension will be disabled completely
associated Tidy configuration. It will be re-purposed at a later time as
to compare impacts of other parser changes.
We haven't figured out the timeline yet, but at some point in the coming
we'll disable most of the high-priority linter categories that only make
in the context of replacing Tidy. If you have any thoughts about
dropping these categories, please leave a note on
As noted in the blog post , this was a collaborative effort between the
several teams at the Wikimedia Foundation and volunteer editing
various wikis. Everyone involved played important and specific roles in
us to this important milestone. An active embrace by various wikis of this
effort has let the Foundation make this much-needed and important
upgrade of a
key piece of our platform.
In that context, I want to take this opportunity to specifically name
some of these individuals.
Tim Starling, C.Scott Ananian, Kunal Mehta, Arlo Breault, and yours
all the technical work in core, Parsoid, and the extensions. Erica Litrenta
and Sherry Snyder helped develop the community engagement plan with various
wikis and specific editors. Sherry, in particular helped a lot in the final
months as we were trying to get more wikis to fix pages. James Forrester
helped review and provide feedback at various stages, especially with the
phased deployment. A number of other developers and staff were involved in
review, feedback, during RFC discussions, and in helping with fixing
templates where I couldn't do so myself.
Here is a subset of users across several wikis that I had an opportunity to
interact with and observe who helped in various ways: developing bots and
gadgets, writing help pages, asking clarification questions, providing
feedback, reporting bugs on wiki and Phabricator, and fixing lots of pages
and templates on their home and other wikis.
User:Daimano Eaytoy, User:Sakretsu, User:Anamalocaris, User:Izno, User:Lsj,
User:xaosflux, User:PerfektesChaos, User:Lómelinde, User:Ikhitron,
User:星耀晨曦, User:Deryck Chan, User:Sunpriat, User:Stryn, User:MawaruNeko,
User:NicoV, User:Bdijkstra, User:Skalman, User:Shakespearefan00,
User:Billinghurst, User:MarcoSwart, User:Mackensen, User:Andriy.v,
User:Jonesey95, User:TheDJ, and the anonymous wiki user whoever you are. :-)
Obviously, there were a number of others users involved in this effort.
feel free to raise your hand or recognize other's contributions on this
My thanks to you all!
In the TechCom committee meeting yesterday, it was decided that next
week's RFC meeting will discuss T198256 "Modern Event Platform -
Choose Schema Tech"
This relates to the choice between Avro and JSONSchema for the next
iteration of EventLogging.
The meeting will be at 1pm Wednesday PST in #wikimedia-office.
-- Tim Starling