Re: [Wikitech-l] phan (new static analysis tool) is now voting on MediaWiki core

[Legoktm]

Hi,

On 12/12/2016 10:03 PM, Sam Wilson wrote:
> Is it possible now to add Phan to extensions' CI as well?

That's the next step :). Filed
 for it.

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] phan (new static analysis tool) is now voting on MediaWiki core

[Stas Malyshev]

Hi!

> There's documentation on mediawiki.org[3] about how it is currently
> configured, and how to set it up locally. You'll need PHP 7 with the ast
> extension to actually run phan. If that's not possible for your system,
> you can rely on jenkins to run it for you.

I wonder how hard would it be to add php7/phan to mediawiki-vagrant?

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Discussion Platform

[Stas Malyshev]

Hi!

> Depends on how you define easy.
> http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki/ is a recording of
> everything in #mediawiki by date, oldest at the top, newest at the bottom.
> I would consider that fairly easy.

It's easy if your use case is "reading everything on a particular day".
If your use case is "locating that part where John and Mary talked about
FooBar", it's not easy at all. Raw logs are as usable as... well, raw
logs. People do read raw logs from time to time, but usually they employ
tools to make sense of them - e.g. kibana, etc. Of course, it's a bit
strained analogy, but my point is IRC raw logs are not a very good UI
for many use cases.
Don't have a good solution for this, as IRC is still excellent as
transient quick discussion medium, but much less as a long-term
persistent discussion one. OTOH, maybe that should be done with wiki+Flow?

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Arbitrary Wikidata querying

[Stas Malyshev]

Hi!

> If I wanted to make a page on the English Wikipedia using wikitext called
> "List of United States presidents" that dynamically embeds information
> from  and
>  and other similar items, is this
> currently possible? I consider this to be arbitrary Wikidata querying, but
> if that's not the correct term, please let me know what to call it.

So this is kind of can of worms which we I guess eventually have to
open, but very carefully. So I want to state my _current_ opinion on the
matters - please note, it can change at any time due to changing
circumstances, persuasion, experience, revelation, etc.

1. Technically, anything that can access a web-service and speak JSON,
can talk to SPARQL server. So, in theory, making some way to do this,
*in theory*, would not be very hard. But - please keep reading.

2. I am very apprehensive about having direct link between any wiki
pages and SPARQL server without heavy caching and rate limiting in
between. We don't have super-strong setup there and I'm afraid making
such link would just knock our setup over, especially if people start
putting queries into frequently-used templates.

3. We have number of bot setups (Listeria etc.) which can auto-update
lists from SPARQL periodically. This works reasonably well (excepting
occasional timeout on tricky queries, etc.) and does not require
requesting the info too frequently.

4. If we want more direct page-to-SPARQL-to-page interface, we need to
think about storing/caching data, and not for 5 minutes like it's cached
now but for much longer time, probably in storage other than varnish.
Ideally, that storage would be more of a persistent store than a cache -
i.e. it would always (or nearly always) be available but periodically
updated. Kind of like bots mentioned above but more generic. I don't
have any more design for it beyond that but that's I think the direction
we should be looking into.

> A more advanced form of this Wikidata querying would be dynamically
> generating a list of presidents of the United States by finding every
> Wikidata item where position held includes "President of the United
> States". Is this currently possible on-wiki or via wikitext?

No, and there are tricky parts there. Consider
https://www.wikidata.org/wiki/Q735712. Yes, Lex Luthor held the office
of the President of the USA. In a fictional universe, of course. But the
naive query - every
Wikidata item where position held includes "President of the United
States" - would return Lex Luthor as the president as legitimate as
Abraham Lincoln. In fact, there are 79 US presidents judging by
"position held" alone. So clearly, there need to be some limits. And
those limits would be on case-by-case basis.

> If either of these querying capabilities are possible, how do I do them?
> I don't understand how to query Wikidata in a useful way and I find this
> frustrating. Since 2012, we've been putting a lot of data into Wikidata,
> but I want to programmatically extract some of this data and use it in my
> Wikipedia editing. How do I do this?

Right now the best way is use one of the list-maintaining bots I think.
Unless you're talking about pulling a small set of values, in which case
Lua/templates are probably the best venue.

