Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_July_28th>
A quick list of notable items...
== Early next week ==
* The new PDF rendering engine will be enabled on production wikis as an
optional (non-default) method of creating PDFs.
** This should probably happen on either Monday or Tuesday.
== Monday ==
* Wikitech wiki
** The OAuth extension will be installed on
<https://wikitech.wikimedia.org>. No downtime expected.
== Tuesday ==
* MediaWiki deploy
** group1 to 1.24wmf15: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf15>
== Wednesday ==
* Weekly fundraising banner test
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf15 (all Wikipedias)
** group0 to 1.24wmf16 (test/test2/testwikidata/mediawiki)
*** Includes the Thumbnail style update work -
<https://www.mediawiki.org/wiki/Thumbnail_style_update>
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Thanks everyone for their time yesterday. It was a really useful sesion to
solve some of our main doubts regarding the organization.
I missed some parts due to bad network connection but did someone ask for a
detailed budget of previous hackathons? (Zurich & Amsterdam) This will be
very useful to prepare our proposal. Are they available online?
Thanks again!
Pep
Hi there,
As it's on my doorstep, I've got myself tickets to WikiMania 2014, including
the hackathon.
I've never been to a hackathon before! What should I expect? Are any of
you guys coming?
- Mark Clements
HappyDog
Today is the last Friday in July, so it's Sysadmin Appreciation Day.
I thank all the people who have built and maintained Wikimedia's technical
infrastructure since 2001 - volunteers, staff, and in between. :) I won't
spam you too much with a repeat of my note from last year
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070791.html .
But I will repeat that Wikimedia Foundation's Ops staff is under "Technical
Operations" in "Engineering and Product Development" on the staff page[1]
in case you want to recognize them and buy them refreshing beverages at
Wikimania. :) https://wikimediafoundation.org/wiki/Staff?showall=1
The site is up. This is the ur-priority, the fact that everything else in
Wikimedia-world depends on. Too often we only notice when the site is down.
Today we notice that it's up, that it's nearly always up, and that it keeps
getting better, and that this takes work and we should appreciate that.
If you want to be someone we appreciate next year, you can always learn. :)
http://ops-school.readthedocs.org/en/latest/ is one place to start.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
MediaWiki offers several extension interfaces based on registering classes to be
used for a specific purpose, e.g. custom actions, special pages, api modules,
etc. The problem with this approach is that the signature of the constructor has
to be known to the framework, preventing us from moving
away from global state towards using proper dependency injection via the
constructor.
The alternative is to allow factory functions[1] to be registered instead of (or
in addition to) class names. This is already supported for actions and config
handlers, and I have now submitted a patch to also allow this for api modules
<https://gerrit.wikimedia.org/r/#/c/149183/>.
If this is accepted, I plan to do the same for special pages. Please have a look
and comment.
Let me give an example of why this is useful:
For example, if we want to define a new api module ApiFoo which uses a DAO
interface called FooLookup implemented by SqlFooLookup, we would have to use
global state to get the instance of SqlFooLookup:
class ApiFoo extends ApiBase {
public function __construct( ApiMain $main, $name ) {
parent::__construct( $main, $name );
$this->lookup = SqlFooLookup::singleton();
}
...
}
...
$wgAPIMOdules['foo'] = 'ApiFoo';
The API module would be bound to a global singleton, which makes testing and
re-use a lot harder, and constitutes a hidden dependency. There is no way to
control what implementation FooLookup is used, and the class can't operate
without the SqlFooLookup singleton being there.
If however we control the instantiation, we can use proper dependency injection:
class ApiFoo extends ApiBase {
public function __construct( FooLookup $lookup, ApiMain $main, $name ) {
parent::__construct( $main, $name );
$this->lookup = $lookup;
}
...
}
...
$wgAPIMOdules['foo'] = array(
'class' => 'ApiFoo', // This information is still needed!
'factory' => function( ApiMain $main, $name ) {
$lookup = SqlFooLookup::singleton();
return new ApiFoo( $lookup, main, $name );
}
);
Now, the dependency is controlled by the code that registers the API module (the
bootstrap code), ApiFoo no longer knows anything about SqlFooLookup, and can
easily be tested and re-used with different implementations of FooLookup.
Essentially it means that we have less dependencies between implementations, and
split the construction of the network of service objects from the actual logic
of the individual components.
Do you agree that this is a good approach? Do you see any problems with it?
Perhaps we can discuss this some more at Wikimania (I assume there will be an
architecture session there).
Cheers,
Daniel
[1] We could also register factory objects instead of factory functions,
following the abstract factory pattern. The main advantage of this pattern is
type safety: the factory objects can be checked against an interface, while we
have to just trust the factory functions to have the right signature. However,
even with type hinting, PHP does not do type checks on return values, so we
never know what the factory actually returns. Overall, individual factory
objects seem a lot of overhead for very little benefit. See also the discussion
on I5a5857fcfa075.
Forwarding for the benefit of those not on Wikimedia-l or Wikimedia-
announce.
Pine
On Jul 24, 2014 5:52 PM, "Erik Moeller" <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> It’s my great pleasure to announce Arthur Richards as Team Practices
> Manager for WMF. Arthur will lead a group of ScrumMasters and coaches
> to scale up our ability to support teams in developing robust
> processes for software delivery. In this new role, Arthur will report
> to the VP of Engineering (currently, me).
>
> Arthur’s first engagement in this role will be with the MediaWiki core
> team in October. He’s also still transitioning responsibilities for
> the mobile web team to Kristen Lans, who just joined WMF as
> ScrumMaster. I am very excited about the work ahead. Please join me in
> congratulating Arthur and wishing him success in this new role. :-)
>
> What follows is some more background about this new group and about
> Arthur’s leadership in case you’re interested (long):
>
> Arthur joined WMF in June 2010 [1] to support fundraising tech. In the
> context of team process pains, this team was the first one to adopt an
> agile development process (specifically, Scrum), and Arthur was in the
> middle of it all. He took this experience with him when he joined the
> mobile development team under Tomasz Finc in 2012. The mobile team,
> too, would soon adopt Scrum, and Arthur took on the role of
> ScrumMaster later that year to be the "process owner" for the team.
>
> What does that actually mean? It means facilitating the "rituals" that
> are part of an agile team’s work (e.g. the daily stand-ups, the sprint
> planning meetings, retrospectives, etc.) and continually facilitating
> the team’s discovery of improving the way they work. Say it turns out
> week after week that the team is introducing preventable regressions
> -- in a situation like this, the ScrumMaster will work with the team
> to better understand what’s going on and work towards a solution
> (e.g. collaboration with QA, improved test coverage, etc.).
>
> In my experience, every team benefits from process improvement, and
> the highest performing ones view this as a continuous part of the
> team’s work. Arthur embodies this and I've long viewed the mobile web
> team as the canonical example in our org that illustrates the benefits
> of agile development done right.
>
> Throughout his experience as ScrumMaster, Arthur has always made a
> point of emphasizing the spirit of agile (continued iteration and
> improvement, problem solving from the bottom up) rather than sticking
> dogmatically to a specific methodology. He’s also led the development
> of new processes in the organization that reduce siloed development
> and improve coordination, e.g. the Scrum of Scrums.
>
> Through most of this time we relied on external consultants to get
> other teams up to speed on agile development practices. While this has
> worked reasonably well, the ever-changing personal relationships (a
> new consultant for every project) and the lack of institutional memory
> has meant that it was hard to customize and scale the process to our
> needs.
>
> When we spun up the Flow team last year, we had to make a decision:
> Will we continue to rely on external consultants, or will we start
> building internal capacity for this? We decided to experiment with the
> latter, and Arthur Richards and Tomasz Finc led a one-time agile
> workshop with the team which was universally well-received and didn't
> suffer from some of the false starts of consultant engagements.
>
> So, in the budget planning cycle this year Tomasz and Arthur made a
> pitch to formalize this function in the organization: the Team
> Practices Group [2]. Given his experience, Arthur is perfectly
> positioned to lead this group. He’s demonstrated level-headedness,
> patience, and openness that you want from a coach, guiding teams
> gently and always focusing on improvements that will be carried
> forward by the team as a whole.
>
> After consulting with multiple teams who were hungry for more support
> (e.g. a full-time ScrumMaster, or just agile process support), we
> decided that Arthur would initially bring on two full-time staffers.
>
> It’s already become clear that this won’t be sufficient. For example,
> Analytics is expressing a strong need for a full-time ScrumMaster to
> support the growing team so that developers can focus on development.
> Whether this is always the right answer remains to be seen. Arthur
> will work with teams to find a good balance between custom tailored
> solutions and process consistency for the org.
>
> Ultimately, this new group’s function will be similar to what in
> traditional organizational models would be a "Project Management
> Office" - except that, instead of having a group of Project Managers
> assign work, we want to facilitate self-organizing and increasingly
> fluid teams coming up with a process that works for them.
>
> We draw lots of inspiration from other orgs (e.g. Spotify’s seminal
> Scaling Agile paper [3]) but also need to account for the unique
> requirements of our org (transparency, commitment to open source,
> etc.).
>
> Working with Arthur is a privilege and a pleasure, and I’m thrilled
> that he’s agreed to take on this new role. If you're interested in
> being part of the ongoing conversation about process improvements, we
> have the public teampractices mailing [4] list for this purpose.
>
> Warmly,
>
> Erik
>
> [1]
> http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2010-June/000027.h…
> [2]
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/Team_Practices_Group
> [3]
> https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
> [4] https://lists.wikimedia.org/mailman/listinfo/teampractices
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Please note: all replies sent to this mailing list will be immediately
> directed to Wikimedia-l, the public mailing list of the Wikimedia
> community. For more information about Wikimedia-l:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> _______________________________________________
> WikimediaAnnounce-l mailing list
> WikimediaAnnounce-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
>
Hi should we upgrade jquery ui to version 1.10.4. even though we recently upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The main difference is it removes internet explorer 6 support which as long as internet explorer 6 users can edit and view the page it wont matter to them. here is the changelog jqueryui.com/changelog/1.10.0/
Hello everybody,
I'm trying to figure out the best method for internationalization/localization of MediaWiki Gadgets. There are several approaches implemented in the different available gadgets, but none of them seem to use MediaWikis client side message system. I want to use something like
mw.message('my-gadget-some-key').plain();
But this only works with message keys that are available on the client side, based on the 'messages' field of a server side module definition ($wgResourceModules). The clientside
mw.loader.implement( moduleName, scripts, styles, messages );
has a parameter for a 'messages' config object. But it does not load the translation texts for the keys automatically. Actually it expects a JavaScript object that contains keys _and_ values [1]. I've tried whether the values get overridden when a translation on the MediaWiki-namespace is available, but they don't seem to. Am I missing something important? Can you recommend a method for I18N in a gadget?
Just for the record: I've been experimenting with keeping the messages in subpages ("MediaWiki:Gadget.-/de.js") in JSON format [2] and loading them on runtime via AJAX [3]. I think this has some beauty because it's close to what MediaWiki does on the server side. Unfortunately in this case I'll have to implement a language fallback [4] by myself. Any thoughts or hints?
[1] https://www.mediawiki.org/wiki/ResourceLoader/Features#Response
[2] https://www.mediawiki.org/w/index.php?title=User%3AOsnard%2FGadget-Test%2Fd…
[3] https://www.mediawiki.org/wiki/User:Osnard/Gadget-Test.js
[4] https://www.mediawiki.org/wiki/Localisation#mediaviewer/File:MediaWiki_fall…
--
Robert Vogel
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
Residenzstraße 2
93047 Regensburg
Tel. +49 (0) 941 - 66 0 80-198
Fax +49 (0) 941 - 66 0 80-189
www.hallowelt.biz
vogel(a)hallowelt.biz
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
