I wanted to invite all of you to the OpenStreetMap hackweekend on July 2
and 3 in Bangalore being hosted at the Mapbox office. We will spend two
full days working on projects like iD, openstreetmap-website, JOSM etc.
You can see all the projects and ideas in the wiki
one or propose your own.
If you are in town and want to contribute to OpenStreetMap, this is a great
opportunity to get started alongside expert developers on the open mapping
stack! Wikimedia projects have already started integrating maps from OSM
https://www.mediawiki.org/wiki/Maps and this can be a useful space to begin
work on ideas for greater collaboration between the communities.
Please RSVP (https://osmhackweekend.splashthat.com/) and let me know if you
have any questions.
Read more: https://www.mapbox.com/blog/osm-hackweekend/
== What is happening? ==
Secure connections to RCStream currently use an SSL/TLS certificate
specific to stream.wikimedia.org. To streamline certificate management, we
are moving RCStream behind our misc caching cluster, which will allow us to
use the wildcard certificate for *.wikimedia.org, making the
RCStream-specific certificate redundant. This will reduce operating costs
and improve performance in certain cases.
== When will this happen? ==
== How could this affect me? ==
This change requires updating the DNS record for stream.wikimedia.org. We
do not expect any service disruptions. It is conceivable (but unlikely)
that you will need to restart your client. If your client is based on one
of the published examples, you should be fine. If you are not sure, feel
free to get in touch with me (ori(a)wikimedia.org).
If you are connecting to RCStream over an insecure (http) connection, now
would be a great time to migrate to https. http access to RCStream will
eventually be disabled; migrating now will protect you from any
interruptions down the line. In most cases, making your client use https is
as simple as prefixing 'stream.wikimedia.org' with 'https://'. Sample
client code on Wikitech has been updated.
== How can I track this work? ==
By following https://phabricator.wikimedia.org/T134871.
On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote:
> Federico Leva (Nemo) wrote:
>>Login pretty much never does what I expect nowadays, but I'm not sure my
>>expectations are correct so I can't identify actual bugs.
> There are various open tasks in Phabricator about user sessions currently,
> such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly
> logged out lately has been a bit annoying, though I don't know if it's
> related to the Performance team or some other team.
The origin of the unexpected logouts falls on the AuthManager project
and specifically the SessionManager component that rolled out in
1.27.0-wmf.11 . We had various issues related to the session
handling changes including a bug that was overloading the storage
capacity of the Redis servers that store session data  and two
other issues which required rolling the wikis back to 1.27.0-wmf.10
Both rollbacks were accompanied by a run of the
"resetGlobalUserTokens.php" maintenance script which updates each
user's CentralAuth records in such a way that their authentication
session will be considered invalid the next time it is used on a wiki.
This was done from an abundance of caution point of view concerning
possible issues with sessions that had been issued by the
SessionManager software. The reset script is not fast , so session
invalidation has slowly worked its way across the CentralAuth user
Part of the enhancements that are being applied in order to bring
SessionManager back to production with 1.27.0-wmf.13 is a new config
setting that can be used to give us a nearly instant switch to throw
to invalidate all active sessions. This setting is actually included
in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has
not been changed to make use of it yet. Invalidating all user sessions
is not something we plan to do for fun certainly, but there have been
in the past (and likely will be in the future) software and
configuration issues that necessitate the use of that heavy hammer
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I'm happy to announce a new mirror for datasets other than the XML dumps.
This mirror comes to us courtesy of the Center for Research Computing,
University of Notre Dame, and covers everything "other"  which includes
such goodies as Wikidata entity dumps, pageview counts, titles of all files
on each wiki (daily), titles of all articles of each wiki (daily), and the
so-called "adds-changes" dumps, among other things. You can access it at
http://wikimedia.crc.nd.edu/other/ so please do!
The Wikimedia Language team has been assembling monthly reports about
language support activities for one year. You can read the latest
Highlights for May include: Special:Translate got an edit summary
field and modernization of web font formats: woff2 is in, eot is out.
Due to the nature of our work, the Language team  (Amir, Kartik,
Pau, Runa, Santhosh, and myself) alone cannot adequately support all
the languages of the Wikimedia movement. That is why the report
includes work by volunteers. We have bolded the names who we believe
are contributing as volunteers.
This report focuses on technical activities. You wont find future
plans or high level roadmap items on it. There is currently a major
omission: the i18n work of MediaWiki core itself. That is lacking
because it is more difficult to filter those activities and also
because we have not had much time for MediaWiki core i18n work.
To acknowledge the work of volunteers and to support them better, the
Language team released a statement of intent for code review  about
six months ago. To summarize: we attempt to review patches not by us
within a week, and patches stalled due to no updates after review for
three months will be abandoned -- unless we feel they are worth fixing
When we released the statement, we also agreed to reduce the existing
backlog of open patches. The results so far are positive, even though
it is easy to find examples where we have not been able to follow our
intent. Translate extension had 35 open patches when we started in
February -- at end of May it had only 12 open patches . Universal
Language Selector had gone from 10 to 6, and fewer of them unreviewed.
Content Translation had gone from 15 to zero. Our jquery repositories
in GitHub have not fared as well, but we hope to achieve similar
results there in the future.
We excluded many repositories from the statement of intent in the fear
that we would add too much of a burden to ourselves. To our delight,
except MediaWiki core i18n, all those repositories have had swift
reviews and I count only two open patches in them.
- Niklas (on behalf of the Language team)
 The numbers change constantly. As of 2016-06-17 Translate has 23
open patches, but only 10 of them not from our team. Universal
Language Selector has 13 patches, 5 of them not from our team. Content
Translation currently has 6, one of them not from our team.