Wikitech-l July 2014

144 participants
154 discussions

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 28 Jul '14

28 Jul '14

1 0

Re: [Wikitech-l] [Wikitech-ambassadors] wikis using badges
by Ricordisamoa 27 Jul '14

27 Jul '14

Il 17/07/2014 16:43, Lydia Pintscher ha scritto: > Hey :) > > Wikidata will soon be able to also maintain article badges like "good > article" and "featured article". I am very happy that we won't use {{Link FA}} anymore, but I'm very skeptical about storing that information on Wikidata. As I previously wrote on the bug page, the page quality rank does not actually pertain to sitelinks. I renew my proposal of an extension to store a quality rank of a page on the client wiki itself, in a structured format that would also be made available to sister projects and to the Wikibase repository. Keeping them on Wikidata would increase redundancy with the client sites, and surely some bots would have to periodically update badges on the repo. Even if I noticed your hard work on badges, I strongly believe that they shouldn't be used for FA/GAs.

1 0

Feedback for mediawiki api development course on codecademy.
by Diwanshi Pandey 26 Jul '14

26 Jul '14

Hello everyone, I am Diwanshi Pandey, an OPW intern. I'd like to have your feedback on the course I have created on codecademy for mediawiki api with help of my mentor Yuri Astrakhan. A little insight: The course is about parsing and querying mediawiki api. Initially we created one course which included 44 exercises but according to codecademy's guidelines their course are for beginners and should have maximum 30 exercises in one course. So we did a split up into two courses: One is Introduction to Wikipedia API<http://www.codecademy.com/courses/web-beginner-en-vj9nh/0/1>and other is Wikipedia:Query API <http://www.codecademy.com/courses/web-beginner-en-yd3lp/0/1>. Also due to api security and restrictions we couldn't implement tutorial on "editing wiki pages through api call" from a non wiki site yet. We are waiting till we find a good and easy way to demo that. Feedback may include: * Are the exercises easy to understand for novice users/developers? * Are changes needed in the look of exercises? * Are there any exercises which need not to be implemented or in too depth? * Any other thing? Thanks, -- *Regards,* *Diwanshi Pandey*

4 8

Fwd: Please welcome Kristen Lans, ScrumMaster
by Arthur Richards 26 Jul '14

26 Jul '14

Hi everyone, I'm very pleased to welcome Kirsten Lans to the Wikimedia Foundation, as the first ScrumMaster [1][2] hire into the newly formed Team Practices Group [3]. Kristen will be taking over ScrumMaster duties for the Mobile Web and Mobile Apps Engineering teams. Prior to joining WMF, Kristen worked for six years with the TED prize-winning Encyclopedia of Life project [4], a free, open resource that aims to provide access to knowledge about all life on Earth. Kristen helped to pilot and facilitate the Encyclopedia of Life organization's agile development and planning processes, and enjoyed working with the project's global community of contributors. Kristen is thrilled to be continuing to work towards open knowledge sharing for all at an even larger scale. Kristen currently lives in Cape Cod, Massachusetts with her husband and dog, and is planning to relocate to the Bay Area by the end of the year, and is looking forward to eating her way through the San Francisco's tasty restaurants and taking advantage of the amazing outdoor activities in the area. [1] https://en.wikipedia.org/wiki/ScrumMaster#Scrum_Master [2] https://www.mediawiki.org/wiki/Wikimedia_Mobile_engineering/imported/Mobile… [3] https://www.mediawiki.org/wiki/Wikimedia_Engineering/Team_Practices_Group [4] http://eol.org -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

4 4

Managing external dependencies for MediaWiki core
by Daniel Kinzler 26 Jul '14

26 Jul '14

This is about whether it's OK for MediaWiki core to depend on other PHP libraries, and how to manage such dependencies. Background: A while back, I proposed a simple class for assertions to be added to core[1]. It was then suggested[2] that this could be placed in a separate component, which could then be re-used by others via composer. Since the assertions are very little code and nicely self-contained, this should be easy to do. However, if we want to use these in MediaWiki core, core would now depend on the assertion component. That means that either MediaWiki would require installation via Composer, or we have to bundle the library in some other way. What's the best practice for this kind of thing? Shall we just make the assertion repo an git submodule, and then pull and bundle it when making tarball releases? Should we switch the generation of tarballs to using composer? Or should we require composer based installs in the future? Are there other options? Cheers, Daniel [1] https://www.mediawiki.org/wiki/Requests_for_comment/Assert [2] https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Assert#Use_outside…

3 2

Roadmap and deployment highlights - week of July 28th
by Greg Grossmeier 26 Jul '14

26 Jul '14

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 |

1 0

RE:Call for Wikimedia Hackathon(s) 2014-2015
by Pep Adrian 25 Jul '14

25 Jul '14

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

3 2

Anyone going to WikiMania?
by Mark Clements (HappyDog) 25 Jul '14

25 Jul '14

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

9 9

Sysadmin appreciation day
by Sumana Harihareswara 25 Jul '14

25 Jul '14

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 https://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

2 1

Please comment: Using factory functions for component instantiation
by Daniel Kinzler 25 Jul '14

25 Jul '14

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.

1 0

← Newer
1
2
3
4
5
6
7
8
...
16
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2014