Experience of harassment has
not declined since 2017 and appears to remain steady
At
what point and time does the foundation step in, as some language editions do and stop the warring and abuse by users and administrators
?
does
the board know what is going on here ?
and
it is not just EN wikipedia, but in all l anguage editions as well.
From: Edward Galvez
Sent: Thursday, September 13, 2018 5:59 PM
To: undisclosed-recipients:
Subject: [Wikitech-l] Results from 2018 global Wikimedia survey
arepublished!
Hi
everyone,
I'm excited to share that our annual survey about Wikimedia
communities is
now published!
This survey included 170 questions and
reaches over 4,000 community
members across
four audiences: Contributors,
Affiliate organizers, Program Organizers, and
Volunteer Developers. This
survey helps us hear from the experience of
Wikimedians from across the
movement so that teams are able to use
community feedback in their planning
and their work. This survey also helps
us learn about long term changes in
communities, such as community health
or demographics.
The report is
available on
meta:
https://meta.wikimedia.org/wiki/Community_Engagement_Insights/2018_Report
For
this survey, we worked with 11 teams to develop the questions. Once
the
results were analyzed, we spent time with each team to help them
understand
their results. Most teams have already identified how they will
use the
results to help improve their work to support you.
The report
could be useful for your work in the Wikimedia movement as well!
What are you
learning from the data? Take some time to read the report and
share your
feedback on the talk pages. We have also published a blog that
you can
read.[1]
We are hosting a livestream presentation[2] on September 20 at
1600 UTC.
Hope to see you there!
Feel free to email me directly with
any questions.
All the
best,
Edward
[1]
https://wikimediafoundation.org/2018/09/13/what-we-learned-surveying-4000-c…
[2] https://www.youtube.com/watch?v=qGQtWFP9Cjc
--
Edward
Galvez
Evaluation Strategist, Surveys
Learning &
Evaluation
Community Engagement
Wikimedia Foundation
--
Edward
Galvez
Evaluation Strategist, Surveys
Learning &
Evaluation
Community Engagement
Wikimedia
Foundation
_______________________________________________
Wikitech-l
mailing
list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello all,
Today we've successfully migrated our wikis (MediaWiki and associated
services)
from our primary data center (eqiad) to our secondary (codfw), an exercise
we've done for the 3rd year in a row. During the most critical part of the
switch today, the wikis were in read-only mode for a duration of 7 and a
half minutes - a significant improvement from last year.
Although the switchover process itself has been largely automated and went
pretty smoothly once started, we did experience some issues leading up to
our maintenance window, which caused us to delay the switch somewhat:
- In the days before the switch a performance issue in the Translate
extension for CentralNotice had been discovered, which was expected to
cause database stampede issues during the switch, and we decided to
mitigate this by temporarily disabling the
extension for the duration of the switchover process. However it's now
understood that this may have caused some unwanted side effects and should
be avoided in the future in favor of other methods.
- Right before the switchover commenced, an eqiad Varnish server
misbehaved, causing a high spike of failed requests. Thankfully the SRE
Traffic team identified and addressed the issue prompty, allowing the
switchover to proceed.
- Two codfw s7 database slaves crashed right before the start of our
maintenance window. This delayed the start of our switchover procedure by
approximately 30 minutes into our maintenance window as we were
investigating cause and impact.
- The ElasticSearch search cluster traffic did not follow MediaWiki traffic
from eqiad to codfw during the switch as was expected, but stayed in our
primary data center instead. Investigation showed that ElasticSearch had
been manually hardcoded to eqiad in its configuration. This was rectified
after the switchover was complete with a configuration change and manual
switch to codfw.
- After the switchover completed we experienced some repetitive database
load spikes, primarily on the codfw s1 cluster (serving English Wikipedia).
The DBA team performed a series of fine tuning and other corrective actions.
All wikis are now served from our secondary codfw data center, and this is
expected to stay that way for the next 4 weeks, when we will reverse this
procedure.
Should you experience any issue that is deemed related to the switchover
process, please feel free to file a ticket in Phabricator and tag it with
the Datacenter-Switchover-2018 project tag[1]. We will monitor this tag
closely and keep any and all issues updated.
We'd like to thank everyone for their hard work in ensuring any (potential)
issues got resolved timely, for automating the process whenever and
wherever possible, and for making this datacenter switch a success!
[1] https://phabricator.wikimedia.org/project/profile/3571/
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
Hello,
The CI jobs using Debian Stretch had their browser updated:
- Firefox v52 -> v60
- Chromium v68 -> v69
The reference task is: https://phabricator.wikimedia.org/T203902
If there is any trouble, please fill a subtask and we can help fix it or
eventually temporarily revert the CI configuration switch for your
repository.
Sincerely,
--
Antoine "hashar" Musso
https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-09-12
*=2018-09-12=*
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* Release Engineering:
** Log Health: Exception thrown for failure to save settings appears ~ 1000
times/day: https://phabricator.wikimedia.org/T202149
== Audiences ==
=== Contributors ===
==== Community Tech ====
* Blocked by:
* Blocking:
* Updates:
**
==== Anti-Harassment Tools ====
* Blocked by:
* Blocking:
* Updates:
**
==== Editing ====
* Blocked by:
* Blocking:
** Updates:
** Improve mobile dialogs, selections, and edit interfaces
==== Growth ====
* Blocked by:
* Blocking:
* Updates:
**
==== Language ====
* Blocked by: RelEng to review: https://gerrit.wikimedia.org/r/450508
* Blocking:
* Updates:
** CX: Performance improvements being worked on along with other continuous
work.
** Global Preferences now supports changing UI languages when enabled.
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
**6.0.1 released (minor bug fixes) (
https://phabricator.wikimedia.org/tag/ios-app-v6.0.1-walrus-on-a-golf-cart/)
** working on 6.1 (wikidata description editing) (
https://phabricator.wikimedia.org/tag/ios-app-v6.1-narwhal-on-a-bumper-car/)
** investigating visual editing capabilities of the iOS SDK
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
** Completing navigation updates based on user testing.
** Should release Echo notifications to beta by end of week.
==== Readers Web ====
* Blocked by:
* Blocking:
* Updates:
** Mobile website (MinervaNeue / MobileFrontend):
*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFro…
**** Transitioning several well-used files to Webpack T203100
**** Enable headless QUnit tests compatible with Special:JavascriptTest
T199452
**** Remove remaining white flicker from image overlay load T197110
**** Client side error reporting for Minerva+MobileFrontend follow-ups
T202026
**** Maintenance and bug fixes T203490 T202701
*** Page issues
https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
**** Bug fixes (thanks Tilman!): T203386 T203725 T203050 T202349 T203449
**** New / old treatment A/B test can be seen here
https://readers-web-master.wmflabs.org/wiki/Pharmacovigilance?mobileaction=…
*** Design and product are iterating on advanced mobile contributions nav
prototypes T203480
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
** Desktop website (Popups) https://www.mediawiki.org/wiki/Page_Previews
*** Fix failing isTranslatedTitleBlacklistedTest T203522
** Supporting Readers Infrastructure, Multimedia, and QA hiring processes
==== Readers Infrastructure ====
* Blocked by: None
* Blocking: None
* Updates:
** MCS, PCS: Nothing particularly exciting.
** Maps:
*** Upgrade to stretch on production starting next week after DC switch
T198622
*** Investigating tilerator crash on eqiad, the service needed a forced
restart T204047
*** New Grafana Dashboard for the beta cluster T202639
*** Kartographer bug changed maplink behavior (fixed) T203427
==== Multimedia ====
* Updates
** File page with multi-lingual captions in review
** MCR work begins this week
** Artwork/editing wikidata design continue
** Restore revisions in progress
** hiring!
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
==== UI Standardization ====
* Blocked by:
* Blocking:
* Updates:
** OOUI v0.28.2 released yesterday and addendum release of v0.28.1 last
week. Highlights:
*** NumberInputWidget: Rethink 'step' semantics (Bartosz Dziewoński)
*** 15 new icons added: 'camera', 'beaker', 'globe', 'helpNotics'
'hieroglyph','mathematics' & 3 'mathematicsDisplay*', 'chart',
'musicalScore', 'zoomIn' &'zoomOut'
*** Special icon treatment for Arabic language on 'info'
*** docs and tests improvements
** Special:Preferences OOUI rollout is prepared and coming.
https://phabricator.wikimedia.org/T180538 Last technical blocker on
Special:GlobalPreferences is on the way to be fixed.
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** old geowiki jobs and datasets have been turned off and deleted in favor
of the geoeditors data pipeline, accessible from Superset
** upgraded two more services to Stretch
** mediawiki history data quality checks have been automated, makes
releasing new snapshots easier
** continuing work on Presto, project family metrics, cummulative metrics,
a tinier EL module, annotations in Wikistats, helping with privacy hiring,
Schema Registry RFC
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** CentralNotice: Working on slowness and DB abuse when saving banners with
translatable messages. Thanks to language team and db ops for help with the
investigation https://phabricator.wikimedia.org/T203925
** CiviCRM: Making some progress on speed of importing donations, fixing
bugs in donor data export / delete tool
** New card processor API: more bug fixing, deploying script to resolve
pending transactions
** Working on hiring
=== MediaWiki Core Platform ===
* Blocked by:
* Blocking:
* Updates:
**
=== Performance ===
* Blocked by:
**
* Blocking:
**
* Updates:
**
=== Release Engineering ===
* Blocked by:
** DBA (in support of Reedy):
https://phabricator.wikimedia.org/T174802(EducationProgram
db dump in prep of removing the extension)
* Blocking:
** Language RelEng to review: https://gerrit.wikimedia.org/r/450508
* Updates:
** Train:
*** we had a UBN! backport needed on Thursday (
https://phabricator.wikimedia.org/T203566 )
*** This has been thoroughly documented in
https://phabricator.wikimedia.org/T156541 and it is a regularly recurring
problem which causes production breakage every time the structure of a
class is changed in an incompatible way. We can do better!
** Log Health:
*** Exception thrown for failure to save settings appears ~ 1000 times/day:
https://phabricator.wikimedia.org/T202149
=== Research ===
* Blocked by:
* Blocking:
* Updates:
=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
** Switched communication between ElasticSearch and Analytics cluster
toKafka: https://phabricator.wikimedia.org/T198490
** Enabled loading categories from daily diffs everywhere:
https://phabricator.wikimedia.org/T201217
** Fixed searching for strings starting with #:
https://phabricator.wikimedia.org/T182452
** Fixed bug in displaying results counts in search:
https://phabricator.wikimedia.org/T71382
** Upgraded disk space on WDQS servers:
https://phabricator.wikimedia.org/T196485
** Working on improving Korean analyzers:
https://phabricator.wikimedia.org/T178925
** Working on running multiple Elastic instances on the same hardware:
https://phabricator.wikimedia.org/T193654
** Working on searching for statement values without additional keywords:
https://phabricator.wikimedia.org/T163642
** Working on ES 6.3 upgrade: https://phabricator.wikimedia.org/T197960
Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
=== Security ===
* Blocked by:
* Blocking:
** Reading-web with T177765 (Sorry for delay)
* Updates:
** Work on phan-taint-check continues. Voting on lots of WM deployed
extensions now (Thanks Legoktm)
**Chromium-render review this week (sorry for delay)
=== Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Site Reliability Engineering ===
* Blocked by:
* Blocking:
* Updates:
**
== Wikidata ==
* Blocked by:
* Blocking:
* Updates:
** Finishing up Senses support in Lexicographical Data:
https://phabricator.wikimedia.org/project/view/2292/
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
**
== Multi-Content Revisions ==
* Blocked by:
* Blocking:
* Updates:
**
== SoS Meeting Bookkeeping ==
* Updates:
**
Reminder: Technical Advice IRC meeting again **Wednesday 3-4 pm UTC** on
#wikimedia-tech.
Question can be asked in English, German & Persian.
The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/
wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
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/681/51985.
Hi All,
A reminder that tomorrow TechCom is hosting an IRC discussion on: Create
a proper command-line runner for MediaWiki maintenance tasks
<https://phabricator.wikimedia.org/T99268>
This RFC proposes to create an organized structure and runner for
running of maintenance tasks.
The meeting is scheduled for Tuesday 11 September at 2pm PST(21:00 UTC,
23:00 CET) in #wikimedia-office. NOTE: this meeting is one day earlier
than TechCom IRC discussions are normally.
If you haven't joined a #wikimedia-office meeting before more
information can be found here:
<https://meta.wikimedia.org/wiki/IRC_office_hours#How_to_participate>
More information regarding the TechCom RFC process is available here:
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Processes#RFC_…>
Thanks,
Kate
--
Kate Chapman TechCom Facilitator (Contractor)
I noticed that WMF production accidentally had no PHP time limits.
Possibly it has been like that for as long as three years. The HHVM
configuration purportedly set the time limit to 60 seconds, but that
did not take effect.
I've deployed a change to set PHP time limits as follows:
* 60 seconds for GET requests
* 200 seconds for POST requests
* 20 minutes for ordinary job queue jobs
* 1 day for video scaler jobs
If it really has been three years of no time limits, this change may
break some accumulated assumptions. But note that Varnish times out
waiting for Apache after 120 seconds, so for most requests longer than
this, it would not have been obvious that HHVM continued to run, an
error was delivered anyway.
The logs so far show a trickle of timeouts from the parser, which is
normal by historical standards.
https://phabricator.wikimedia.org/T97192
-- Tim Starling