As we approach another quarterly planning cycle, I'd like to bring my
proposal for how we can improve our quarterly planning and review process.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Goals_Proposal
Do people support implementing these changes for the Q4 planning cycle? If
you have input, could you please participate in the discussion on the talk
page by Feb 5 (next Friday)?
- Trevor
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-01-27
= 2015-01-27 =
== Product ==
=== Reading ===
==== Android ====
* Hotfix for login issues, v2.1.138, in production.
* v2.1.139 beta published for changes in Wiktionary API and removal of "m."
requests.
* Android saved synchronized articles implementation in progress (using
API's userjs feature).
* Even better memory profile coming soon.
==== iOS ====
* Evaluating pageviews API usage for "Trending/Top Articles" feature in 5.0
* Need to start evaluating impact of API usage in 5.0 (particularly
extensive use of extracts prop w/ search
* Login/Account creation integration meeting (AuthManager API changes in MW
core)
==== Web ====
* User page enhancements coming to mobile web (removal of
Special:UserProfile)
* PageImages API updates being examined (Fair use of images)
* Language overlay changes
* QuickSurveys enhancements
==== Reading Infrastructure ====
* Block: Security, are we good on https://gerrit.wikimedia.org/r/#/c/264309/
?
=== Community Tech ===
* Wrapping up work on Gadgets 2.0 https://www.mediawiki.org/wiki/Gadgets_2.0
** Could probably use a security review from Chris once it's done -
https://phabricator.wikimedia.org/T124943
* Collaborating with volunteers on Dead link rescue (bot) and Pagestats
tool (still in planning stage)
* Working on getting PageAssessments extension ready for testing as a
prototype https://www.mediawiki.org/wiki/Extension:PageAssessments
** Already had security review and DBA review
=== Editing ===
==== Language ====
* Got parallel corpora tables created
* Working on AbuseFilter
** Many articles not published due to AbuseFilter warnings/errors
** We are improving UI to better surface these warnings and what they mean
** Also trying to figure how to get more exact locations of the issues out
of AbuseFilter
** If any AbuseFilter experts around, I might have questions
* cxserver itself is ready for Node 4.2, but the Apertium packages are
still WIP (T106385), no estimate of when they'll be done.
** how urgent is this?
*** Answer: Don't have to do both at the same time.
==== Collaboration ====
* Moriel is working on having human-readable names for all Wikimedia wikis
available programatically in all languages. Initially, this will be used
for cross-wiki notifications, but it can potentially be used in many other
areas. https://phabricator.wikimedia.org/T121936
* Jaime approved the Flow dry run patch for the External Store migration.
It now needs to be reviewed by our team and then tested on Beta Cluster.
* I'll (Matt Flaschen) be at FOSDEM, and lead the MediaWiki stand
presence. I'm also presenting on the LiquidThreads to Flow conversion.
See wikitech-l for more information.
==== VisualEditor ====
* Blockers: https://phabricator.wikimedia.org/T58337 is blocked on review
from Krinkle for https://gerrit.wikimedia.org/r/#/c/259771/ and
https://gerrit.wikimedia.org/r/#/c/265878/ and so
https://gerrit.wikimedia.org/r/#/c/265879/
* Blockees: Only known blockee is Design Research, waiting on above patches
to land on Beta Cluster.
* Production deployment on shared feedback page and VE default-on for
another few wikis delayed from Monday due to the train; not yet scheduled.
==== Multimedia ====
* No known blockers or blockees.
=== Discovery ===
* found temp solution for load spikes, moved more_like traffic to another
cluster
** working on improving "more like" performance, may change results, will
a/b test https://phabricator.wikimedia.org/T124258
* working on yearly plan/budget
* started loading analytics data into ElasticSearch, full run takes ~12
hrs, may need to look for performance improvement
* Working on integrating completion search into SearchEngine API
* Blazegraph 2.0 is out, Wikidata Query service upgrading soon
* Blocked:
** need help from Ops for access analytics->codfw for
elastic20{01..24}.codfw.wmnet, er, I 'd rather not have ACLs on the routers
referring to non intra DC things. Why is that needed ? Task ? Same reason
we needed it before, we need to get data from analytics to ES machines and
this is the only way we found we can do it right now.
https://phabricator.wikimedia.org/T120281
eqiad access works, but codfw one does not.
== Advancement ==
=== Fundraising Tech ===
* Creating CI job to test DonationInterface on mw branch deployed on
payments cluster
** thanks Antoine!
* Working on new fraud filters
* More CiviCRM fixes and improvements
* Making code changes to expand Latin America fundraising from just Brazil
to six other countries
== Technology ==
=== Technical Operations ===
* Blocked: Research on ORES
* Blocked by: none
* Updates:
** Had an outage yesterday. all *.wikimedia.org was redirected to
wikimedia.org
** mira is now the deployment server, NOT tin
** Got an OTRS upgrade on Feb 3
** HHVM 3.11 packages are ready to go:
http://anonscm.debian.org/cgit/pkg-hhvm/hhvm.git/log/
** mobile traffic varnish clusters get folded into the text clusters.
** Need help with:
*** https://phabricator.wikimedia.org/T124649 module dependencies handling,
mediawiki core ?
*** https://phabricator.wikimedia.org/T124651 RELENG. phabricator is
misbehaving when a git repo is missing
*** https://phabricator.wikimedia.org/T124418 Investigate massive increase
in htmlCacheUpdate jobs in Dec/Jan
=== Services ===
* EventBus
:* extension emitting events live in prod
* Move to Jessie and Node 4.2
:* Graphoid and Citoid - done
:* CXServer - please check!
::* Apertium pkgs?
:* RELENG. CI support for Node 4.2
::* https://phabricator.wikimedia.org/T119143
:* RELENG. Migrate to Node 4.2 in BetaCluster
::* task to be created :P
=== Security ===
* More patches on the cluster; deploying updates for LanguageConverter this
week
* Keystone plugin development underway
=== Research ===
* Blocked: none
* Blocked by:
** ORES moving to new meso-level (Labs < Meso < Prod) support -- blocked on
Ops time to set up machines
*** See https://phabricator.wikimedia.org/T106867 -- working with Yuvi to
flesh out sub-tasks -- need to know who to CC
=== Release Engineering ===
* *Blocking*: YES (as of today ;-) )
* *Blocked*: none
* *Updates:*
** scap 3.0 will be tagged and packaged soon
*** Finishing work on puppet provider
** Shifting the MW train window starting next week to 2000 UTC (noon PST)
** Re-deploying 1.27.0-wmf.11 this week after last week's rollback due to
SessionManager issues
** Discussing ways to improve reliability and recoverability of train
deploys (tools and process)
** Annual planning all the things
I ran into an issue trying to save MediaWiki:Common.js I get this page not available (index.php?title=MediaWiki:Common.js&action=submit)
MediaWiki:Common.css save fine
Any Idea what I'm doing wrong?
Thank you!
Trying again from a different address
On 26 January 2016 at 01:04, Alex Monk <amonk(a)wikimedia.org> wrote:
> Forwarding to wikitech-l since this is not really specific to staff, but
> all shell users.
>
> On 25 January 2016 at 20:39, Ori Livneh <ori(a)wikimedia.org> wrote:
>
>> The X-Wikimedia-Debug header, for those of you who don't know, is an HTTP
>> request header that you can set on your requests (either manually, or by
>> using the Chrome[1] or Firefox[2] extensions). Requests bearing this header
>> are always treated as cache misses by Varnish, and they are always routed
>> to the same backend, mw1017.
>>
>> In addition to handling X-Wikimedia-Debug requests, mw1017 is also
>> configured as the sole application server backend for all requests to
>> test.wikimedia.org. This was set up before X-Wikimedia-Debug existed,
>> and as a debugging tool it is (IMO) inferior to it, because
>> X-Wikimedia-Debug allows you to test code changes against any production
>> wiki.
>>
>> What I've seen happen before is developers (like me -- I've done this
>> before) live-hack code on mw1017 to debug some issue that is only showing
>> up in production. This can cause testwiki to break, which annoys developers
>> and editors who use testwiki for testing things like Lua modules or editing
>> functionality on mobile apps.
>>
>> To reduce contention for mw1017, I propose that we do the following:
>>
>> 1) Keep testwiki, but don't special-case it in Varnish
>> (in other words, have testwiki requests go to the standard app server
>> pool)
>>
>> 2) Reserve mw1017 exclusively for X-Wikimedia-Debug requests
>>
>> 3) Add a service alias (appservers-debug.svc.eqiad.wmnet) for mw1017 and
>> update the varnish backend config to use that, rather than hard-code mw1017
>> in VCL.
>>
>> Thoughts?
>>
>> [1]:
>> https://chrome.google.com/webstore/detail/wikimediadebug/binmakecefompkjggi…
>> [2]:
>> https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/
>>
>>
>> _______________________________________________
>> Engineering mailing list
>> Engineering(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
> --
> Alex Monk
> VisualEditor/Editing team
> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>
The other day, someone came and renamed the Phabricator projects for
various skins from MediaWiki-skins-Foo to just Foo.
A few days later, someone else came and renamed them all back.
Since I'm a member of a few of these projects, I've gotten lots of email
about this, twice.
(Example: https://phabricator.wikimedia.org/project/profile/355/)
And the projects are inconsistently named at the moment, since both
persons missed a few spots:
https://phabricator.wikimedia.org/project/query/xTNAyyYaAY0U/#R
So, what should the names be?
--
Bartosz Dziewoński
Hi all,
The Collaboration team is currently working on a variety of
improvements and updates to the Notifications (Echo) extension.[1]
One task is improving how the many different types of notifications
are sorted, into the two fly-out menus. Your feedback would be
especially appreciated here.
TL;DR: Please see this spreadsheet, listing the Current split, and 3
alternative groupings:
https://docs.google.com/spreadsheets/d/1eVQVbzVhhVejEMnVqRBC98weBnfrnZqcGEx…
(or a simplified version, and without the 3rd more complex
"Experimental" grouping, at https://phabricator.wikimedia.org/T123018
)
The team is currently recommending we start off with the "By urgency"
grouping. There is a list of Pros/Cons for each, in the spreadsheet.
Please give us feedback, either at phabricator, or at
https://www.mediawiki.org/wiki/Topic:Sw196pvf5vwt6pku
Detailed information on the goals and background of this task, is
included in both the phabricator and mediawiki.org links.
Much thanks,
Quiddity / Nick
[1] https://www.mediawiki.org/wiki/Notifications#Future_plans_and_requests_for_…
--
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation
Hi,
Here's an interesting video that we didn't get to show on the Developer
Summit.
This is me with my Nexus 5 (Android 6) on 2G in Spain loading
en.m.wikipedia.org/wiki/Barack
Obama
https://www.youtube.com/watch?v=W1w0EcuiUjo
Write your own conclusions, hopefully this will make us think.
If you can set your device from your country to 2G and try it out on an
incognito window (cold cache) and share the results, I would be very
interested to see if your experience is the same as mine.
Cheers,
Joaquin
The Wikimedia Hackathon (Jerusalem, 31 March - 3 April) is approaching and
we are receiving new registrations every day.
Two initiatives are being considered by local members of Wikimedia Levant,
thanks to the proximity of the biggest Wikimedia technical event:
A technical workshop at WikiArabia in Amman (Jordan) on 24-26 March.
https://phabricator.wikimedia.org/T124217
A technical workshop in Ramallah or Birzet (Palestine) one day betweenn
WikiArabia and the Wikimedia Hackathon.
https://phabricator.wikimedia.org/T124721
We are in the earliest stages of planning. People interested, please
subscribe / comment in the tasks.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I haven't been able to setup the installation for mediawiki-vagrant .
I'm running WAMP stack. Is windows the problem ?
Anyways, I started again from the scratch to avoid any error caused by
myself earlier .Cloned it as ->
ssh://dg7@gerrit.wikimedia.org:29418/mediawiki/vagrant.git
Now ,on vagrant up , it clones the mediawiki as well as other
repositories via https only ,i.e,
https://gerrit.wikimedia.org/r/p/mediawiki/core.git
(
no commit access) .
How should I go about it ?
the log gives the following message at last :
The SSH command responded with
a non-zero exit status ........
The code loads on requesting 127.0.0.1:8080 , The only problem
presently is with this SSH issue .
So, it runs like this with just monobook role enabled .
The screenshot :
https://phab.wmfusercontent.org/file/data/rdduw4p2eua22zs3ed77/
PHID-FILE-sjw6fj5oezch467kkdkh/
3yd57vaes5ncfv3s/Screenshot_%28168%29.png
Now, when I enabled and provisioned for "Flow" role
besides the monobook role, it all broke when I
executed "vagrant reload".
screenshot :
https://phab.wmfusercontent.org/file/data/ae26yakvhhieoizpkday/
PHID-FILE-xpy3pmwv3ejbxsrcntu2/onrit2xyn2mqmp53/
Screenshot_%28169%29.png
log ( provision ) : https://dpaste.de/kO0W
log( reload ) : https://dpaste.de/ePbW
I'm working on this task currently :
https://phabricator.wikimedia.org/T72472
So...
I stopped development on the Persona extension a while ago when Mozilla dropped official support for it, but with persona.org shutting down, I am considering deprecating the extension entirely, especially considering the work that would be required porting it to AuthManager.
But I figured I'd give a sort of last call. Is there anybody here that knows if the extension is being used (despite being marked as experimental) and thinks I should still maintain some sort of support for it?
--
Tyler Romeo
https://parent5446.nyc
0x405D34A7C86B42DF
From: Ryan Kelly <rfkelly(a)mozilla.com>
Reply: dev-identity(a)lists.mozilla.org <dev-identity(a)lists.mozilla.org>
Date: January 11, 2016 at 20:09:31
To: dev-identity(a)lists.mozilla.org <dev-identity(a)lists.mozilla.org>, persona-notices(a)mozilla.org <persona-notices(a)mozilla.org>
Subject: Shutting down persona.org in November 2016
Hi Everyone,
When the Mozilla Identity team transitioned Persona to community
ownership, we committed resources to operational and security support
throughout 2014 [1], and renewed that commitment for 2015 [2]. Due to
low, declining usage, we are reallocating the project’s dedicated,
ongoing resources and will shut down the persona.org services that we run.
Persona.org and related domains will be taken offline on November 30th,
2016.
If you run a website that relies on Persona, you will need to implement
an alternative login solution for your users. We have assembled a wiki
page with additional information and guidelines for migration [3], but
here are the important things you need to know:
Between now and November 30th, 2016, Mozilla will continue to support
the Persona service at a maintenance level:
* Security issues will be resolved in a timely manner and the services
will be kept online, but we do not expect to develop or deploy any
new features.
* Support will continue to be available on the dev-identity mailing
list [4] and in the #services-dev IRC channel [5].
* All websites that rely on persona.org will need to migrate to
another means of authentication during this period.
Beginning on November 30th, 2016, the Persona service hosted by Mozilla
will be decommissioned:
* All services hosted on the persona.org domain will be shut down.
* Mozilla will retain control of the persona.org domain and will
not transfer it to a third party.
* Since the privacy of user data is of utmost importance to Mozilla,
we will destroy all user data stored on the persona.org servers,
and will not transfer it to third parties.
We intentionally designed Persona to expose email addresses rather than
opaque identifiers, which should ease the transition to other systems
that provide verified email addresses. You can find guidelines on
alternative login solutions on the wiki [3] and we will continue to
update them over the coming year. We strongly encourage affected teams
to openly discuss and blog about their migrations on the dev-identity
mailing list so that others can learn from their experience.
Thank you for your support and involvement with Persona. If you have any
questions, please post them to the dev-identity mailing list.
Ryan
[1]
http://identity.mozilla.com/post/78873831485/transitioning-persona-to-commu…
[2] https://groups.google.com/forum/#!topic/mozilla.dev.identity/rPIm7GxOeNU
[3]
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
[4] https://lists.mozilla.org/listinfo/dev-identity
[5] http://irc.mozilla.org/#services-dev
_______________________________________________
Persona-notices mailing list
Persona-notices(a)mozilla.org
https://mail.mozilla.org/listinfo/persona-notices