> If these querying capabilities are not currently possible, when might they
> be? I understand that cache invalidation is difficult and that this will
> need a sensible editing user interface, but I don't care about all of
> that, I just want to be able to query data out of this large data store.

We're working on it (mostly thinking right now, but correct design is
80% of the work, so...). Visualizations already have query capabilities
(mainly because they have strong caching model embedded and because
there are not too many of them and you need to create them so we can
watch the load carefully). Other pages can gain them - probably via some
kind of Lua functionality - as soon as we figure out what's the right
way to do it, hopefully somewhere within the next year (no promise, but
hopefully).

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] phan (new static analysis tool) is now voting on MediaWiki core

[Sam Wilson]

This is brilliant! :-)

Is it possible now to add Phan to extensions' CI as well?


On 13 December 2016 at 10:41, Legoktm  wrote:

> Hi!
>
> Thanks to some awesome work by Erik Bernhardson, phan[1], a new static
> analysis tool, is now voting[2] on MediaWiki core patches.
>
> It's significantly more advanced than any of our other current tools,
> and should help identify some types of errors. It uses PHP 7's AST to
> process code, but is capable of analyzing PHP5 code.
>
> There's documentation on mediawiki.org[3] about how it is currently
> configured, and how to set it up locally. You'll need PHP 7 with the ast
> extension to actually run phan. If that's not possible for your system,
> you can rely on jenkins to run it for you.
>
> [1] https://github.com/etsy/phan
> [2] https://phabricator.wikimedia.org/T132636
> [3] https://www.mediawiki.org/wiki/Continuous_integration/Phan
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
User:SWilson (WMF) 
Community Tech
Fremantle, Western Australia
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] phan (new static analysis tool) is now voting on MediaWiki core

[Legoktm]

Hi!

Thanks to some awesome work by Erik Bernhardson, phan[1], a new static
analysis tool, is now voting[2] on MediaWiki core patches.

It's significantly more advanced than any of our other current tools,
and should help identify some types of errors. It uses PHP 7's AST to
process code, but is capable of analyzing PHP5 code.

There's documentation on mediawiki.org[3] about how it is currently
configured, and how to set it up locally. You'll need PHP 7 with the ast
extension to actually run phan. If that's not possible for your system,
you can rely on jenkins to run it for you.

[1] https://github.com/etsy/phan
[2] https://phabricator.wikimedia.org/T132636
[3] https://www.mediawiki.org/wiki/Continuous_integration/Phan

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Readership metrics for the timespan until December 4, 2016

[Zareen Farooqui]

Hi all,

Please see below for the Readership metrics report for the timespan until
December 4, 2016.


Zareen Farooqui


-- Forwarded message --
From: Zareen Farooqui 
Date: Mon, Dec 12, 2016 at 8:45 PM
Subject: Readership metrics for the timespan until December 4, 2016
To: mobil...@lists.wikimedia.org
Cc: sch...@wikimedia.org, sl...@wikimedia.org,
wikitech-l@lists.wikimedia.org, analyt...@lists.wikimedia.org,
fr-onl...@wikimedia.org


Hi all,

This resumes the usual look
 at our
most important readership metrics. This time we can report that daily
pageviews are up 4.8% (since the last report), with an interesting recent
peak which meant that November’s pageviews surpassed those of November 2015
(coincidentally also) by 4.8%, after October had already seen a 2.1%
year-over-year increase. The iOS Wikipedia app saw increased downloads,
while the Android app’s install base has stopped its previous downward
trend.

As laid out earlier
,
the main purpose is to raise awareness about how these metrics are
developing, call out the impact of any unusual events, and facilitate
thinking about core metrics in general. As always; feedback and discussion
welcome. Week-over-week and month-over-month changes are now being recorded on
the Product page 
at MediaWiki.org. This edition of the report covers a timespan of eighteen
weeks.

Some other recent items of interest, in case they didn’t already catch your
attention:

   -

   The WMF Reading team published its quarterly review presentation
   

   for Q1 2016-17 (July-September), which includes lots of traffic and usage
   data.
   -

   At the Foundation’s August metrics meeting
   
