"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki CREDITS file
. It had been sitting there for over a year. He doesn't seem to
have been active since. I don't know what to do with it. It made me
Do we have it documented anywhere how we use this credits file and why
we feel the need to distinguish between Developers and Patch
Contributors? It seems like a recipe for disaster in my opinion as it
can only lead to hurt feelings due to contributors feeling unfairly
treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
with 'We would like to recognize the following persons for their
contribution to MediaWiki." - if someone is not in that list are they
not as important?
If we keep these files we should probably explain the rules to what
adding names looks like within these files and what the process to
adding your name is (can I add myself? Is there a process like getting
To take another extreme, we might consider abandoning such a file in
favour of something automatically generated. Things like
https://github.com/wikimedia/mediawiki/graphs/contributors do a far
better job at allowing people to see who contributed to a tool and
making people feel like their work is rewarded.
On a slightly related note, can we abandon the practice of putting
PHP files throughout core (grep for @author). As Team Geek  (great
read btw) says "unlike other collaborative pieces of creative work...
software keeps changing even after it's "done". So while listing
contributors credits at the end of a movie is a safe and static thing,
attempting to add and remove names from a source file is a
never-ending exercise in insanity". For similar reasons this practice
gives an impression of ownership of a file/code review
responsibilities (which are not always true) and risks hurt feelings.
= 2016-07-06 =
== Product ==
=== Reading ===
==== iOS ====
* 5.0.5 has been delayed for 2 more weeks due to new regressions.
** We are restarting the entire beta process because the 5.0.5 release
diverged significan;ty from the trunk
** A new 5.0.5 with changes more recent bugfixes from the main trunk is
being redeployed to beta this week
** 5.0.5 will re-enter regression next week
* 5.1 features are being re-evaluated due to the long development time of
** Some 5.1 features will likely be moved to 5.2
* Discovery is helping us improe the map UI first developed on Android by
implementing some Geodata API enhancements (
==== Android ====
Finishing touches on the feed.
==== Mobile Content Service ====
* Experienced more than a dozen Nagios checker failures (timeouts) due to
increased memory usage by ORES last weekend. Got fixed on Monday.
* Feed endpoint improvements:
* redirect to summary endpoint for random and TFA if possible.
* adding date input validation for feed endpoints which accept dates
Blocked on Services team:
* We need the public feed endpoints (aggregated feed + random page) to
enable the feed functionality for a beta Android app release. This is
blocking the Android teams quarterly goal.
==== Reading Web ====
* Wikidata descriptions to mobile web stable in ca.wiki and pl.wiki
* Deployed lazy references and images to mobile web tl.wiki
* Fixing some bugs with hovercards to improve data analysis from A/B test
* Started working in improvements to language switcher in mobile web
==== Reading Infrastructure ====
=== Community Tech ==
* Deploying PageAssessments extension to test.wikipedia (
* Finishing work on CopyPatrol Tool (https://tools.wmflabs.org/copypatrol)
** Replication lag on Tool Labs has been a major problem. We are migrating
from local DB queries to API requests to avoid the problem.
* Figuring the out the best implementation plan for switching to UCA
collation + numerical sorting for categories
* No blockers
=== Editing ===
==== Multimedia ====
* https://phabricator.wikimedia.org/T138273#2410743 MatmaRex needs review
from *anomie, tgr, and AaronSchulz*.
* Still waiting for Thumbor deployment to carry ImageTweaks forward, Gilles
says he's working on Debian packaging
* Continuing work on FileAnnotations
* Continuing work on getting rid of fatal errors in UploadWizard
==== Collaboration ====
* Blocking - No change
* Blocked - None
** Deployed to group 0 new enhanced Echo bunding (with the ability to
expand and collapse bundles of notifications and act on individual
notifications), changed sorting of Alerts and Messages
** Deployed new version of Special:Notifications with per-page notification
==== Parsing ====
* Co-ordinating with Services to resume work on Parsoid migration to use
service-runner utility. This blocks upgrade of parsoid production cluster
to node 4.x (from 0.10) and deployment process to scap3 (from trebuchet)
* Continuing to work on a bunch of bug fixes in Parsoid.
* Work ongoing (Tim & Scott) to land a PHP HTML5 parser in core which can
serve as a default Tidy replacement solution for mediawiki.
== Wikidata ==
* Focus on refactoring the Sites mess in core, starting with:
https://phabricator.wikimedia.org/T137537, tracked in:
* Core support for multilingual wikis:
* Ongoing communication about Multi Content Revision support in core:
== Technology ==
=== Analytics ===
* Will start working on migrating refinery to SCAP 3 tomorrow (cc: release
* Ongoing work on Event Bus, scaling AQS and the Pageview API,
reconstructing mediawiki history, and loading Druid with pageview data
=== Research ===
* ores.wikimedia.org online (woo ops). ores.wmflabs.org will remain online
and a deprecation plan will be announced "soon"
* Major ORES downtime was exacerbated by icinga config failure (301 is a
good response and not followed by default)
* ORES extension deployed to fawiki and wikidatawiki. Large wikis coming
=== Security ===
* Other security reviews are being schedule; if you have need, please
submit your request:
* A security release will be prepared soon
* Reviews: 3d2png (cont.), Tool Labs Console
=== Services ===
* out for two weeks - Wikimania + Offsite
** lots of interesting discussions
* Auth / session storage service
** discussed the plan with Darian
** will draft an Arch RfC soon
* Nodejs migration to 4.4.6
** scheduled for next wednesday
** test your services and update your package.json to use node v4.4.6
** especially important for SCB services
=== Fundraising tech ===
* Building and deploying new payments servers to get off precise and php 5.3
* Also upgrading mediawiki and CiviCRM, planning how we'll more closely
follow mw master
* More work towards de-duplicating donor database
* CentralNotice: don't load anything on Special: or action=edit
* Still investigating what looks like missing log entries (delivered via
=== Discovery ===
* '''Blocking''': none
* '''Blocked''': none
* Hired new data analyst, she starts end of July
* TextCat A/B finished, analyzing results
* Working on enabling boxed search by coordinates with near: and
neartitle: - https://gerrit.wikimedia.org/r/#/c/297524/
* Logstash elasticsearch upgrade planned for July 7th (
https://phabricator.wikimedia.org/T136001). This also includes upgrade to
* Portal stats updated on June 30th
* Portal survey on why people come to Portal are published:
==== Maps/Graphs =====
* Geoshapes service is integrated with WDQS and can provide both wikidata
data and shapes: http://data.wmflabs.org/wiki/Regional_maps
=== RelEng ===
* Blocking: none?
** Target architecture without gallium (email followup)
** Browser Testing survey still open https://goo.gl/xS6mmV (phab task for
** CI reduced yesterday, should be good now
** Scap3 migration - new guide posted on wikitech
=== Technical Operations ===
** By noone
** All image scalers are now on jessie with updated librsvg, fixes plenty
of bugs (also related to changes to fonts while at it)
** Enabled TCP Fast Open on some caching clusters
** gitblit is finally dead
** Working with LE to get apertium packages reviewed/uploaded on
apt.wikimedia.org. Some 20% done
The next CREDIT showcase will be Wednesday, 6-July-2016 at 1800 UTC (1100
Please add your demos to the Etherpad.
For this one we'll use the YouTube stream for viewers and Hangouts on Air
See you next week!
Etherpad , our real-time colaborative editing tool suffered an
outage due to what we only know for now was database corruption. This
was detected shortly after it happened 14:27 UTC and we (ops in charge
of the service and the database) worked to reestablish the service.
As the service continued crashing despite our efforts, we decided to
recover a database backup from 2016-06-22 01:00:01 UTC. The service is
now back up and working since 16:11 UTC, but that means that you may
have lost a day and a half of edits in the current available etherpad
I understand that that may cause a lot of inconveniences, specially
for the people at Wikimania. *We are now trying to recover more than
that*, but as the corruption could come back, or not all could be
recovered, and people need the service the plan is the following:
- Keep the current pads as is, not delete or add anything from now.
You can continue using etherpad now as usual.
- If possible, recover the last days of edits on a separate location.
See  for progress if you are affected.
Sorry for the inconveniences. Please, more than ever, follow the
recommendation we added at the beginning of every empty pad:
> "Keep in mind as well that there is no guarantee that a pad's contents will always be available. A pad may be corrupted, deleted or similar. Please keep a copy of important data somewhere else as well"
The reason for this is that wiki content has proper HA and redundancy,
etherpad does not.
Again, my most sincere apologies,