We are getting ready to release MediaWiki 1.30 - probably tomorrow. If you have found any bugs while testing Release Candidate 0, please report them now.
Thanks!
Cindy
______________________________
Cindy Cicalese
Product Manager, MediaWiki Platform
Wikimedia Foundation
> Begin forwarded message:
>
> From: Cindy Cicalese <ccicalese(a)wikimedia.org>
> Subject: Availability of MediaWiki 1.30 Release Candidate 0
> Date: November 28, 2017 at 10:23:53 PM EST
> To: mediawiki-announce(a)lists.wikimedia.org
>
> I would like to announce the immediate availability of MediaWiki 1.30.0-rc.0, the first release candidate for 1.30.x. Links are at the end of this e-mail.
>
> This is not a final release and should not be used for production websites.
>
> As always, please do try out the release candidate in a test environment. It's how we find bugs that didn't surface in initial development.
>
> Barring any unforeseen issues, we hope to move forward to the release of MediaWiki 1.30 in the next few weeks.
>
> Per the version lifecycle, the current MediaWiki LTS version is 1.27.4. The 1.27 LTS branch will continue to be supported through June 2019. The 1.29 branch is not an LTS branch, but it will continue to be supported until July 2018. The current version in that branch is 1.29.2. MediaWiki 1.28.x reached End of Life this month. The final release in this series was 1.28.3.
>
> Full release notes: https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_30/RELEASE-N…
>
> **********************************************************************
> Download: https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0-rc.0.tar.gz
> GPG signature: https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0-rc.0.tar.gz.… (signed by Chad Horohoe)
>
> Core only, no extensions: https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0-rc.0.ta…
> GPG signature: https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0-rc.0.ta… (signed by Chad Horohoe)
>
> Public keys: https://www.mediawiki.org/keys/keys.html
> ______________________________
> Cindy Cicalese
> Product Manager, MediaWiki Platform
> Wikimedia Foundation
Following your message Jeroen, there it also is on Wikitech-l now.
-------- Message transféré --------
Sujet : Re: [Wikidata] Imperative programming in Lua, do we really want
it?
Date : Wed, 6 Dec 2017 23:53:17 +0100
De : Jeroen De Dauw <jeroendedauw(a)gmail.com>
Répondre à : Discussion list for the Wikidata project.
<wikidata(a)lists.wikimedia.org>
Pour : Discussion list for the Wikidata project.
<wikidata(a)lists.wikimedia.org>
Hey,
While I am not up to speed with the Lua surrounding Wikidata or
MediaWiki, I support the call for avoiding overly imperative code where
possible.
Most Lua code I have seen in the past (which has nothing to do with
MediaWiki) was very imperative, procedural and statefull. Those are
things you want to avoid if you want your code to be maintainable, easy
to understand and testable. Since Lua supports OO and functional styles,
the language is not an excuse for throwing well establishes software
development practices out of the window.
If the code is currently procedural, I would recommend establishing that
new code should not be procedural and have automawted tests unless there
is very good reason to make an exception. If some of this code is
written by people not familiar with software development, it is also
important to create good examples for them and provide guidance so they
do not unknowingly copy and adopt poor practices/styles.
John, perhaps you can link the code that caused you to start this thread
so that there is something more concrete to discuss?
(This is just my personal opinion, not some official statement from
Wikimedia Deutschland)
PS: I just noticed this is the Wikidata mailing list and not the
Wikidata-tech one :(
Cheers
--
Jeroen De Dauw | https://entropywins.wtf |https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3
On 6 December 2017 at 23:31, John Erling Blad <jeblad(a)gmail.com
<mailto:jeblad@gmail.com>> wrote:
With the current Lua environment we have ended up with an imperative
programming style in the modules. That invites to statefull objects,
which does not create easilly testable libraries.
Do we have some ideas on how to avoid this, or is it simply the way
things are in Lua? I would really like functional programming with
chainable calls, but other might want something different?
John
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata
<https://lists.wikimedia.org/mailman/listinfo/wikidata>
Hi all!
I'm working on the database schema for Multi-Content-Revisions (MCR)
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema> and I'd
like to get rid of the rev_sha1 field:
Maintaining revision hashes (the rev_sha1 field) is expensive, and becomes more
expensive with MCR. With multiple content objects per revision, we need to track
the hash for each slot, and then re-calculate the sha1 for each revision.
That's expensive especially in terms of bytes-per-database-row, which impacts
query performance.
So, what do we need the rev_sha1 field for? As far as I know, nothing in core
uses it, and I'm not aware of any extension using it either. It seems to be used
primarily in offline analysis for detecting (manual) reverts by looking for
revisions with the same hash.
Is that reason enough for dragging all the hashes around the database with every
revision update? Or can we just compute the hashes on the fly for the offline
analysis? Computing hashes is slow since the content needs to be loaded first,
but it would only have to be done for pairs of revisions of the same page with
the same size, which should be a pretty good optimization.
Also, I believe Roan is currently looking for a better mechanism for tracking
all kinds of reverts directly.
So, can we drop rev_sha1?
--
Daniel Kinzler
Principal Platform Engineer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-12-06?veaction=edit&sec…
= *2017-12-06* =
== Callouts ==
* Operations blocked on https://phabricator.wikimedia.org/
<https://phabricator.wikimedia.org/T172025>T172025
<https://phabricator.wikimedia.org/T172025> (Flow)
* Operations DBAs s8 master switchover programmed for 9th January
* Reminder! This is your last few weeks of deployments for the
year/quarter! No non-emergency deploys starts the week of December 18th.
** MediaWiki 1.30 is about to be released in the next few days, so last
call for any blockers, phabricator tag is *#mw-1.30-release
* Wikidata welcomes secondary review from somebody with knowledge about the
recent "section editing" change: https://phabricator.wikimedia.org/T181807
* Have a look at newly initiated
https://www.mediawiki.org/wiki/Manual:Coding_conventions/SVG. Feedback
welcome!
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
** Releasing 5.7.2 (high priority fix for
https://phabricator.wikimedia.org/T69015 ) (
https://phabricator.wikimedia.org/tag/ios-app-v5.7.2/ )
** Continuing work on 5.7.3 (Faster article loading, other minor
enhancements) for release before the end of the year (
https://phabricator.wikimedia.org/project/view/2913/ )
** Continuing work on 5.8 (Reading Lists) for release next year (
https://phabricator.wikimedia.org/project/view/3131/ )
==== Android native app ====
* Blocked by:
* Blocking:
* Updates: Releasing beta 2.6.207
==== Reading Web ====
* Blocked by:
* Blocking:
* Updates:
==== Reading Infrastructure ====
* Blocked by:
* Blocking:
* Updates:
** ReadingLists performance improvements
** Wrapping up media + summary endpoints
** References needs a bit more design work
==== Multimedia ====
* Blocked by: N/A
* Blocking: N/A
* Updates: 3D nearly ready to go, probably before holidays, else shortly
thereafter. Also working on prototyping for first feature of Structured
Data on Commons.
==== Discovery ====
* Blocked by:
* Blocking:
* Updates:
===== Maps =====
* Blocked by: N/A
* Blocking: N/A
* Updates:
** Maps mediawiki integration (Kartographer) improvements #1 on community
wishlist:
https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Tracking
** Redeploying Kartotherian
** Tracking down conflicting versions + NPM
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates:
=== Contributors ===
==== Editing ====
* Blocked by:
* Blocking:
* Updates:
==== Parsing ====
* Blocked by: Services (because of Cassandra3 migration) on deployment of
HTML version bump (for section, figure-inline, html5-id, interwiki-link
changes). This is just an FYI since Services & us have already synced up
about this.
* Blocking: Reading Infra on section tag markup
* Updates:
** itwiki, dewiki, and 170 small wikis got switched from Tidy to RemexHtml
yesterday - itwiki have flagged a bunch of new issues that hadn't been
caught by linting so far. Investigation ongoing and might introduce one or
two newer categories to aid editors -- we expect these categories to be
sparsely populated
** Templatedata related fixes being deployed today -- For pre-existing
transclusions, this will prevent Parsoid from normalizing parameter order
to templatedata format
==== Global Collaboration ====
* Blocked by: MW core (or Parsing?) for code review on
https://gerrit.wikimedia.org/r/#/c/392990/ and surrounding stack of commits
* Blocking: ops for Flow dumps
* Updates:
** New tags for https://phabricator.wikimedia.org/
<https://phabricator.wikimedia.org/T167656>T167656
<https://phabricator.wikimedia.org/T167656> are on this week's train
==== UI Standardization ====
** No OOUI release this and upcoming weeks
* Ongoing:
** OOUI & based products:
*** icons: Work on icon set to be more harmonious and align to WikimediaUI
Style Guide https://phabricator.wikimedia.org/T177432 finishing up
** Unify SVG markup across Foundation products
https://phabricator.wikimedia.org/T178867
** Continuous work and per-project SVGO based optimizations, also initiated
https://www.mediawiki.org/wiki/Manual:Coding_conventions/SVG
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** The prometheus druid exporter (to report druid metrics to graphana via
prometheus) got some attention and others (outside WMF) will be using it
** First productionized version of EventLogging backend on hadoop launched
this week. This means SQL-friendly tables on hadoop with eventlogging data,
and for the first time, ability to join to all mediawiki databases in one
query
** Wikistats 2 APIs (like Pageview API, but for edit data), alpha launch:
https://wikitech.wikimedia.org/wiki/Analytics/AQS/Wikistats
** Wikistats 2 UI, alpha launch: https://stats.wikimedia.org/v2/
** Decommissioning old DB hosts for EventLogging done, remember that
eventlogging DB is now only on analytics-slave, not on analytics-store
anymore
** Work on kafka jumbo cluster
** Rebooting one druid host for maintenance brought up unexpected issues
with druid and zookeeper, working on that
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
** Annual Toolforge survey closed. 141 responses received (11% response
rate).
** Team in Austin this week doing an offsite + attending KubeCon conference
** Will upgrade labpuppetmaster* to v4 puppet packages after the offsite
*** Presuming everything in eqiad goes well next week
=== Fundraising Tech ===
* Blocked by: None
* Blocking: None
* Updates:
** New CiviCRM Import tool for Major Gifts
** Paying down some tech debt in Central Notice
** Fixes for fundraising vagrant role
** Continued improvements to Fundraising Dashboard
** Continuing to support FR-non-tech during the fundraiser
=== MediaWiki Platform ===
* Blocked by: N/A
* Blocking: Global Collaboration for code review on
https://gerrit.wikimedia.org/r/#/c/392990/ and surrounding stack of commits
* Updates:
** MediaWiki 1.30 Release Candidate 0 released
** MCR and Actor table reviews ongoing
** Comment table: Tried to enable WRITE_BOTH mode on testwikis, but had to
revert because it broke CentralAuth and ForeignDBViaLBRepo.
*** Will likely wait until the schema change is done everywhere before we
move anything to WRITE_BOTH.
** TemplateStyles: ParserOutput stateless transforms got merged. Some
Wikibase issues that are being dealt with.
** Firejail: will be deployed for Score
** New PSR-4 autoloader patchset https://gerrit.wikimedia.org/r/373626 ready
for review
** PoolCounter for ORES client https://gerrit.wikimedia.org/r/
<https://gerrit.wikimedia.org/r/394407>394407
<https://gerrit.wikimedia.org/r/394407> ready for testing
** MP3 transcoding deployment
** Discussions with third party MediaWiki developers regarding extension
deployment/dependency management (composer)
=== Performance ===
* Blocked by: N/A
* Blocking: N/A
* Updates:
** Significant new performance testing documentation in progress (aimed at
developers), expected to be delivered before end of 2017
** New varnish slow log configuration in final testing
** perf testing of cross-data center database writes
** Q3 Goals planning: if you think you might need anything from the perf
team, hit me up.
** docker-based MW dev environment (in collab with WMDE)
=== Release Engineering ===
* Blocking:
** Scoring platform, https://phabricator.wikimedia.org/
<https://phabricator.wikimedia.org/T181661>T181661
<https://phabricator.wikimedia.org/T181661>
*** New scap release planned for this week that will hopefully address this
issue.
* Blocked by:
** none
* Updates:
** [MW Train] Reminder! This is your last few weeks of deployments for the
year/quarter! No non-emergency deploys starts the week of December 18th.
*** *#mw-1.30-release *MediaWiki 1.30 is about to be released in the next
few days, so last call for any blockers people might have...you
know...forgotten *
=== Research ===
* Blocked by:
* Blocking:
* Updates:
=== Scoring Platform ===
* Blocked by:
** Parallel scap SSH issue https://phabricator.wikimedia.org/T181661
* Blocking:
* Updates:
** Outage on Nov 28, incident report is going out today.
** SimpleWiki deployed to ORES
*** FYI: Global Collab, please announce and update RC Filters. The
extension is only configured on the beta cluster.
** testwiki (RevIdScorer) includes thresholds now, which makes extension
development easier, against the real server or in either of our vagrant
roles.
** ORES Ext. Refactoring
** Incoming basic support of Icelandic (No RC Filters yet)
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
* Working on improvements to LTR training
* Reindexed wikis to enable improved katakana/hiragana mapping
https://phabricator.wikimedia.org/T179945
* Improving completion suggester interaction with namespaced prefix search
https://phabricator.wikimedia.org/T178474
* Wikidata descriptions indexed, working on fulltext search
* Working on porting Selenium tests from Ruby to JS
* Logstash upgrade to ElasticSearch 5.5 on Thu, completing the 5.5 upgrade
=== Security ===
* Blocked by:
* Blocking:
* Updates:
** Lots of development on Phan security plugin by Bawolff
** Maintanenace work on security alert configuration (Github, NSP)
** Reviews:
*** Ex:WikipediaExtracts
*** Next set of security reviews will be scheduled this week
=== Services ===
* Blocked by: none
* Blocking: Parsing till early next week
* Updates:
** Round of Cassandra 3 bootstraps is complete
** htmlCacheUpdate for wiktionaries are on kafka queue
=== Technical Operations ===
* Blocked by:
** Global Collaboration on Flow dumps https://phabricator.wikimedia.org/
<https://phabricator.wikimedia.org/T172025>T172025
<https://phabricator.wikimedia.org/T172025>
* Blocking:
** None
* Updates:
** Q3 goal planning started, if teams have dependencies on Ops for next
quarter, reach out
** Part of DC ops in Singapore for eqsin (new caching DC's name) rollout
** s8 (wikidata) work ongoing, work ontrack.
** Operations DBAs s8 master switchover programmed for 9th January
== Wikidata ==
* Finally got rid of the manual "Wikidata" build process, Wikidata is part
of the weekly deployment now: https://phabricator.wikimedia.org/T173818
* Introduced a custom, "compact" entity diff serialization in the
wb_changes table. Please look out for side-effects:
https://phabricator.wikimedia.org/T113468
* First patches demo the possibility to persist statements on sub-entities
utilizing Wikibase's standard wbsetclaim API (namely Forms on Lexemes):
https://phabricator.wikimedia.org/T163724
* Core changed the way it handles section editing. Wikibase hooks into this
feature, and now behaves unexpected. Review welcome:
https://phabricator.wikimedia.org/T181807
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
Hello!
Our logstash servers are the last servers to upgrade to elasticsearch
5.5.2. I'm planning to do this upgrade on Thursday December 7, between
9:00 and 10:00 UTC (10:00 to 11:00 CET, 01:00 to 02:00 PST).
Testing on labs went well, so I'm not expecting any issue. Now that
all servers are behind LVS, we should not even loose a single message.
That being said, there is a risk. If you see disapearing log messages
during that period, please let me know!
Have fun!
Guillaume
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation
UTC+2 / CEST
Handling of usernames in imported edits in MediaWiki has long been weird
(T9240[1] was filed in 2006!).
If the local user doesn't exist, we get a strange row in the revision table
where rev_user_text refers to a valid name while rev_user is 0 which
typically indicates an IP edit. Someone can later create the name, but
rev_user remains 0, so depending on which field a tool looks at the
revision may or may not be considered to actually belong to the
newly-created user.
If the local user does exist when the import is done, the edit is
attributed to that user regardless of whether it's actually the same user.
See T179246[2] for an example where imported edits got attributed to the
wrong account in pre-SUL times.
In Gerrit change 386625[3] I propose to change that.
- If revisions are imported using the "Upload XML data" method, it will
be required to fill in a new field to indicate the source of the edits,
which is intended to be interpreted as an interwiki prefix.
- If revisions are imported using the."Import from another wiki" method,
the specified source wiki will be used as the source.
- During the import, any usernames that don't exist locally (and can't
be auto-created via CentralAuth[4]) will be imported as an
otherwise-invalid name, e.g. an edit by User:Example from source 'en' would
be imported as "en>Example".[5]
- There will be a checkbox on Special:Import to specify whether the same
should be done for usernames that do exist locally (or can be created) or
whether those edits should be attributed to the existing/autocreated local
user.
- On history pages, log pages, and the like, these usernames will be
displayed as interwiki links, much as might be generated by wikitext like "
[[:en:User:Example|en>Example]]". No parenthesized 'tool' links (talk,
block, and so on) will be generated for these rows.
- On WMF wikis, we'll run a maintenance script to clean up the existing
rows with valid usernames and rev_user = 0. The current plan there is to
attribute these edits to existing SUL users where possible and to prefix
them with a generic prefix otherwise, but we could as easily prefix them
all.
- Unfortunately it's impossible to retroactively determine the actual
source of old imports automatically or to automatically do anything about
imports that were misattributed to a different local user in
pre-SUL times
(e.g. T179246[2]).
- The same will be done for CentralAuth's global suppression blocks.
In this case, on WMF wikis we can safely point them all at Meta.
If you have comments on this proposal, please reply here or on
https://gerrit.wikimedia.org/r/#/c/386625/.
Background: The upcoming actor table changes[6] require some change to the
handling of these imported names because we can't have separate attribution
to "Example as a non-registered user" and "Example as a registered user"
with the new schema. The options we've identified are:
1. This proposal, or something much like it.
2. All the existing rows with rev_user = 0 would have to be attributed
to the existing local user (if any), and in the future when a new user is
created any existing edits attributed to that name will be automatically
attributed to that new account.
3. All the existing rows with rev_user = 0 and an existing local user
would have to be re-attributed to different *valid* usernames, probably
randomly-generated in some manner, and in the future when a new user is
created any existing edits for that name would have to be similarly
re-attributed.
4. Like #2, except the creation (including SUL auto-creation) of the
same-named account would not be allowed. Thus, an import before the local
name exists would forever block that name from being used for an actual
local account.
5. Some less consistent combination of the "all the existing rows" and
"when a new user is created" options from #2–4.
Of these options, this proposal seems like the best one.
[1]: https://phabricator.wikimedia.org/T9240
[2]: https://phabricator.wikimedia.org/T179246
[3]: https://gerrit.wikimedia.org/r/#/c/386625/
[4]: https://phabricator.wikimedia.org/T111605
[5]: ">" was chosen rather than the more typical ":" because the former is
already invalid in all usernames (and page titles). While a colon is *now*
disallowed in new usernames, existing names created before that restriction
was added can continue to be used (and there are over 12000 such usernames
in WMF's SUL) and we decided it'd be better not to suddenly break them.
[6]: https://phabricator.wikimedia.org/T167246
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hi there,
The Technical Wishes Team of Wikimedia Germany is currently working on a
soon-to-be deployed major improvement of the diff view engine. [1]
It is now available on test wiki [2] and Mediawiki [3] and it would be
great if you could test it and tell us if you encounter any bugs. [4] The
deployment to all other wikis will hopefully happen in the near future.
While working on this, we also found an old bug in the diff engine:
Sometimes two paragraphs which are not related at all are considered a
changed paragraph: example [5]. We have fixed this bug now and it was
already deployed on all wikis by the end of October. [6] [7]
The bigger improvement of the diff view will be announced separately, once
the date for its deployment is fixed – expect it in a few weeks.
Regards,
Michael for the Technical Wishes Team
[1]
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Show_text_changes_whe…
[2] http://test.wikipedia.org
[3] http://mediawiki.org
[4] https://phabricator.wikimedia.org/T146781
[5]
https://meta.wikimedia.org/wiki/File:ImprovedDiff_-_Example_1_-_before2.png
[6] https://gerrit.wikimedia.org/r/#/c/356582/,
[7] https://phabricator.wikimedia.org/T146781
--
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.
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **today, Wednesday 4-5 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. 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 WMDE’s tech team)
--
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,
There was no significant change in Malayalam language support since 2013 in
operating systems. Last OS which has incomplete Malayalam support was
Windows XP (without any service package), so it is irrelevant. There was no
prior notification about this removal. Malayalam webfonts were simply
unilaterally removed from Malayalam projects (just like it's deployment).
We Malayalam wikimedians like to know the substantial changes in
circumstances which lead to removal of Malayalam fonts from ULS. Please
also note that so many other languages which are much bigger in number of
speakers and well supported in OSs even before Malayalam, are still serving
webfonts in ULS (eg: Arabic, Tamil, Kannada etc).
There was occasion when a webfont imposed (maintained upstream by ULS
developer) on Malayalam community. User community members were asked
consensus for each and every word about this imposed webfont font. Once
Wikipedia editing was entirely impaired for weeks by removing typing tool
(ULS removed by misreading the bug) after these 'skirmishes'. Users were
abused and even humiliated based on their tribe by 'sidekicks' in public
mailing lists and forums. As a small community who lost a significant
number of users and thus growth, because of the problems in the deployment
of webfonts and antipathy, we believe we have the right to know the
circumstance/study/reason about this removal.
Related links:
https://phabricator.wikimedia.org/rEULS28c0ba6bca63e658160f772cdef141c2b929…https://phabricator.wikimedia.org/T53019https://phabricator.wikimedia.org/T51894
The fullfilled request for webfonts as an optional feature asked after
community consensus, also broken here.
---
ml:User:Praveenp