,
   the Reading team gave an update on longer-term traffic trends since 2013.
   (TL;DR: Overall pageviews have been flat to slightly declining, mobile has
   been steadily rising but recently slowed down, desktop has declining during
   these three years. However, total pageviews have been slightly increasing
   year-over-year in the last few months.) See the chart below, updated with
   data until November:

[image: Wikimedia monthly pageviews (desktop+mobile), 2013-2016 (version
December 2016).png]

In particular, as mentioned, the number of total pageview saw
year-over-year increases of +2.1% for October and +4.8% in November, in
contrast to e.g. the -10.5% we had for May 2015-May 2016.

Now to the usual data. (All numbers below are averages for August
1-December 4, 2016 unless otherwise noted.)

Pageviews

Total: 529 million/day (+4.76% from the previous report timeframe, with
corrected numbers for anomalously high traffic on some main pages
)


Context (April 2015-December 2016):



See also the Vital Signs dashboard


(Small caveats: iOS app’s pageviews were undercounted by about 1.6
million/day from mid September to early November due to a bug
.)

Overall pageviews increased steadily during the timespan of this report
aside from the week ending October 30th (right before Halloween) and the
end of November. There appears to be a peak in pageviews in November.

To facilitate our understanding of which traffic movements are seasonal and
which may indicate lasting changes, here is a chart overlaying the total
pageview numbers back to May 2013 (the earliest time for which we have data
according to the current pageview definition):

The blue line indicates a non-seasonal rise peaking around November 12. We
checked whether this peak came from a particular country and were able to
exclude that possibility.

Wikimedia Daily Pageviews from US


Pageviews in US do not show any drastic changes (even around the time of
the US elections).


Wikimedia Daily Pageviews from Mexico


In Mexico, there seems to been a huge drop starting October 27th (perhaps
some sort of local outage).


Wikimedia Daily Pageviews from Ecuador


Ecuador shows a huge spike on October 30th, followed by a drop for several
days.

Desktop: 54.1% ​(previous report: ​54.1%)

Mobile web: 44.8% ​(previous report: 44.6%)

Apps: 1.1% ​(previous report: ​1.3%) (missing some iOS pageviews, cf. above)

Context (December 2015 - December 2016):

Overall mobile percentage is similar to the last report, but we did see a
small increase (besides one week in August) until late September.  As a
reminder, mobile already has a solid majority in terms of unique devices,
cf. below.



