https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-12-09
= 2015-12-09 =
== Reading ==
=== Android ===
* 2.1.135-beta-2015-12-03 published to beta only.
* 2.1.136-* release candidate to be published as beta soon.
** Only bug fixes and polish since v2.1.135.
** New Wikipedia Maps promotion from beta to prod to appear in this release.
** Final planned release of 2015.
=== iOS ===
* Doing regression testing before wider, public beta distribution of
Wikipedia 5.0.0
* Considering Mobile Content Service integration (perhaps as a beta
experiment) as Q3 "reach" goal
** (
https://www.mediawiki.org/wiki/Reading/Quarterly_Planning/Q3#iOS_Goals_.28n…)
=== Mobile Content Service ===
* 10% of Android Beta App users use the RB based service for link previews
(page summary) + page content
=== Reading Infrastructure ===
* We're concerned that oojs-ui is what we're supposedly wanting to move UI
stuff to, but oojs-ui is apparently unowned and development is blocked on
T113681 with no one planning to work on it (and people are being encouraged
to shove stuff into mw.widgets to hack around that block).
** ApiSandbox is now theoretically blocked on Brad finding time to apply
said hack, since we've determined oojs-ui isn't getting new functionality
any time soon..
== Technology ==
=== Security ===
* Reviews: ArticlePlacement (waiting for wikidata), Thumbor in progress,
RevisionJumper this week
* Secure Code training today, 3:30pm PST -
https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084213.html
* Need help: T118769 (Ops, someone who can help with vcl)
* Goals: 2FA for wiki accounts, and possibly changes to Javascript
permisions (T120889, T120886) . Input welcome.
**
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Goals_201516#Q3_.28J…
=== Technical Operations ===
* Blocking: none
* Blocked by: none
* Updates:
* Migration from OpenDJ to OpenLDAP successful. Some minor wake from
the migration, solved today
* ops get their yuvikeys one by one
* moving on with scaling alerting monitoring
* drafting Q3 goals
=== Services ===
* Actively working with RelEng on Scap3
:* Current goal: set up AQS in beta
* RESTBase v0.9.0 released
:* many config style changes
:* Analytics - need to coordinate next deploy (config changes)
:* move RESTBase to service::node -
https://gerrit.wikimedia.org/r/#/c/257898/
* EventBus
:* extension emitting events now in Beta, after tests moving to prod (next
week)
:* need security review
:* HTTP proxy service work continues (Analytics)
:* working on change propagation
* CXServer move to service-runner
:* let's schedule the actual merge/deploy, Kartik, Alex
* Goals for next Q: https://phabricator.wikimedia.org/T118868
:* finalisation tomorrow
:* if you have JobRunner jobs, we'd like to talk to you about moving them
to the EventBus
== Release Engineering ==
* *Blocking*: (none)
* *Blocked by*: (none)
* *Updates*:
** Scap3 refactoring and tech debt cleanup
*** https://phabricator.wikimedia.org/project/view/1449/
*** Deployed AQS in Beta Cluster
*** Moving on to support Mathoid
*** One Q3 goal is to support MediaWiki deployments
** Rolling responsibility of cutting MediaWiki branches
*** Bear with noobs
== Discovery ==
* Portal A/B test launched
* Completion suggesters beta feature deployed soon
* Working on Q3 goals
* No blocking/blockers
=== Maps/Graphs ===
* interactive graphs are on the train -
https://test.wikipedia.org/wiki/DynamicGraph
* Do not perform image quality reduction for any zero partners, or it may
corrupt image URLs
* Will push kartographer extension to beta cluster
== Fundraising Tech ==
* Tiny, conservative fixes to Central Notice and payments-wiki
* Bunch of new visualizations for the internal fundraising dashboard
* Dealing with interesting behaviors of the new CiviCRM verison
** Actually upstreaming a bunch of fixes!
* Watching donation streams and error logs
* More testing of backup credit card processor
* Gathering stats on donatewiki clicks
** Will replace 3rd-party email performance tracking, which has been
redirecting users through weird-looking domains
==Community Tech==
* Wrapping up Wishlist Survey
* Working on Gadgets 2.0
* PageAssessments extension - need some help figuring out job/database
scalability
== Editing ==
=== Parsing ===
* Discovered use of "wikitext as a database" page (
https://ur.wikipedia.org/wiki/%D9%86%D8%A7%D9%85_%D9%85%D9%82%D8%A7%D9%85%D…
)
that was being updated multiple times a minute by bots
** Let to a 80% and higher load on the Parsoid cluster over the last 4-6
hours because the DOM is larger than what Parsoid can reliably handle.
** Filed https://phabricator.wikimedia.org/T120972: Introduce configurable
wt2html/html2wt to deal with this; On the RESTBase end, there is
https://phabricator.wikimedia.org/T120971 (Blacklist automatic updates for
especially expensive pages)
Hi everyone, here's what the Community Tech team's been up to lately.
* Community Wishlist Survey: we've been running this survey to identify the
most important features and fixes to work on in 2016; you might have heard
about it because we've been spamming mailing lists and village pumps. If
you haven't checked it out yet -- the voting phase ends on Monday, please
come and vote for the proposals you want to support! There are a lot of
proposals, and many of them are awesome.
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey
* Gadgets 2.0: A new Gadget Manager has been in the works for a long time,
to replace Mediawiki:Gadgets-definition as the interface for managing
gadgets on a wiki. Community Tech is helping to complete the feature -- in
November, we created new Gadget and Gadget_definition namespaces and
content models, and we're currently working on the Gadget Manager itself.
For more info: https://www.mediawiki.org/wiki/Gadgets_2.0 and
https://phabricator.wikimedia.org/T31272.
* GadgetUsage: We made some improvements to the Special:GadgetUsage report,
filtering out removed gadgets and adding a recently active users count. You
can see the improved report at
https://www.mediawiki.org/wiki/Special:GadgetUsage, and it'll roll out to
more projects next week.
* Citation bot: We've been working on getting Citation bot into shape;
check out https://phabricator.wikimedia.org/T108412 for more.
In December, we've got more work coming up on Gadget Manager, Citation bot
and storing WikiProject article assessment metadata. Plus come and vote in
the Wishlist Survey so that we have interesting things to work on in
January. Thank you and good night.
DannyH (WMF)
Community Tech
(cross-posted to Wikimedia-l, Wikitech-l and WMF staff lists, sorry for the
duplication)
On Wed, Dec 2, 2015 at 6:32 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:
> On [T118932], I proposed a process whereby the RFC will be reopened
> for review if any existing Phabricator user will second the motion. If
> you do object, please register your objection on Phabricator.
>
> In the meantime, please do not merge any changes which require PHP 5.4+.
Thanks for your caution here, Tim. A large merge requiring PHP 5.5
might be messy to unravel.
Per our discussion earlier, I filed T120164 [1] proposing to institute
a "last call" period for MediaWiki RfCs. As a result of this, we
might not to use RFC meetings as the final decision on approval.
I filed T120164 with a little hesitancy. I believe that we've made
the RFC process more efficient these past few months, such that it
should be possible to *reverse* an RFC quite simply: write another
RFC. The more process we layer onto each individual RFC, the harder
it is to use them for nimble decision making.
We also discussed having some sort of minimum discussion time on
wikitech-l prior to having the decision-oriented RFC meeting. That
seems sensible, with the caveat that we discussed: we should ask that
those proposing RFCs announce their intention on wikitech-l, directing
the conversation toward the Phab ticket associated with the RFC. The
Phab ticket should be the "discussion of record", whereas wikitech-l
can be "announcement of record" (torturing the "newspaper of record"
metaphor[2])
I think a "last call" period, if done correctly, can be a lightweight
safeguard that can maximize participation and provide for welcome
scrutiny. Done incorrectly, and it's a new way for stubborn defenders
of the status quo to get everyone the hell off of their lawn. ;-)
That's one of the things that worries me about making it too easy to
reopening RFCs. It seems here in the U.S. we were able to repeal the
18th amendment with the 21st amendment. Even with a process as
complicated as amending the U.S. constitution, the results were
reversible. Our process (hopefully) isn't that complicated, but let's
avoid making it more complicated by handwringing over the approval
process.
Rob
[1] <https://phabricator.wikimedia.org/T120164>
[2] https://en.wikipedia.org/wiki/Newspaper_of_record
Hello Everyone,
Hope you are enjoying the approach of the end of the year. In the last 3
months the reading team has worked on a process for open strategy planning
[0], in order to define priorities, and align tests and products that the
team works on, with broader movement goals.
Given the strategy work, planning for Q3 (the next quarter: Jan - March) is
different; the team is sharing its roadmap for Q3 and Q4 [1], as well as
the actions planned for Q3 [2] early on. Despite of the strategy work and
planning, these documents are still work in progress; adaptations and
changes are likely to take place, given the time frame and tests included.
However, the team is sharing early in order to accommodate feedback. You
can also add suggestions for Q4 (Apr - Jun), as long as they align with the
roadmap.
This is the first team the team shares its plans early and openly, and
allows room for feedack and suggestions in future planning. We trust that
the open process will help with better engagement and more lessons to learn
on best practices.
Enjoy December!
All the best,
M
[0] https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing
[1] https://www.mediawiki.org/wiki/Reading/Roadmap
[2] https://www.mediawiki.org/wiki/Reading/Quarterly_Planning/Q3
[3] https://www.mediawiki.org/wiki/Reading/Quarterly_planning/Q4
For your information:
"Applications are open until Saturday, January 09 2016 23:59 UTC."
---------- Forwarded message ----------
From: Martin Rulsch <rulschmartin(a)gmail.com>
Date: Tue, Dec 8, 2015 at 10:26 PM
Subject: [Wikimedia-l] Wikimania 2016 scholarship applications open
To: "Wikimania general list (open subscription)" <
wikimania-l(a)lists.wikimedia.org>, Wikimedia Mailing List <
wikimedia-l(a)lists.wikimedia.org>
Thanks again, Dan Garry, for pointing me on this again-ill formatted mail.
Cheers,
Martin
----
Hi all, Scholarship applications for Wikimania 2016 which is being held in
Esino Lario, Italy on June 22–27, 2016 are now being accepted. Applications
are open until Saturday, January 09 2016 23:59 UTC. Applicants will be able
to apply for a partial or full scholarship. A full scholarship will cover
the cost of an individual's round-trip travel, shared accommodation, and
conference registration fees as arranged by the Wikimedia Foundation. A
partial scholarship will cover conference registration fees and shared
accommodation. Applicants will be rated using a pre-determined selection
process and selection criteria established by the Scholarship Committee and
the Wikimedia Foundation, who will determine which applications are
successful. To learn more about Wikimania 2016 scholarships, please visit:
https://wikimania2016.wikimedia.org/wiki/Scholarships To apply for a
scholarship, fill out the multi-language application form on:
https://scholarships.wikimedia.org/apply It is highly recommended that
applicants review all the material on the Scholarships page and the
associated FAQ ( https://wikimania2016.wikimedia.org/wiki/Scholarships/FAQ
) before submitting an application. If you have any questions, please
contact: wikimania-scholarships at wikimedia.org
<wikimania-scholarships(a)wikimedia.org> or leave a message at:
https://wikimania2016.wikimedia.org/wiki/Talk:Scholarships Please help us
spread the word! Best regards, for the Scholarship Committee
https://wikimania2016.wikimedia.org/wiki/Scholarship_committee
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi, all!
I'm writing to share a prototype image editor that our very own Prateek
(prtksxna) has been working on. We're hoping to write an extension
around this and provide it on-wiki as a replacement for several bots and
off-wiki tools. It's only an experiment, but honestly, our upload
pipeline lacks an editing tool, which is *so* 2003. I'm looking towards
getting this released on Commons, as a BetaFeature™, within the next few
months.
Feedback can be shared here, on GitHub in the form of issues, on IRC in
#wikimedia-multimedia, or via private e-mail to myself or Prateek, if
you prefer.
The code is here: https://github.com/prtksxna/ImageEditor
You can try a demo here: http://prtksxna.github.io/ImageEditor/
And finally, there's a sneak peek at the API documentation here:
http://prtksxna.github.io/ImageEditor/docs/index.html
Thanks for your eyeballs and time!
--
Mark Holmquist
Lead Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
http://marktraceur.info
Hey everyone,
I've recently initiated a consultation to help decide on topics for IdeaLab
campaigns for the future, and I'm very interested in your input on what
technical issues, gaps, or general features we could consider focusing our
attention upon. These campaigns can generate novel proposals for tools and
improvements to address needs in the Wikimedia projects to which you
contribute:
<https://meta.wikimedia.org/wiki/Grants:IdeaLab/Future_IdeaLab_Campaigns>
You can offer feedback and add your own campaign topics through a survey
conducted through AllOurIdeas <http://www.allourideas.org/idealab_campaigns>
in addition to participating on the IdeaLab talk page.
I’m looking forward to seeing your feedback and exploring potential
directions we can take IdeaLab campaigns starting next year.
Take care,
Jethro
--
Chris "Jethro" Schilling
I JethroBT (WMF) <https://meta.wikimedia.org/wiki/User:I_JethroBT_(WMF)>
Community Organizer, Wikimedia Foundation
<https://wikimediafoundation.org/wiki/Home>
Hello,
This is the monthly report from the Wikimedia Performance team.
## Our progress ##
* Availability. We've done a major overhaul of the ObjectCache interfaces. Many
factory methods were deprecated or removed, reducing it to just four simple
entry points. New docs at
https://doc.wikimedia.org/mediawiki-core/master/php/classObjectCache.html#d…
We've written a new IExpiringStore interface for convenient TTL constants,
e.g. $cache::TTL_WEEK. See
https://doc.wikimedia.org/mediawiki-core/master/php/interfaceIExpiringStore…
We've migrated most use of wfGetMainCache() to WANObjectCache. Work
continued on the librarization of BagOStuff, Memcached, and other object
cache classes.
* Performance testing infrastructure. We've created dedicated dashboards
for portals:
https://grafana.wikimedia.org/dashboard/db/webpagetest-portals
And for mobile:
https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest
We now test one page using real 3G connections (from San Francisco and
Bangalore) and test other pages using the following physical devices:
iPhone 6, iPad mini 2 and Moto G.
* Media stack. We've extended Thumbor with 12 small plugins to meet our
needs and match our existing thumbnailing feature set. This includes
support for all the file formats in use on Commons. The Thumbor Vagrant
stack is now very close to having all the moving parts needed in
production, with basic Vagrant roles for Varnish and Swift having been
written to that end. Our objective is to finish the work on VM by the
holidays and have it ready to be showcased and discussed collectively at
the developer summit in a breakout session.
* ResourceLoader. We've written a new mw.requestIdleCallback API for
scheduling deferred tasks. We've removed usage of the msg_resource_links
DB table. We now use message config from the module registry directly.
We've migrated MessageBlobStore msg_resource DB table to an object cache
(to be deployed in January 2016): https://phabricator.wikimedia.org/T113092
## How are we doing? ##
Client-side performance has remained stable over the past month. Save Timing
has also remained stable, around the 1s median mark.
The job queue's health improved greatly after adding a new server to the
pool, with the job queue size dropping drastically and the 99th percentile
job processing time going from one day to one hour:
* https://grafana.wikimedia.org/dashboard/db/job-queue-health
There was a small scare about a sudden increase of the SpeedIndex value
across the board:
https://grafana.wikimedia.org/dashboard/db/webpagetest
But it was entirely explained by the fundraising banner, which doesn't
appear immediately on pageload. SpeedIndex measures the time it takes for
the above-the-fold area to "settle" visually. The banner appears late and
pushes the content down, which delays the time when visual changes stop
happening for the above-the-fold area.
Until next time,
Aaron, Gilles, Peter, Timo, and Ori.
If I write a [[link]] it will be blue if the page exists and red otherwise.
But if I write [[:sw:link]] that will be an external or cross-wiki link,
that is never red, as if it were impossible to know whether that page
existed in Swahili Wikipedia.
But determining the existence of a page is just a quick database table
lookup, and all databases run on WMF's servers, so it shouldn't be more
expensive to look up a cross-wiki link, as long as it is one of WMF's wikis.
In Wiktionary, it is common to link to entries in foreign languages both
on the local wiki and to the native wiki for that language. For example,
in English Wikitionary the entry for "blue" links to the Swahili word "bluu"
both on en.wiktionary and on sw.wiktionary, using the template
{{t+|sw|bluu}}.
https://en.wiktionary.org/wiki/blue#Translations
But since the Afrikaans translation "blou" doesn't have an entry on the
Afrikaans Wiktionary, another template is used: {{t|af|blou}}. And it is
a pain to know which one of these two templates to use. If it was possible
in {{#ifexists}} to determine the existence of a page in another wiki,
only one template would be needed, and the bot job to change to the right
template would not be needed.
#ifexist already works across namespaces (well, of course), so is there any
good reason it shouldn't work across wikis?
Oddly, the documentation says #ifexist is an "expensive" parser function.
That doesn't make much sense to me. It's as if red/blue links were
expensive, and most of our list pages should be banned.
https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23ifexist
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se