Am 07.04.2016 um 20:00 schrieb Moritz Schubotz:
> Hi Daniel,
>
> Ok. Let's discuss!
Great! But let's keep the discussion in one place. I made a mess by
cross-posting this to two lists, now it's three, it seems. Can we agree on
<wikitech-l(a)lists.wikimedia.org> as the venue of discussion? At least for the
discussion of MathML in the context of Wikimedia, that would be the best place,
I think.
-- daniel
Peter Krautzberger, maintainer of MathJax, apparently thinks that MathML has
failed as a web standard (even though it succeeded as an XML standard), and
should be removed from HTML5. Here's the link:
https://www.peterkrautzberger.org/0186/
It's quite a rant. Here's a quick TL;DR:
> It doesn’t matter whether or not MathML is a good XML language. Personally, I
> think it’s quite alright. It’s also clearly a success in the XML publishing
> world, serving an important role in standards such as JATS and BITS.
>
> The problem is: MathML has failed on the web.
> Not a single browser vendor has stated an intent to work on the code, not a
> single browser developer has been seen on the MathWG. After 18 years, not a
> single browser vendor is willing to dedicate even a small percentage of a
> developer to MathML.
> Math layout can and should be done in CSS and SVG. Let’s improve them
> incrementally to make it simpler.
>
> It’s possible to generate HTML+CSS or SVG that renders any MathML content –
> on the server, mind you, no client-side JS required (but of course possible).
> Since layout is practically solved (or at least achievable), we really need
> to solve the semantics. Presentation MathML is not sufficient, Content MathML
> is just not relevant.
>
> We need to look where the web handles semantics today – that’s ARIA and HTML
> but also microdata, rdfa etc.
I think both, the rendering as well as the semantics, are well worth thinking
about. Perhaps Wikimedia should reach out to Peter Krautzberger, and discuss
some ideas of how math (and physics, and chemistry) content should be handled by
Wikipedia, Wikidata, and friends. This seems like a cross roads, and we should
have a hand in where things are going from here.
-- daniel (not a MathML expert all all)
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-04-06
= 2016-04-06 =
== Product ==
=== Editing ===
==== Collaboration ====
* '''Blocking''':
** External store work
* '''Blocked''':
* '''Updates''':
** Working on support for Flow notifications being properly hidden on
moderation
** Work on the Echo special page
*** Looking into removing one or two of the formats output by the Echo
API; see https://phabricator.wikimedia.org/T130661 for details
** Working on improving Flow user experience when page is protected or
otherwise not editable
** Flow dumps now have XSD schema on MediaWiki.org. Waiting on ops for
the actual dumps. Let us know if there's anything we can do.
==== Language ====
* '''Blocking''':
* '''Blocked''':
* '''Updates''':
** Working on ULS+Compact Language Links+Translate this sprint.
** To RelEng: https://phabricator.wikimedia.org/T53731#2160828 -
refresh-translatable-pages needs to be run on all wikis using Translate
- any possible blocker or go ahead for this?
==== Parsing ====
* Updates
** Kunal joined the parsing team (see wmfall, wikitech-l announcement)
** As of yesterday, Parsoid will now generate localized image options
(e.g thumb, left). This is a followup based on changes to core that
reordered aliases for wikis so that Parsoid can pick a consistent choice
and generate the wiki's preferred alias. The full change will take
effect once the m/w train finishes deploy tomorrow
** Additional work ongoing to replace Tidy with a HTML5 parser -- some
essential Tidy functionality is now implemented as DOM passes. We'll
likely not replicate all of Tidy functionality and deliberately break
some corner case functionality that probably only matters for parser
test runs. Announcement on wikitech-l in the coming weeks.
** Work ongoing to get a m/w install initialized with 60K+ titles from
41 wikis (wikipedia, wikisource, wiktionary, wikivoyage) for visual diff
testing -- this is proving to be somewhat of a painful process since
dump import is slow and running into troubles with mediawiki vagrant
(not sure if it is the import process or if it is mediawiki-vagrant --
getting help from Kunal and Bryan)
=== Reading ===
==== Reading Infrastructure ====
* AuthManager is getting closer!
*** SECURITY: We should be ready for finishing up the security reviews
on the AuthManager core bits.
**** Main: https://gerrit.wikimedia.org/r/#/c/195297/
**** API: https://gerrit.wikimedia.org/r/#/c/265201/
**** UI: https://gerrit.wikimedia.org/r/#/c/240052/
* Wikibase bug https://phabricator.wikimedia.org/T131176 seems to be the
* only blocker remaining for turning on load.php session access errors.
==== iOS ====
* '''Blocking''':
** none
* '''Blocked''':
** none
* '''Updates''':
** 5.0.2 Deployed this week to fix universal links issues cause by
Apple's iOS 9.3 update
** 5.0.3 in progress, likely deploying in 2-3 weeks
** SWAT deployment scheduled this week to support App to Browser Handoff
and sharing of credentials between Safari and the iOS app
(https://phabricator.wikimedia.org/T128795)
** Working with Apple to fix universal links not working on lower
traffic domains (https://phabricator.wikimedia.org/T131250)
==== Android ====
* '''Blocking''':
** none
* '''Blocked''':
** none
* '''Updates''':
** Working to get Reading Lists wrapped up
** Next up: The Feed
==== Web ====
* Near to deploying updated "Read in other language" button icon to top
* of mobile web
* New mobile web language overlay running at 100%
* Request: initial security assessment of HoverCards
* Image lazy loading in beta
* Reference lazy loading WIP
==== Mobile Content Service (MCS) ====
* Rolled out to 50% of Android prod app installs
* https://phabricator.wikimedia.org/T126934
* Fixed page title issue when parsing redirects in Parsoid payload
* https://phabricator.wikimedia.org/T131406
* Had some stale content on some main pages that are not in main
* namespace https://phabricator.wikimedia.org/T123938
=== Community Tech ===
* No blockers
* Finished work on pageviews tool, is now linked from several projects:
* http://tools.wmflabs.org/pageviews/
* Continuing work on deadlink fixing, will soon be detecting it's own
* dead links rather than relying on templates
* Continuing work on PageAssessments extension
** https://www.mediawiki.org/wiki/Extension:PageAssessments
* Getting security review for Gadgets 2.0 from Darian Anthony Patrick
== Discovery ==
* '''Blocking''':
** Not that we are aware of
* '''Blocked''':
** Security review: SVG sanitizer for graphs -
https://phabricator.wikimedia.org/T125382
* '''Updates''':
** Weekly status updates:
https://www.mediawiki.org/wiki/Discovery/Status_updates
** We began working on structured on-wiki storage (tabular, json,
geojson, ...)
== Fundraising Tech ==
* No blocking / blockers
* running 1 hr full traffic test in Argentina, Colombia, Chile, and
* Uruguay
** (still working out Mexico bug)
* planning integration with new PayPal API
* more DonationInterface refactoring
* more work towards reversible CiviCRM merges
* email unsubscribe fixes
* Netherlands bank transfer fixes
* Education Program needs rails dev, has money for contractor. Might be
* able to use WikiEducation Foundation, but if you have suggestions
* please contact Tighe Flanagan
== Technology ==
=== Research ===
* '''Blocking''': none
* '''Blocked''':
** MediaWiki core patches
*** https://gerrit.wikimedia.org/r/#/c/278841/ -- Re-introduce
"Templatize Special:Contributions lines"
*** https://gerrit.wikimedia.org/r/#/c/279925/ -- Add hook to modify
classes of inner lines in enhanced changes list
** Puppet patches
*** https://gerrit.wikimedia.org/r/#/c/281940/ -- wikilabels: healthier
uwsgi
*** https://gerrit.wikimedia.org/r/#/c/281228/ -- ores: do git clone in
staging
*** https://gerrit.wikimedia.org/r/#/c/281161/ -- Use die-on-term on
ores uwsgi
*** https://gerrit.wikimedia.org/r/#/c/280403/ -- ores: Scap3 deployment
configurations
* '''Updates''':
** ORES deployed to beta labs via scap3: https://ores-beta.wmflabs.org/
** Substantial updates to ORES service announced:
https://meta.wikimedia.org/wiki/Talk:Objective_Revision_Evaluation_Service#…
*** Scoring UI, API versioning and v2, Swagger documentation, Feature
reporting and injection
** ORES breaking change coming April 7th (tomorrow):
*** Patches submitted to tools that use ORES (huggle*, ra-un,
ScoredRevisions, crosswatch, RTRC)
=== Security ===
* Reviews: Gadgets in progress; next week: Newsletter, DOMPurify,
* Hovercards, UploadLinks, DoubleWiki
* Security release soon (maybe next week)
* Ops: https://phabricator.wikimedia.org/T131195 ?
=== Release Engineering ===
* Blocking: security release soonish
* Blocked:
** Beta Cluster SSL https://phabricator.wikimedia.org/T97593
** Phab/Jenkins firewall things:
https://phabricator.wikimedia.org/T131375
** Jessie HHVM: https://phabricator.wikimedia.org/T125821
* Updates:
** Scap migration timeline announcement (End of Quarter)
=== Technical Operations ===
* '''Blocking''':
none
* '''Blocked''':
none
* '''Updates''':
** On track for CODFW switchover on Tue April 19th
https://wikitech.wikimedia.org/wiki/Codfw_cluster
** some work on scap3 with releng
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
No. Your citations are normal, and expected. The use of [0] is a dev
affectation to show you're 'in the club', that is, to discriminate, but
violates the principal of least surprise.
On 2016-04-06 05:00, wikitech-l-request(a)lists.wikimedia.org wrote:
> I suppose you've figured out that I don't know how to write citations.
> Subtract -1 from N for all [N] in the body. :-) -S.
The Release Engineering team's goal for the April-June 2016 quarter is
to move everything that is currently deployed with Trebuchet over to
Scap. With the release of Scap 3.1.0, everything that is deployed via
Trebuchet can be ported to Scap—it supports git-fat, restarting
services, and there is even a puppet provider.
== What is the timeline? ==
We have made tasks for all of the existing projects that are deployed
via Trebuchet[0], and the goal is to move these all by **2016-06-30**
(AKA the End of The Quarter™).
If we missed your project that is deployed via Trebuchet, please add a
task with the #scap3 tag in phabricator.
== What is Scap? Why are we moving to it? ==
Scap is a tool that the Release Engineering team has been working on
as a successor to the salt-based Trebuchet deployment system.
* Stable and secure SSH-based command and control
* Detailed error logs available from every target node
* Built on tools that everyone is familiar with—SSH and Git
== What does it mean to move to Scap? ==
To assist with the move from Trebuchet to Scap:
* We have written documentation, including a quick start setup guide [1]
* Release Engineering folks are available to help with migrations,
questions, concerns in the #scap3 channel on freenode
== Why isn't Release Engineering just porting everything all by their
lonesome? ==
We're hoping that by the end of the quarter, not only will we get all
projects migrated, but we also want folks to be familiar with Scap and
know how to troubleshoot their own deployments. In the end, the goal
is to scale knowledge of how to use Wikimedia's deployment tooling to
the wider organization instead of a handful of people. "Teach a person
to fish"[2] and all...
<3,
Tyler Cipriani
WMF Release Engingeering
[0] https://phabricator.wikimedia.org/project/view/1824/
[1] https://doc.wikimedia.org/mw-tools-scap/scap3/quickstart/setup.html
[2] https://en.wiktionary.org/wiki/give_a_man_a_fish_and_you_feed_him_for_a_day…
Hi, back from the Hackathon in Jerusalem, where technical collaboration
worked at its best. :)
I have been asking hackathon participants about their opinions on the Code
of Conduct, especially among volunteers that haven't participated in the
draft. The replies could be mainly classified in two groups: "about time --
sorry that I couldn't follow all the discussion" and "right, but is there
really a problem...?".
Since there have been some questions about the types of problems we have in
our technical spaces, I have tried to provide an overview at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Problems_in_the_W…
Please have a look. The fact that Wikimedia technical spaces seem to have
less problems than other corners of the movement doesn't mean that there
are no problems at all. Andre and I deal with reports of different types
basically every month.
For us, the proposal for a Code of Conduct with a process to handle reports
by a community committee represents a better process than the current
ad-hoc approach that the WMF Developer Relations team has to maintain in
response to the complaints we receive.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
The WMF’s technology department has for this quarter the goal of testing
and temporarily switching the main operational data centre from Eqiad
(located in Chicago) to Codfw (located in Dallas)~[1,2]. This includes both
back-end-processing as well as serving live traffic from it.
As a part of this effort, we are scheduling a switch-over for RESTBase and
its back-end services, including: Parsoid, the Mobile Content Service,
CXServer, Mathoid, Citoid, Apertium and Zotero~[3]. Technically, it will
not be a real switch-over per se, because we will keep all of those
services active in both DCs. However, external traffic will be directed to
the Dallas DC only.
=== When is it and what does it mean for me? ===
The switch-over test is planned for this Thursday, 2016-03-17. We have
allotted a three-hour window for this~[4]. There is nothing users should
do before or after the switch; it will be transparent for them. There are
two things users should note, though:
1) At the time of the switch-over, users might receive error responses for
a while (both 4xx and 5xx status codes). While we will test most of the
things ahead of time, we cannot test the actual traffic shifting, so small
bumps might be noticed.
2) After the switch to the Dallas DC, users will likely see their response
latencies slightly elevated. During the test, some requests might
experience a slightly larger latency. This will occur because all of the
services that will be responding to live requests still need to contact the
main MediaWiki cluster, which will remain in Eqiad (the other DC) until a
complete switch-over of the infrastructure is performed. However, given the
multiple levels of caching, the 40 ms of penalty to go cross-DC for an
uncached API request does not seem too taxing.
=== Wait, what about my service X running in WMF production? ===
If you are a service owner of one the aforementioned services, there are no
explicit actions you should take prior to, during or after the switch-over
test. This test could, however, affect your service depending on whether it
usually serves live traffic or is mostly operational during various
internal updates. MediaWiki and JobQueue processing will still be performed
in Eqiad, so in the latter case your service should not see a change in the
usage pattern. If, however, your service is mostly in charge of responding
to live requests coming through RESTBase, those will be handled by
instances in Codfw. However, as these services are full replicas of their
Eqiad counterparts and are stateless, no major breakage will happen.
Should you have any questions or concerns, don’t hesitate to contact us
here or on IRC (#wikimedia-services @ freenode).
Best,
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
[1]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Techn…
[2] https://phabricator.wikimedia.org/project/profile/1723/
[3] https://phabricator.wikimedia.org/T127974
[4]
https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A…
Hello everyone,
Related pages feature has been in beta for over two months now, the future
of the feature depends on our discussions. While we currently don't have a
clear process for deciding collaboratively on an all languages product,
Alsee and the reading team have put together this document on meta [0], as
a request for comment, seeking comments and ideas on modifications
required, and how to further test the feature. In fact, we are not sure if
an rfc is the best strategy to move forward with product decisions, but
lets see how the discussion evolves, and we might explore the need for a
different process, as we move on with this one.
We managed to translate a brief introduction about the topic, please feel
free to fully translate the document and/or further promote the discussion
on your wiki. We are trying hard to avoid having an English centric
discussion for a feature that could be available across all language
projects, and while we don't have a clear solution for this, we are trying
this method as an experiment, where at least our communities can leave
comments in their preferred language if they aren't comfortable writing in
English but they can understand it.
Please check the page, help with translation or promotion in your
Wikipedia, and most importantly, comment on how you think it can evolve. :)
Lets see how this works!
All the best,
M
[0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages
Hello,
The Jenkins slaves had grunt-cli provisioned which is often used by the
npm test command. If you get a Jenkins job to fail with:
sh: 1: grunt: not found
Simply add grunt-cli to your project devDependencies and the next build
have it installed. Example:
https://gerrit.wikimedia.org/r/#/c/275823/1/package.json,cm
The change removing grunt-cli is:
https://gerrit.wikimedia.org/r/#/c/280974/
--
Antoine "hashar" Musso