Global North ratio: 75.3% of total pageviews (previous report: 

[Wikitech-l] Wikimedia Developer Summit DRAFT program

[Quim Gil]

Hi, the Wikimedia Developer Summit Program committee is happy to announce a
draft schedule:

https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Program#Schedule

This schedule includes two plenary sessions:

* Has our success made it hard to see your own contribution?
 by Ward Cunningham

* Wikimedia Foundation Technology and Product Q, with Victoria Coleman
(CTO) and Wes Moran (VP of Product).

You can propose and vote questions for Victoria and Wes between now and the
beginning of the Summit:

http://www.allourideas.org/wikidev17-product-technology-questions

We welcome feedback about possible improvements to the schedule. Please
share your suggestions at the related discussion page
.
We plan to confirm the final schedule on Friday, December 23rd.

We are working on the Unconference, the third day of the Summit, and the
social events. We will share more details soon. Stay tuned!

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ArchCom Meeting Minutes (2016-12-07)

[Gergo Tisza]

On Mon, Dec 12, 2016 at 11:20 AM, Daniel Kinzler <
daniel.kinz...@wikimedia.de> wrote:

> * Victoria suggest to have a regular meeting to review/prioritize technical
> debt. ArchCom to be invited.
>

Thank you! Systematic focus on that has long been overdue.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery Weekly Update for the week starting 2016-12-05

[Chris Koerner]

This is the weekly update for the week starting 05 December. As always,
feedback and questions are welcome.

==Highlights==
* Load tests for cross-project searching were completed successfully. [0]
We are now testing how many results are produced for typical queries as a
first step towards figuring out how relevant the results are. [1]
* Released tabular and map data namespaces to Commons, after reviewing
implementation, consulting legal, enabling shared geojson data storage, and
adding metrics tracking. [2] [3] [4] [5] [6] [7] [8] [9]

=== Search ===
* We've put together a draft proposal for how to deal with the interaction
of all the possible additional search options—suggestions, quote-stripping,
"wrong keyboard", language ID, etc.—to have a more co-ordinated
conversation about all this. Comments on the talk page there are welcome.
[10]
* Load tests for cross-project searching were completed successfully. [11]
We are now testing how many results are produced for typical queries as a
first step towards figuring out how relevant the results are. [12]
* Upgraded to Java 8 in preparation for upgrading ElasticSearch next
quarter. [13]
* Performed some refactoring to improve interwiki searching. [14]
* Improved handling of characters containing diacritics or accents. [15]
[16]
* Added support for minimum query length to detect the language of the
query. When a minimum length is eventually chosen, this will solve edge
cases where some very short queries and queries consisting just of numbers
could produce unexpected results. [17]
* Fixed an edge case where third-party users of CirrusSearch could get an
exception when building a completion suggester index. [18]

=== Analysis  ===
* Fixed an error with installing R package Boom (& bsts) on stat1002 (but
can on stat1003) [19]

=== Portal ===
* Add node 6 compatibility to Portal build tasks [20]

=== Interactive ===
* Enhance Report Updater to be able to send data to graphite [21]
* Increase user sampling rate [22]
* Investigate ClearTables [23]
* Bug fixed: Closing maps by going back doesn't always work [24]
* Updated and adapted Tabular Data to match published formats [25]
* Updated Legal wording update for tabular and map data release [26]
* Added information on how to change error message [27]
* Updated the logging for Kartotherian from info to warn [28]

== Other Noteworthy Stuff  ==
* Published Wikimedia Discovery's narrative and roadmap for FY 2016/17
(July 2016 - June 2017) [29]

[0] https://phabricator.wikimedia.org/T149740
[1] https://phabricator.wikimedia.org/T151935
[2] https://phabricator.wikimedia.org/T148745
[3] https://www.mediawiki.org/wiki/Help:Tabular_Data
[4] https://www.mediawiki.org/wiki/Help:Map_Data
[5] https://www.mediawiki.org/wiki/Extension:JsonConfig/Tabular
[6] https://phabricator.wikimedia.org/T134426
[7] https://phabricator.wikimedia.org/T152553
[8] https://phabricator.wikimedia.org/T137930
[9] https://phabricator.wikimedia.org/T152661
[10]
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/So_Many_Search_Options
[11] https://phabricator.wikimedia.org/T149740
[12] https://phabricator.wikimedia.org/T151935
[13] https://phabricator.wikimedia.org/T151325
[14] https://phabricator.wikimedia.org/T141033
[15] https://phabricator.wikimedia.org/T137830
[16] https://phabricator.wikimedia.org/T146402
[17] https://phabricator.wikimedia.org/T149318
[18] https://phabricator.wikimedia.org/T150799
[19] https://phabricator.wikimedia.org/T147682:
[20] https://phabricator.wikimedia.org/T150190
[21] https://phabricator.wikimedia.org/T150187
[22] https://phabricator.wikimedia.org/T152174
[23] https://phabricator.wikimedia.org/T141964
[24] https://phabricator.wikimedia.org/T151915
[25] https://phabricator.wikimedia.org/T152184
[26] https://phabricator.wikimedia.org/T152553
[27] https://phabricator.wikimedia.org/T152554
[28] https://phabricator.wikimedia.org/T148116
[29] https://www.mediawiki.org/wiki/File:Discovery_narrative_FY_2016-17.pdf



The full update, and archive of past updates, can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as Easy or Volunteer
needed in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R


Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom Meeting Minutes (2016-12-07)

[Daniel Kinzler]

Hi all!

Please find below minutes of the last ArchCom meeting

The minutes can be fond at
.

See also the ArchCom status page at
 and the RFC board
.


^


People present: Members: Brion, Daniel (chair), Gabriel, Tim. Guest: Victoria
Coleman (CTO)

* Victoria joined to meeting to get an idea of how ArchCom operates

* Victoria will attend ArchCom meetings as much as time allows

* Work on thumbnail API (T66214) is progressing, follow-up meeting to be
announced (Gabriel)

* Web API outage (T151702) is being investigated/evaluated (Gabriel, Tim, Kunal,
and others)

* Code experiments started for using Varnish’s xkey feature in Wikibase
(T152425) (Daniel)

* Victoria suggest to have a regular meeting to review/prioritize technical
debt. ArchCom to be invited.

* Lego’s Deprecation Policy RFC (T146965) to be discussed on December 14.
Fallback: thumb API (T66214).

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom RFC Meeting W51: Deprecation policy for PHP code in MediaWiki (2016-12-14, #wikimedia-office)

[Daniel Kinzler]

Hi all!


At the ArchCom RFC meeting on Wednesday [E412], we will talk about defining an
official deprecation policy [T146965][DP].

I think it would be quite useful to discuss the different modes and methods of
deprecation we have, and what they mean for MediaWiki core, and for extension
developers.

To me, one of the interesting questions is what happens if a deprecated function
is still used in an extension that is not actively maintained. We can provide a
patch - but who can review it? And if nobody reviews it, can we still remove the
deprecated method?



The meeting will be at the usual time (Wednesday 21 UTC, 14 PDT, 23 CET)
and place (#wikimedia-office). For an overview of ArchCom activity, see
[ArchComStatus].


-- Daniel


[E412]: 
[T146965]: 
[DP]: 
[ArchComStatus]: 


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Neil P. Quinn]

Strainu and Pine:

If developers learn they can't trust you to distinguish reasonable
expectations from unreasonable ones (this falls into the "ludicrously
unreasonable" category, by the way), don't be surprised if they ultimately
start to doubt even your legitimate complaints.

There are very important discussions to be had about how software
development works in the Wikimedia movement. This is absolutely not one of
them.

On Mon, Dec 12, 2016 at 1:48 AM, Strainu  wrote:

> 2016-12-12 10:21 GMT+02:00 Quim Gil :
> > Hi, let me check this incident under the light of the Technical
> > Collaboration Guideline
> > 
> (draft
> > under review, feedback welcome in the related discussion pages).
> >
> > https://www.mediawiki.org/wiki/Technical_Collaboration_
> Guideline/Milestone_communication
> > defines when and where are communications expected.
>
> Thank you for the pragmatic approach Quim. I launched 2 discussions
> there, referring to changes that require action from the communities
> [1] and changes affecting large number of pages [2]. Hopefully we can
> find a middle ground on at least some of the subjects.
>
> Strainu
>
> [1] https://www.mediawiki.org/wiki/Topic:Th1vs3h97d96ajaf
> [2] https://www.mediawiki.org/wiki/Topic:Th1wc4pu1qplo4k8
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Neil P. Quinn ,
product analyst
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Strainu]

2016-12-12 10:21 GMT+02:00 Quim Gil :
> Hi, let me check this incident under the light of the Technical
> Collaboration Guideline
>  (draft
> under review, feedback welcome in the related discussion pages).
>
> https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication
> defines when and where are communications expected.

Thank you for the pragmatic approach Quim. I launched 2 discussions
there, referring to changes that require action from the communities
[1] and changes affecting large number of pages [2]. Hopefully we can
find a middle ground on at least some of the subjects.

Strainu

[1] https://www.mediawiki.org/wiki/Topic:Th1vs3h97d96ajaf
[2] https://www.mediawiki.org/wiki/Topic:Th1wc4pu1qplo4k8

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Quim Gil]

Hi, let me check this incident under the light of the Technical
Collaboration Guideline
 (draft
under review, feedback welcome in the related discussion pages).

https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication
defines when and where are communications expected.

The change discussed in this thread is a slight variation of the same
colors, for accessibility reasons that haven't been contested. This is not
a new product or a new feature, and it is not even a major bug. Therefore,
not triggering a community announcement & review for this case was correct.

This doesn't forbid anyone to talk about this change, especially when they
are one of the contributors (and a volunteer developer) happily sharing the
results obtained. Sharing the news with wikitech-ambassadors was correct
too.

https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Community_decisions
defines the steps for communities in case of disagreement.

If a change (no matter how small is perceived by their authors) causes
problems to a community or an individual, they can file specific blockers
explaining the problem. They can do it in the related Phabricator project
 or wiki page
.

So far there haven't been any blockers identified about the change itself,
though? If you have any, please report it in the venues where they can be
addressed effectively. https://phabricator.wikimedia.org/T152025 seems to
be the related task.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l