Forwarding, since the subjects may be of interest to people on the
Wikitech, AI, and Research lists.
I'm unqualified to evaluate Damon's comments and the FB exec's comments
about AI, so please refrain from shooting the messenger if these aren't
helpful or interesting to those of you who do know enough about AI to make
well-educated assessments.
Regards,
Pine
---------- Forwarded message ----------
From: "Damon Sicore" <damon(a)sicore.com>
Date: Aug 18, 2016 21:35
Subject: [Wikimedia-l] Facebook CTO on strategy, Internet access, Wikipedia
To: "Wikimedia Mailing List" <wikimedia-l(a)lists.wikimedia.org>
Cc:
Hi,
I usually don't recommend these things, but this interview with Schrep [1]
[2] is interesting and insightful. I recommend listening to it instead of
reading. He discusses FB's ten year plan, AI, VR, Internet access for
all, mentions Wikipedia several times, confirms their insatiable hunger for
structured data, and reveals several details on their innovation approach.
Trigger Warning: Corporate Speak
Make no mistake, I've nothing but contempt and spite for Facebook, but
having worked with Mike I also know he demonstrates formidable intellect
and is a decent person. He's incredibly capable in building amazing teams
and predicting (more like sniffing out) the future of tech. I watch his
moves closely to stay sharp.
He's right about how papers are coming out constantly which augment current
AI tech in interesting new ways. I believe we're living in interesting
times for computer science and mathematics--computational linguistics and
probabilistic search in particular. A person can't read the CS and math
papers fast enough in order to keep up with the innovation. A lot of it is
trivial, sure, but some is quite startling in impact as they combine a few
smaller things which seemed previously innocuous yet when used together
they solve key problems.
When looking into tech and strategy for WMF and the engineers it supports,
I'd be very interested in the direction Facebook is going and the
technologies they plan on investing in, so passing it along.
Yours faithfully,
Damon
[1] http://www.metisstrategy.com/interview/mike-schroepfer/
[2] https://en.wikipedia.org/wiki/Mike_Schroepfer
Damon Sicore
512 963 5126
https://damon.sicore.com
6E98 FBFB
D192 D325
B85D D4FF
FD2A 20ED
DC1D 3975
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Hi all,
I've been working on a new structure test that ensures interface messages,
exported as part of a ResourceLoader module, actually exist.
This avoids broken interface messages from showing up in the interface
undetected, and catches left-over references to messages that were removed.
Commit: https://gerrit.wikimedia.org/r/#/c/277457/
Task: https://phabricator.wikimedia.org/T129976
Thanks to everyone who's helped over the past 5 months to make this test
passing in core and various extensions. Now that the test landed, we can
finally prevent new issues instead of chasing them after the fact in error
logs.
Best,
-- Krinkle
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-08-17
= 2016-08-17 =
== Product ==
=== Reading ===
==== Reading Web ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2126/
* Next sprint: https://phabricator.wikimedia.org/project/view/2158/
* Lazy loading images on mobile web is going live very soon
* Heads up, we're looking to release Related Articles on mobile web
potentially in 6-10 weeks. More api.php calls.
* Any ideas on "Various browser tests failing due to login error" (
https://phabricator.wikimedia.org/T142600 )?
==== Mobile Content Service (MCS) ====
Not stripping title attributes from links anymore.
https://gerrit.wikimedia.org/r/#/c/304785/
==== Android native app ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2142/
* Next sprint:
* Beta release this week with minor feed updates (tab icon update, access
to tabs from the feed, persistent dismissal of cards)
* Nav overhaul work continues apace
* Working with Discovery to get Nearby search going
==== iOS native app ====
* 5.0.6 shipped this week:
https://phabricator.wikimedia.org/tag/ios-app-v5.0.6-hotfix/
* Current release board:
https://phabricator.wikimedia.org/project/board/1736/
** Major features are iPad and Find in Page
** Feature Complete and in beta
** Still wrapping up minor tweaks and bug fixes
* Next release board: https://phabricator.wikimedia.org/project/view/2150/
** Started development this week week
** Adding iOS 10 support
** Dropping iOS 8 support
** Major features are Widgets and Feed improvements
** Expected to go to beta in early september
==== Reading Infrastructure ====
*
=== Security ===
* MediaWiki 1.27.1 release delayed to this week
* Security reviews this week: Html5Depurate, GlobalGroupPermisions,
PerformanceInspector
* Planning for captcha improvements continues
** https://phabricator.wikimedia.org/T125132
** https://phabricator.wikimedia.org/T141490
** First step will be re-generating images using current script
=== Editing ===
=== Collaboration ===
* Blocked:
* Blocking:
* Updates:
=== Language ===
* Blocked:
* Blocking:
* Updates:
** Security review for Youdao needed:
https://phabricator.wikimedia.org/T143185
** Apertium->Jessie packaging work almost done; Few packages left to upload.
** Improvements in Content Translation continue: MT card, templates, DB
errors.
=== Multimedia ===
* Blocked:
** Is there an update on thumbor production status? (Performance?) It's
still blocking ImageTweaks deployment.
* Blocking:
** None of which we're aware.
* Updates:
** Continuing our work on FileAnnotations; currently pending on a decision
on whether we're waiting for structured data or will go early and re-write
content after the fact when it goes live.
=== Parsing ===
* Blocked:
* Blocking:
* Updates:
=== VisualEditor ===
* Blocked:
** We (and other teams depending on Phlogiston) remain blocked with
Ops/Labs on server issues, with the system either completely broken or
impaired continuously since mid-June; this week it's T142742, before that
T141796, T142165, T137736 and others from related issues. Is there a better
mechanism for getting these kinds of issues fixed more rapdily?
* Blocking:
** Parsing team are still waiting for our response on "native" Parsoid
<gallery> implementation. Thalia and Ed will look at it more.
* Updates:
** Major work this week on client-side DOM diffing (for smaller save
bandwidth demands), re-orderable transactions (for enhanced IME support and
maybe offline editing), and the new wikitext editor (now merged in a
feature-flagged state; Beta Feature expected in a month or so).
== Technology ==
=== Release engineering ===
* '''Blocked'''
** ops - need a set of eyes on https://gerrit.wikimedia.org/r/#/c/302601/ so
we can easily put logs for Java-based applications into Logstash
* '''Blocking'''
** Security - security release of 1.27.1 & co. This week.
* Updates:
** New SWAT window schedule starting Aug 22nd
*** See: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_August_22nd
*** And: https://wikitech.wikimedia.org/wiki/SWAT_deploys#The_team
*** https://phabricator.wikimedia.org/T137970
=== Analytics ===
* loading of new AQS (pageview API) cluster ongoing, will switch over to it
when done
* new event bus logging from mw hooks merged, will start being available on
event bus soon
* re-ran massive sqoop of all mediawiki databases, parallelizing most of
the small wikis together, and dbstore1002 doesn't seem impacted
* re-worked some dataset documentation to help people transition from the
old pagecounts-raw: https://wikitech.wikimedia.org/wiki/Analytics/Data
* Joseph and Luca are on vacation for two and one week respectively
=== Services ===
* Blockers: none
* Kafka upgraded to 0.9, now working on replacing the driver in Change-Prop
* Parsoid move to scap3 is in progress
* Puppetisation of the PDF render electron service
=== Research ===
* Substantial update to ORES is live
** CPU usage down by 66%
** Memory usage down by 26%
** Some minor regressions that will be handled in incoming patches.
=== Community Tech ===
* Updating affected abuse filters as the wikis receive the new code for
norm and ccnorm function https://phabricator.wikimedia.org/T29987
* Working on acceptance tests for InternetArchiveBot (
https://phabricator.wikimedia.org/T140386) and releasing some code as a
composer package (https://phabricator.wikimedia.org/T140135)
* Migrations to centralauth database for cross-wiki watchlist
https://phabricator.wikimedia.org/T141951
** Semi-blocker: update on when the watchlist IDs will be added by the TCB
team
* Testing numeric sorting on Swedish Wikipedia
https://phabricator.wikimedia.org/T142113
* Helping out with Education Program’s Dashboard tool
* Nearing completion of feature releases for CopyPatrol
=== Discovery ===
* No blockers
* Working on BM25 implementation
* Working on multi-wiki indexes
* Working on integrating Polestar (http://vega.github.io/polestar/) and
WDQS GUI to allow create graphs visually from WDQS results
* Improved suggestions with typos in first characters:
https://phabricator.wikimedia.org/T107006
* Analysis of ASCII folding/stemming on enwiki:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Re-Ordering_Stemming…
** TLDR: results positive, we should do it
* Summary of Portal changes published:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-August/086312.html
=== Interactive Team ===
* Working on deploying <mapframe> and <maplink> to all non-Wikipedia sites
* Working on replacing GeoHack with <maplink> + info screen on all
Wikipedias
* Working on deploying Tabular data on Commons. Already synced up with
Wikidata.
* In progress of deploying eqiad maps cluster
=== Technical Operations ===
* '''Blocked'''
** None
* '''Blocking'''
** None
* Updates:
** apertium packages for LE reviews ongoing
** thumbor service getting installed this week, no definite ETA yet, but
ongoing
** Work ongoing on puppetDB, xkey, varnish4
== Wikidata ==
* Blockers: None.
* Implemented user feedback on ArticlePlaceholder.
* Series of small fixes to make error messages in the UI more actionable.
* Need Ops input on https://phabricator.wikimedia.org/T142944. Performance
and caching considerations when we make ArticlePlaceholder pages visible to
search engines.
* Today: ArchCom meeting about proposals for content model storage. First
step towards allowing multiple content objects.
https://phabricator.wikimedia.org/E261
== Fundraising Tech ==
* More queue work
* Running CiviCRM batch de-duplication, fixing issues as they arise
== Architecture ==
https://www.mediawiki.org/wiki/Architecture_committee/Status
2016W33: 2016-08-17 (Wednesday)
* ArchCom Planning meeting: [https://phabricator.wikimedia.org/E260 Phab:E260]
20 UTC (1pm PDT)
** Notes: [https://www.mediawiki.org/wiki/Architecture_committee/2016-08-17
Architecture
committee/2016-08-17]
* ArchCom-RFC office hour: [https://phabricator.wikimedia.org/E261 Phab:E261]
21 UTC (2pm PDT)
** Agenda: [https://phabricator.wikimedia.org/T105652 Revisiting T105652
(content model storage)]
Hello!
Almost two months ago we announced [1] that effectively from June 29 Gitblit
will be turned off and the new repo browser will be Phabricator's Diffusion
where the majority of original links will be redirected to.
As the current Github search [2] shows at the moment, there is still over
five hundreds of references to Gitblit in our codebase.
Some don't require attention as they are parts of historical logs, however,
most majority of them should be sooner or later turned to link to Diffusion
instead.
At the moment, the biggest issue are links which were not (able to be)
redirected, thus now point to non-existent location, which in some cases
causes even problems with upgrades and development. Two typical cases of
such links are:
* clone links in the form of https://git.wikimedia.org/git/... (cf. T139206
- Clones from git.wikimedia.org are not redirected [3])
* links which have the repo name does not contain the trailing .git (cf. T
139027 - Gitblit links not redirecting to the correct moved resource unless
.git is part of repo name in url [4])
Other Gitblit links which are now functional via redirect of course do not *
have to* be replaced with the new Diffusion ones, but it would be obviously
good to have everything pointing directly to the Diffusion.
While we have tried our best effort to do these fixes ourselves (big kudos
to @Paladox for that!) it turned out to be impossible to complete it in
reasonable time without having others to jump in.
So I would like to appeal on project & product managers and repo owners to
find couple minutes of their time to grep their code and ensure all links in
their projects are working and preferably directly to Diffusion.
Please mark relevant commits with T139089 (Fix references to git.wikimedia.
org in all repos) [5] which is tracking all relevant changes.
If you have any link that is not working and you are not able to find the
desired relevant Diffusion target, or if you'll need any other assistence,
please leave a message in the tracking task mentioned above and we will try
to help you.
Thank you for your cooperation.
Kind regards
Danny B.
[1] https://lists.wikimedia.org/pipermail/wikitech-l/2016-June/085935.html
[2] https://github.com/search?p=2&q=org%3Awikimedia+%22git.wikimedia.org%22&
type=Code
[3] https://phabricator.wikimedia.org/T139206
[4] https://phabricator.wikimedia.org/T139027
[5] https://phabricator.wikimedia.org/T139089
(Feel free to crosspost to further relevant lists...)
Hello.
https://phabricator.wikimedia.org/tag/mediawiki-extensions-vectorbeta/
contains 21 open tasks of which
* 13 are not tagged with any other open project
* 3 are not tagged by anything but yellow tags (= no projects, teams, goals,
releases...)
* 1 is tagged Wikimedia-General-or-Unknown
https://phabricator.wikimedia.org/tag/compact-personal-bar-beta/ contains 21
open tasks of which
* 11 are not tagged with any other open project
* 3 are not tagged by anything but yellow tags (= no projects, teams, goals,
releases...)
* 1 is tagged Wikimedia-General-or-Unknown
(17 of these tasks are tagged with both of these archived projects, so the
real total of tasks in both projects is 25.)
Because I don't know details about these two projects and their archiving, I
would like to ask whoever relevant to perform some cleanup, which means one
or both of following actions:
* tag the task with any open project (except for generic "Wikimedia-General-
or-Unknown" or "MediaWiki-General-or-Unknown: or such), team, goal or
release
* close the task with appropriate resolution
Thank you for helping to keep Phabricator swept.
Kind regards
Danny B.
Hi Chad,
I was not logging in using my email address. I was using my username "vtingey" which is the same on the wikitech site. I tried again now and my username works and I was able to login to Gerrit. Unsure why it works now as I was using the same login (saved in my lastpass). Thanks for the quick help!
Thank you,
Vince Tingey
IT Systems Manager
Michael Smith Laboratories
The University of British Columbia
301 – 2185 East Mall | Vancouver, BC Canada V6T 1Z4
Phone 604 822 8895 | Fax 604 822 2114
vtingey(a)msl.ubc.ca | @ubcmsl
www.msl.ubc.cawww.chibi.ubc.ca
Message: 6
Date: Tue, 16 Aug 2016 18:52:15 +0000
From: Chad <innocentkiller(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Gerrit Access Problem
Message-ID:
<CADn73rNGBhv7Po-CHYR1xUmSX6Fx4eTXEesc0NHb9DUyaodpQQ(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
>From looking at the error logs, it appears you're trying to login with your
e-mail
address. You need to login with your username, which is "Vtingey"
Hope this helps!
-Chad
On Tue, Aug 16, 2016 at 10:37 AM Tingey, Vince <vtingey(a)msl.ubc.ca> wrote:
> Hello Wikitech People,
>
> I apologize in advance if this is the wrong place to put this request but
> I'm
> trying to get access to Gerrit so I can submit a patch to the BiblioPlus
> extension. This is would be my first contribution to Mediawiki.
> https://www.mediawiki.org/wiki/Extension:BiblioPlus
>
> Following through documentation instructions I have created an account on
> Wikitech:
> https://wikitech.wikimedia.org/wiki/User:Vtingey
>
> According to the documentation as long as I have that account I should have
> access to the Gerrit system through LDAP. I tried using my Wikitech
> account to
> log in but I keep getting a "Invalid username or password." error. Any
> ideas?
> https://gerrit.wikimedia.org/r/login/
>
> Thank you,
> Vince Tingey
> IT Systems Manager
> Michael Smith Laboratories
> The University of British Columbia
> 301 - 2185 East Mall | Vancouver, BC Canada V6T 1Z4
> Phone 604 822 8895 | Fax 604 822 2114
> vtingey(a)msl.ubc.ca <mailto:vtingey@msl.ubc.ca> | @ubcmsl
> www.msl.ubc.ca
> www.chibi.ubc.ca
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello Wikitech People,
I apologize in advance if this is the wrong place to put this request but I'm
trying to get access to Gerrit so I can submit a patch to the BiblioPlus
extension. This is would be my first contribution to Mediawiki.
https://www.mediawiki.org/wiki/Extension:BiblioPlus
Following through documentation instructions I have created an account on
Wikitech:
https://wikitech.wikimedia.org/wiki/User:Vtingey
According to the documentation as long as I have that account I should have
access to the Gerrit system through LDAP. I tried using my Wikitech account to
log in but I keep getting a "Invalid username or password." error. Any ideas?
https://gerrit.wikimedia.org/r/login/
Thank you,
Vince Tingey
IT Systems Manager
Michael Smith Laboratories
The University of British Columbia
301 - 2185 East Mall | Vancouver, BC Canada V6T 1Z4
Phone 604 822 8895 | Fax 604 822 2114
vtingey(a)msl.ubc.ca <mailto:vtingey@msl.ubc.ca> | @ubcmsl
www.msl.ubc.cawww.chibi.ubc.ca
Hi everyone,
For this week's office hour, we'll be revisiting the 2015 proposal to
change content model storage[1] (see also T105652). The RFC describes
the problems it is solving:
> * The content model and format of a revision is stored as NULL if it
> is the default. This makes changing the default problematic[...]
> * content model and content format are stored as strings
> ("wikitext" and "text/x-wiki" respectively) which is inefficient from
> a storage point of view
It then describes some schema changes which hopefully address the problems.
The idea was approved, but was never implemented. Daniel is now
interested in moving this forward to unblock Multi-Content
Revisions[2] (which relies on this).
The discussion is scheduled for 2016-08-17 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E261][3]
Rob
p.s. ArchCom status updates continue on [ArchCom/Status][4]
[1]: <https://www.mediawiki.org/wiki/Requests_for_comment/Content_model_storage>
[2]: <https://phabricator.wikimedia.org/T107595>
[3]: <https://phabricator.wikimedia.org/E261>
[4]: <https://www.mediawiki.org/wiki/Architecture_committee/Status>
