I've opened up a task on phabricator (T130812) about the question of how to make a good MediaWiki distribution. And I'd like to ask anyone interested in this topic for thoughts, suggestions and advice. Your help is highly appreciated. Details can be found on the task page .
tl,dr; if you enabled two-factor authentication on your
wikitech.wikimedia.org account this past week (since 23 March, 22:03 UTC),
the second factor may have been removed, and you should re-enable it.
The long version:
Several users in the past few days reported that they had 2FA required for
their wikitech account, but had not enabled it. This was my fault-- we
converted the database token format and didn't account for users who had
previously clicked on the "enable two-factor authentication" but never
finish the enabling process. These users (about 400, as best as we can
tell) were unfortunately locked out of their accounts as a result, after we
updated the token format.
I've disabled 2FA for accounts that looked like they were affected by our
update. Unfortunately, this may have disabled 2FA for users who recently
enabled 2FA also. So if you enabled 2FA on your account this past week, you
may need to re-enable it-- please login to wikitech and verify that 2FA is
still enabled for you account.
Apologies to everyone affected.
we're looking for a buddy to help / guidance with page-content-type handling
extension at Jerusalem Hackathon.
If you are familiar with it, but not coming to the hackathon, please let me
know as well.
Feel free to reply to me directly to not pollute the list.
Thanks for help.
The Reading team's Q4 goals for 2015-16 are posted on Media Wiki:
We arrived at these goals by taking the results of the Q4 brainstorming
<https://www.mediawiki.org/wiki/Reading/Quarterly_planning/Q4> and matching
them against our strategy, speed and strengths.
Below is a summary of what we aim to do in the April-June Quarter with more
context than what you see on our goals page. You will notice a lot of
cross-platform migration. That is no accident: we learn faster by
launching on one platform and then migrating the idea to others. The goals
are broken out by team or strategic theme.
*Community Tech: Community Wishlist items*
Ship features and fixes related to three wishes in the Wishlist Survey top
*Infrastructure: two-factor authentication*The infrastructure team will
enable two-factor authentication
<https://en.wikipedia.org/wiki/Two-factor_authentication> via AuthManager
on the Wikimedia cluster. The goal here is to add another layer of
security for accounts with important privileges.
*New Readers (was: "reach new users in the global south")*
*Web: decrease load time and cost for low-resource environments on mobile*This
will be accomplished through lazy loading
<https://en.wikipedia.org/wiki/Lazy_loading> of images, and cutting default
html size. This is in beta mobile channel by the end of this quarter and
we plan to measure results and roll out to all users over the course of Q4.
*Make a better encyclopedia experience*
*Web: hovercards*Specifically, enable hovercards
<https://www.mediawiki.org/wiki/Beta_Features/Hovercards> as default for
logged-out desktop users on more than one wiki (this one is dependent on
community approval). Hovercards represent a faster way of browsing
Wikipedia that most readers prefer (as indicated by this survey
It has been in beta for more than a year and the mobile version was
recently launched to all users on our Android app. This is not as simple
as turning on a switch, there are several improvements that will have to be
made. One reason we are launching this is to clean up our beta site before
picking up any new work. This is arguably "New Readers" as well, due to the
performance gains from loading fewer pages.
A community initiated proposal is being discussed to enable this on English
Wikipedia. Please chime in!
*Android: launch the feed*This quarter, the iOS team launched a feed on the
app home screen and it looks great and early results suggest users are
responding well to it. The goal is to drive user retention by giving
readers a reason to open up Wikipedia even if they don't have a specific
query in mind. The Android team will also be implementing backend services
to support the feed across platforms.
*iOS: Universal links*"Universal Links" (aka deep links) provide convenient
re-entry to the app from links and OS search, but do not advertise or
promote the app. This is something that is already live on Android and
partially supported on iOS. It allows users who prefer the app to open it
from links or an OS query, since that is how most users get to Wikipedia.
*A Community of Readers (interactive Wikipedia)*
This is the third pillar that came out of our strategy process. No active
development work is planned here. Future direction for this part of our
strategy is currently being explored via a community consultation here:
Your feedback or questions are welcome.
= *2016-03-2**3* =
== Product ==
=== Community Tech ===
** Waiting for jcrespo to do schema change for category sorting:
** Pageviews Analytics tool is feature complete (
http://tools.wmflabs.org/pageviews/), talking to communities about adding
links to it
** Deadlink logging API is finished, adding integration to Cyberbot
=== Reading ===
==== Reading Infrastructure ====
* *AuthManager is still coming!* (see three weeks ago for details)
** Behind schedule though, but we think we're about there on the core
* It looks like we're getting close on the load.php thing, too.
==== Mobile Content Service ====
** Fixed issue with lead paragraph transformation
** Starting rollout of Mobile Content Service to Android production app
this Thursday https://phabricator.wikimedia.org/T126934
==== Android ====
* 2.1.143 beta published. Expected to be promoted to production soon.
==== iOS ====
** 5.0.1 was released today - all bug fix updates
** Hockey app is currently much happier - less crashes
** Enabling handoff from Mac browser to iOS app and credentials sharing by
updating a file on the server
** No time frame for next release (but expect it within 3 weeks) -
currently deciding whether to do another bug fix or do 5.1 with features
* Lazy loaded images rolling to beta mobile web
* Structured Language Overlay - trying to push it to 100% stable
* Language Switcher button - beta for now
* Lazy loading references
* Bug fixes and tweaks to the Language Overlay
* Ship the language switcher
* Semi-structured sprint
=== Editing ===
==== Collaboration ====
** External store work
** Working on support for Flow notifications being properly hidden on
** Work on the Echo special page
** Changed MobileFrontend to reuse Echo code
** Working on Flow bug fixes
==== Language ====
** New MT deployments blocked due to
** Work on ContentTranslation continue.
==== Multimedia ===
** UploadWizard fixes and performance stuff on the way, currently in the
** ImageTweaks is slow going, currently there's a patch in core that it
depends on, probably won't be moving as quickly as we thought
==== Parsing ===
** Somewhat of a lull in activity last couple weeks (with vacation, time
off, 20% work)
** But, heads up for VE, CX, Flow, Reading teams about
https://phabricator.wikimedia.org/T78676 -- been filing dependent tasks for
various teams. Parsoid side of the work should mostly be ready for merge in
2-3 weeks. But, other dependent tasks need to be resolved, performance and
client blockers will be considered before enabling this in production.
==== VisualEditor ===
* No update.
== Advancement ==
=== Fundraising Tech ===
* No blocking/blockers
* DonationInterface mw1.27 tests are failing on some i18n core change, but
they're no longer voting
* Raft of CiviCRM enhancements to make logging more robust and enable
reverting contact merges
* Testing new Latin American payment methods in previously unpestered
* Pondering how to make payments use a more recent version of mediawiki
* More DonationInterface refactoring
== Technology ==
=== Release Engineering ===
** Reminder: Code freeze & Dallas switchover week of April 18
** Trebuchet -> Scap migration! Get in touch if you need it
*** There is a super secret irc channel on freenode, cryptically named
*** scap 3.1 should be deployed soon, now with moar git-fat support. This
will unblock some services switching from Trebuchet to scap.
=== Research ===
==== Research and Data ====
** ORES blocked on MW core code review
*** What is the normal workflow for getting code reviewed?
**** typical turn-around time?
**** documentation for engaging +2 people?
** ORES downtime over the weekend
*** tl;dr pip doesn't remove old versions when installing new wheels
=== Security ===
** 2FA updates for wikitech today. 2FA available on SUL wikis to Staff next
=== Services ===
** Ops: change-prop deploy - https://phabricator.wikimedia.org/T128463
** RESTBase to start redirecting non-normalised titles and commons URLs
** DC switch-over for RESTBase && node services successful -
** Mathoid and RESTBase now support PNG generation
** Scap3: should have a guide soon for node.js services
=== Technical Operations ===
** Services on changepropagation deploy
** All the rdb100* hosts (Redis Job Queue) have been re-imaged with Debian.
** ORES database hosts ready, looking for some help with scap3 and ORES
==== Discovery ====
** Ops: https://phabricator.wikimedia.org/T127014
** Security review: SVG sanitizer for graphs -
** ZRR down following completion suggester deployment:
** Working on scoring improvement for search and suggester
** Working on connection pooling for ES
** Join #wikimedia-interactive for interactions about interactive content!
Forwarding info about an opportunity to intern in product management with
Wikidata and the good people at Wikimedia Deutschland.
---------- Forwarded message ----------
From: "Lydia Pintscher" <Lydia.Pintscher(a)wikimedia.de>
Date: Mar 24, 2016 07:24
Subject: [Wikidata] internship opening: product management at WMDE
To: "Discussion list for the Wikidata project." <
Hey folks :)
I am looking for someone to support me me with my product management work
at WMDE as an intern. If you'd love to work with me and the rest of the
team, love Wikidata and want to learn, this might be the thing for you.
More details are here:
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
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 mailing list
please have a look at this week's summary of new and ongoing RFC
discussions. There are several new RFCs, and some existing ones are moving
close to a decision. No RFCs were decided finally this week.
Because of the parallel Hackathon, no IRC discussion is scheduled for next
T130663 WIP RFC: Reference API requirements and options
<https://phabricator.wikimedia.org/T130663> (Timo): API access and
component markup for references; focus on gathering use cases /
T122942 RFC: Support language variants in the REST API
<https://phabricator.wikimedia.org/T122942> (Gabriel): Different options
for supporting languange variant selection in the REST API. Needed for
languages like Chinese.
T122825 Service Ownership and Maintenance
<https://phabricator.wikimedia.org/T122825> (Gabriel): Ownership and
minimum maintenance requirements for production services. Strongly driven
by unclear ownership of OCG (PDF renderer).
T39902 RFC: Implement rendering of redlinks (in a post-processor?)
<https://phabricator.wikimedia.org/T39902> (Gabriel): Solutions for
highlighting links to non-existing pages in Parsoid HTML. Main question is
preprocessing vs. separate metadata processed on client.
T130528 RFC: PSR-6 Cache interface in Mediawiki core
<https://phabricator.wikimedia.org/T130528> (No shepherd): Exploring use of
standard PHP cache interface.
Today's IRC session:
T124792 Service Locator for MediaWiki core
<https://phabricator.wikimedia.org/T124792> (Daniel): Introduce a service
locator (aka DI container) to allow code in mediaWiki core to make use of
the Dependency Injection (DI) and Service Locator (SL) patterns.
The discussion showed general support. Several participants expressed a
desire to write more code with it before making a final call. Concrete
suggestions on areas would be welcome. Tentative working group forming,
aiming to discuss at Jerusalem Hackathon.
T129435 RFC: drop support for running without mbstring
<https://phabricator.wikimedia.org/T129435> (Gabriel): Very focused RFC by
Max. Main question in discussion so far is whether polyfilling is worth it.
Max reaching out to mediawiki-l.
<https://phabricator.wikimedia.org/T108655> (Roan): No update since last
week, I need to split this task but I haven’t had time to yet. Last week’s
Considering to split out contentious part (file-based require, or something
like it; to support embedding libraries), move forward on less
controversial part (basic module-name-based require infrastructure)
T18691 RFC: Section headings should have a clickable anchor
<https://phabricator.wikimedia.org/T18691> (Timo): Under discussion with
Volker and Frontend Standards Group. Volker and team to collect different
benefits and concerns to determine whether this is generally a desirable
feature. And to explore other conceptually different solutions to the
underlying use case of “sharing a link to a section” (e.g. a better table
of contents, or live address bar).
T124504 Transition WikiDev '16 working areas into working groups
<https://phabricator.wikimedia.org/T124504> (RobLa): No concrete progress;
MZMcBride advocates for organic growth.
T128351 RfC: Notifications in core
<https://phabricator.wikimedia.org/T128351> (Brion): No movement last week.
Needs clarification of interfaces & scope as follow-up from IRC meeting.
T66214 Use content hash based image / thumb URLs & define an official thumb
API <https://phabricator.wikimedia.org/T66214> (Brion): Clarified
requirements & priorities in last week's IRC discussion. Needs update to
T118517 [RFC] Use <figure> for media
<https://phabricator.wikimedia.org/T118517> (Brion): Revisit soon.
T88596 Improving extension management
<https://phabricator.wikimedia.org/T88596> (Daniel): Discussion is picking
up again, patch for review.
T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
<https://phabricator.wikimedia.org/T113034> (Daniel): Has been discussed
before, needs somebody to actually take this on.
T114444 [RFC] Introduce notion of DOM scopes in wikitext
<https://phabricator.wikimedia.org/T114444> (Tim): Active related
discussion and prototyping at Balanced templates
<https://phabricator.wikimedia.org/T114445> and Hygienic transclusions for
WYSIWYG, incremental parsing & composition: Options and trade-offs
Please join for the following tech talk:
*Tech Talk**:* New readership data: Some things we've been learning
recently about how Wikipedia is read
*Presenter:* Tilman Bayer
*Date:* March 18th, 2016
*Time: *18:00 UTC
Link to live YouTube stream <http://www.youtube.com/watch?v=Qo4XIzCJZVs>
*IRC channel for questions/discussion:* #wikimedia-office
*Summary: *This talk will highlight various recent insights and new sources
of data on how readers read Wikipedia, going beyond the familiar pageview
numbers (that tell us which topics are popular and how overall traffic is
developing, but not e.g. which parts of articles are being read). While we
are still only beginning to understand some of these aspects, we now know
more than a year or two ago. The presentation is centered around data
analysis done by the Reading team, but will also include findings by other
WMF teams and by external researchers.