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
Google Code-in 2015 will start today and run for seven weeks:
https://www.mediawiki.org/wiki/Google_Code-in_2015
Many young students will make their first contributions to Wikimedia
hence there will be lots of questions on IRC and mailing lists.
Your help (and patience) is welcome to answer them and provide a
helping hand to an onboarding newcomer.
Thanks to all mentors who have registered & provided some tasks!
You have not become a mentor yet? Consider it - it's fun!
* Think of easy tasks in your area that you could mentor.
Areas are: Code, docs/training, outreach/research, quality
assurance, and user interface. "Easy" means 2-3h to complete for
you, or less technical ~30min "beginner tasks" for onboarding).
* OR: provide one easy clonable task (a type of task that is
generic and could be repeated many times by different students.
* Note that you commit to answer to students' questions and to
evaluate their work within 36 hours (but the better your task
description the less questions. No worries, we're there to help!)
For the full info, please check out
https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner
and don't hesitate to ask questions if something is unclear!
Thank you again for giving young contributors the opportunity to learn
about and work on Free and Open Source Software projects!
Cheers,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
I noticed that since we enforce SSL on Wikipedia for everyone,
Wikipedia is much more restricted in some countries, such as China,
where it's entirely blocked (I think only SSL is blocked, but users
now have no option to fall back to non-ssl version).
Is there some non-ssl mirror for people in these countries? Or did we
just gave up on "free knowledge for everyone"?