When api.php was basically the only API in MediaWiki, calling it "the API"
worked well. But now we've got a Parsoid API, Gabriel's work on a REST
content API, Gabriel's work on an internal storage API, and more on the
way. So just saying "the API" is getting confusing.
So let's bikeshed a reasonably short name for it that isn't something awful
like "the api.php API". I'm horrible at naming.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
On 08/07/2015 11:43 AM, Oliver Keyes wrote:
> Thank you for drafting this up, Matt. Who's "we" here?
In that case, "we" meant the Wikimedia technical community (in
collaboration with other related groups at WMF). Several people have
already participated, but we need more. See e.g.
https://phabricator.wikimedia.org/T90908
Thanks,
Matt Flaschen
Greetings, and apologies for cross posting:
The community liaisons at the Wikimedia Foundation held a roundtable
discussion at Wikimania [1] in order to gather feedback around
participation in product development. The notes are now up.[2] We welcome
input from everyone, whether you were unable to join us at Wikimania, or
whether you did attend and want to further engage in conversation.
Some major themes from this session were that places to give feedback are
confusing and unclear, there is little to no understanding of
product/engineering prioritization, and there were requests to involve and
include communities more.
The goal of this roundtable was not to get a wishlist of products and
features, but to identify problems and successes around product
development so that the WMF and communities can collaborate in better ways.
This is an ongoing conversation, and we invite your participation here [3].
Thank you so much,
Rachel
[1]
https://wikimania2015.wikimedia.org/wiki/Submissions/Do_you_feel_heard%3F_A…
[2]
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Wikimania_20…
[3]
https://meta.wikimedia.org/wiki/Talk:Community_Engagement_%28Product%29/Wik…
--
Rachel diCerbo
Director of Community Engagement (Product)
Wikimedia Foundation
Rdicerb (WMF) <https://meta.wikimedia.org/wiki/User_talk:Rdicerb_%28WMF%29>
@a_rachel <https://twitter.com/a_rachel>
TL:DR; Double-check your wiki's site scripts and your personal scripts
to ensure "document.write" is no longer used.
Hey all,
We have strongly discouraged for many years the use of synchronous
"document.write()" to inject additional HTML into the output stream.
Across MediaWiki core, extensions, and gadgets this hasn't worked since 2012.
With two legacy exceptions: the 'site' and 'user' modules. We always found a way
to continue support for those. But this is now going to be removed.
In upcoming ResourceLoader upgrades and performance improvements, we will
cease support for synchronous document-write, in the site and user modules.
Use of document-write requires MediaWiki to instruct the browser to pause its
rendering before the browser may proceed to parse and display a page to users.
Even though most scripts don't use this feature, the mere fact that we support it
is causing a measurable impact on page load performance.
Starting in 1.26wmf17 (released to wikis this week), ResourceLoader will be
fully asynchronous. This change is already live on the Beta Cluster. [1]
This means it is no longer possible for the site and user scripts to, with
document-write, pause the browser execution and insert additional HTML in
the initial output stream.
Removing an API does not necessarily mean removing a capability. If you
encounter any issues or can't find a simple upgrade path for an existing
script, please reach out on the mailing list. Below is summary of a few
typical use cases:
1. Loading scripts.
Instead of `document.write("<script src=url></script>");`
use `mw.loader.load(url);` instead.
2. Loading stylesheets.
Instead of `document.write("<link rel=stylesheet href=url/>");`
use `mw.loader.load(url, "text/css");` instead.
3. Creating elements.
Instead of `document.write("<div>....</div>");`, use:
var nodes = $.parseHTML("<div>..</div>"); $('body').append(nodes);
Or something like:
$("<div>").attr({ "id": "foo" }).appendTo("body");
Please take some time to look through your wiki's site scripts (MediaWiki:Common.js,
MediaWiki:Vector.js, etc.) and make sure document-write is no longer used.
You can also use the search engine. For example:
https://nl.wikipedia.org/w/index.php?search=document.write&ns8=1https://commons.wikimedia.org/w/index.php?search=document.write&ns8=1
Search results from mwgrep on all public wikis:
https://phabricator.wikimedia.org/P1832
Check out the migration page for other deprecations and common issues you may encounter:
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)
== Further reading ==
The ResourceLoader improvements that led to this change are tracked under
https://phabricator.wikimedia.org/T107399.
Refer to the following workboards for other tasks in this area:
https://phabricator.wikimedia.org/tag/mediawiki-resourceloader/board/?order…https://phabricator.wikimedia.org/tag/performance-team/board/?order=priority
Now that the site and user modules are primary citizens in the ResourceLoader landscape,
their states can be tracked with mw.loader. This solves long-outstanding issues such as
https://phabricator.wikimedia.org/T106736 which sometimes caused malfunctions
in Common.js to affect user gadgets, VisualEditor, and other site tools.
— Krinkle
[1] http://en.wikipedia.beta.wmflabs.org/
Hi!
So I'm just going through the latest Wikimedia Foundation quarterly
report, and I stumbled on a short passage that mentions a feature of
the mobile Wikipedia app that I really, really enjoy using.
The ability to view a link preview when clicking on an article link
inside the app is just fantastic. Not only does it save time when you
only need to quickly look up a fact, but the way that the app does it
is elegant and fast.
I'm using the alpha version of the app on an Android 5.1 smartphone,
and the report says it's also in the beta version, but I do hope it
will be added to the stable app too :-)
So, to cut a long story short: a huge thank you and please-keep-it-up
to the mobile team for implementing this handy little feature :-)
--
Tomasz
I was also at the Wikimania session where we worked on this draft. I
strongly support this effort. Best practices for codes of conduct include
clearly defined consequences for breaches, as well as named behaviors that
are unacceptable (as not everyone shares the same "common sense", and
people interested in behaving badly tend to rules-lawyer as well). Our
Phabricator etiquette is lacking both of these, and it does not cover the
rest of our technical spaces. An effective code of conduct has been shown
to be effective at bringing people from underrepresented groups--and their
contributions!--to events and projects. Screening technical contributors by
their willingness to take a risk of poor treatment is a terrible idea if we
want to get as many good contributions as we can.
-Frances
On Fri, Aug 7, 2015 at 8:43 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> Thank you for drafting this up, Matt. Who's "we" here?
>
> On 6 August 2015 at 20:19, Matthew Flaschen <mflaschen(a)wikimedia.org>
> wrote:
> > On 08/06/2015 08:17 PM, Matthew Flaschen wrote:
> >>
> >> We're in the process of developing a code of conduct for technical
> >> spaces. This will be binding, and apply to all Wikimedia-related
> >> technical spaces (including but not limited to MediaWiki.org,
> >> Phabricator, Gerrit, technical IRC channels, and Etherpad).
> >
> >
> > I forgot to mention (but this is in the draft), it also applies to
> physical
> > spaces, including but not limited to hackathons.
> >
> >
> > Matt Flaschen
> >
> >
> > _______________________________________________
> > Engineering mailing list
> > Engineering(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
>
> --
> Oliver Keyes
> Count Logula
> Wikimedia Foundation
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
This is a notice that on Monday, August 10th between 20:00-21:00 UTC
(1-2pm PDT) Wikimedia Foundation will release security updates for
current and supported branches of the MediaWiki software. Downloads
and patches will be available at that time, with the git repositories
updated
soon after.
-Chad
The idea for this was presented at Wikimania where it received a very
positive reception. Most of what I was going to say about it has already
been covered by Frances, so I'll just add that I support it as well.
On Fri, Aug 7, 2015 at 10:01 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> Excellent! I'm a strong supporter too, although I think it should be
> (as you say) very explicit about the consequences, the processes and
> the types of behaviour that are inappropriate - I'd previously added
> some commentary on the talk page that pointed to a particularly
> detailed CoC I like (it's the jQuery one; gnarf drafts good stuff).
>
> Thanks again to Matt and Frances and everyone else for kicking this
> off; this is something we desperately need.
>
> (Kudos specifically for handling Tim L's comment so nicely)
>
> On 7 August 2015 at 12:57, Frances Hocutt <fhocutt(a)wikimedia.org> wrote:
> > I was also at the Wikimania session where we worked on this draft. I
> > strongly support this effort. Best practices for codes of conduct include
> > clearly defined consequences for breaches, as well as named behaviors
> that
> > are unacceptable (as not everyone shares the same "common sense", and
> people
> > interested in behaving badly tend to rules-lawyer as well). Our
> Phabricator
> > etiquette is lacking both of these, and it does not cover the rest of our
> > technical spaces. An effective code of conduct has been shown to be
> > effective at bringing people from underrepresented groups--and their
> > contributions!--to events and projects. Screening technical contributors
> by
> > their willingness to take a risk of poor treatment is a terrible idea if
> we
> > want to get as many good contributions as we can.
> >
> > -Frances
> >
> > On Fri, Aug 7, 2015 at 8:43 AM, Oliver Keyes <okeyes(a)wikimedia.org>
> wrote:
> >>
> >> Thank you for drafting this up, Matt. Who's "we" here?
> >>
> >> On 6 August 2015 at 20:19, Matthew Flaschen <mflaschen(a)wikimedia.org>
> >> wrote:
> >> > On 08/06/2015 08:17 PM, Matthew Flaschen wrote:
> >> >>
> >> >> We're in the process of developing a code of conduct for technical
> >> >> spaces. This will be binding, and apply to all Wikimedia-related
> >> >> technical spaces (including but not limited to MediaWiki.org,
> >> >> Phabricator, Gerrit, technical IRC channels, and Etherpad).
> >> >
> >> >
> >> > I forgot to mention (but this is in the draft), it also applies to
> >> > physical
> >> > spaces, including but not limited to hackathons.
> >> >
> >> >
> >> > Matt Flaschen
> >> >
> >> >
> >> > _______________________________________________
> >> > Engineering mailing list
> >> > Engineering(a)lists.wikimedia.org
> >> > https://lists.wikimedia.org/mailman/listinfo/engineering
> >>
> >>
> >>
> >> --
> >> Oliver Keyes
> >> Count Logula
> >> Wikimedia Foundation
> >>
> >> _______________________________________________
> >> Engineering mailing list
> >> Engineering(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/engineering
> >
> >
>
>
>
> --
> Oliver Keyes
> Count Logula
> Wikimedia Foundation
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>