Wikitech-l March 2014

wikitech-l@lists.wikimedia.org

188 participants
231 discussions

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 07 Mar '14

07 Mar '14

Minutes and slides from Wednesday's quarterly review of the Foundation's Wikipedia Zero team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We'll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We're slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

Re: [Wikitech-l] [WikimediaMobile] Zurich Hackathon: Creating a map namespace
by Derk-Jan Hartman 07 Mar '14

07 Mar '14

On 8 mrt. 2014, at 00:47, Russell Nelson <russnelson(a)gmail.com> wrote: > Maps great, yes. Here's what *I* think Wikipedia needs. First and foremost, OSM is a database, just like Wikipedia articles are data (don't get me started). It's a foreign database, which means that you have the foreign key problem. Wikipedia articles all have a published unique name. Perfect for a foreign key. Articles can get moved, but in the ordinary course of editing, they don't. In OSM, the key "wikipedia" is used to make reference to a Wikipedia article. It can be the full URL, or simply the article name (latter is recommended). http://wiki.openstreetmap.org/wiki/Key:wikipedia for details. I agree, somewhat, but I think this is not 'Wikipedia' per se. It's as much a need for OSM, as it is a need for Wikipedia. And articles do get moved (as much as OSM nodes with tags on them get deleted). > Linking to OpenStreetMap entities, on the other hand, is somewhat more abstract. OSM entities (nodes, ways, and relations, all fruitful for Wikipedia linking) have a database ID. The trouble that the ID is only as persistent as the database entry, which can change through as simple a change as adding a bridge to a road (one database entry becomes three -- the original, a new short one which is the bridge, and the remainder of the road, as a new way). Probably the most persistent way to link to an entity is to give a lat/lon of a node, and give the name of the node. That is enough information to recover from any editing (if the node gets moved or deleted, there be congruent nodes nearby, and if the name is changed, you still have the node's location). Particularly if the entity has a Wikipedia article name; a bot can audit both databases against each other. > Wikipedia currently has only points in articles. At most you can say "The subject of this article is at this point." which is insufficient if the point is an area (in OSM, a self-terminating way), a way (e.g. road, railroad, river), or a relation (a collection of related ways, e.g. a lake and its islands, or a bus route). The Wikiuniverse could reinvent OSM's system for identifying places, or it could bite the bullet, lean more heavily on OSM's data, and make article references into explicit OSM references. Note that these references would not be OSM specific -- any map is going to have lat/lon and names of entities. It's just that the Wikipedia editor that helps make these links would use OSM lat/lons and names. Well first of all, we should get away from the concept of 'article'. It's really clear now that most of this data will soon live in WikiData. Coordinate values have already been added, and it's only time until most of those existing values have been moved into WikiData and there is the OSM relation ID property to link from WikiData to OSM. For entities/concepts WikiData is the only thing that will be relevant real soon. And a bot can easily detect when those break. So what you want in this regard is already in process. > Then, once Wikipedia articles can make reference to OSM objects, and you have a OSM-derived Wikimedia-hosted set of map tiles, then including a dynamic map in an article is simply a matter of a single command. And an article which is a collection of articles can make a map with references to those articles, again, with a single command. This is thinking way too simple. Would it be nice to be able to do this ? Sure, but we already have dynamic maps. WikiMiniAtlas, the german OSM map. Those even have area highlights these days. Can they be better ? sure, is that something difficult, is it really needed ? No not really x2. Wikipedians are much more focused on making static maps usually. Or rather, they often want very specific types of maps, resulting in them using custom designed static maps. These custom maps have different base layer types for different types of articles (and sometimes for different cultures cross wiki), and very simple highlights in them (less is more). Or they want to mark the spot of an event (planecrash/hurricane path etc). If we do not recognize the target group, then the integration of the feature will fail. Also, there are many problems with dynamic maps in articles (print, mobile, loadtime, fallback for users without JS). Can we do many cool things with maps ? sure. but where is the most valuable place to start ? That is a much better question I think. Personally, I think the power is in annotation. The success of FA, Commons, WikiData and OSM have shown that our users love to not just 'collect' data, but to do the curation, annotation and restoration of this data. Doing annotation using a simple OSM renderer as our starting point could be step 1. We need support for 'static' image maps to generate the buy in of people to start using this feature (step 2). With enough buy in, we can start going for the long haul, which is to build a very complex map renderer with a lot of different baselayer configurations, that might help us at some time achieve to phase out the static maps. But saying we need 'dynamic maps' is way too narrow and technical view. The other thing we could build, would be the 'foursquare' microcontributions to our mapping data (can you pinpoint this location on this OSM map, there are five locations in this area, which one best represents this article) and then with enough confirmed information set/add/correct/suggest the OSM value in wikidata again. Things like that (gamification). I think that is where we have a lot of potential. DJ > And .... here's the money shot: your location gets shown on the map. > > BTW, Special:Nearby is broken. Android phone, Chrome Browser, GPS on and locked (Ingress is happy), "Quiet out here ... there weren't any pages found nearby." Yet I could throw a stone and hit the location of a page AND my Google Glass app is happy to report that a page is very close to me. > > > On Fri, Mar 7, 2014 at 4:55 PM, Arthur Richards <arichards(a)wikimedia.org> wrote: > Somehow wikitech-l got dropped form the recipient list of this thread; I know some of the OSM folks are subscribed. Anyway, re-added wikitech-l to this thread. > > > On Fri, Mar 7, 2014 at 1:53 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: > Sounds like a good idea. If there is no objections to my potentially crazy idea I will drop them a note on their mailing list... > > On 7 Mar 2014 13:27, "Arthur Richards" <arichards(a)wikimedia.org> wrote: > Dunno if any of the OSM-y folks are planning to attend but I bet this would be up their alley. At the very least, it would probably be good to get their input on a project like this. > > > On Fri, Mar 7, 2014 at 11:44 AM, Jon Robson <jdlrobson(a)gmail.com> wrote: > Dan awesome! Glad there is some interest - this should be a lot of fun! :-) > > On Wed, Mar 5, 2014 at 1:20 PM, Quim Gil <qgil(a)wikimedia.org> wrote: > > fyi > > > > > > -------- Original Message -------- > > Subject: [WikimediaMobile] Zurich Hackathon: Creating a map namespace > > Date: Wed, 5 Mar 2014 12:54:52 -0800 > > From: Jon Robson <jdlrobson(a)gmail.com> > > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, mobile-l > > <mobile-l(a)lists.wikimedia.org> > > > > This may be extremely ambitious, but I'm keen to kick off development > > around the creation of a map namespace during the Zurich hackathon. > > > > The goal would be to setup an editable map namespace that could be > > used for a variety of things, one of which would be adding a map view > > to the Special:Nearby page provided via the mobile site. The goal is a > > proof of concept not necessarily anything production ready (but that > > would be great if we could get to that point!) > > > > Please let me know if you would also be interested on hacking such a > > thing - > > https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Geo_Namespace > > - or if doing so would be a terrible idea (but if you have to go down > > that route please provide constructive reasoning on what would be a > > less terrible idea) > > > > Excited to hack on cool things in Zurich! > > > > _______________________________________________ > > Mobile-l mailing list > > Mobile-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > > > > > > > -- > Jon Robson > * http://jonrobson.me.uk > * https://www.facebook.com/jonrobson > * @rakugojon > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > -- > Arthur Richards > Software Engineer, Mobile > [[User:Awjrichards]] > IRC: awjr > +1-415-839-6885 x6687 > > > > -- > Arthur Richards > Software Engineer, Mobile > [[User:Awjrichards]] > IRC: awjr > +1-415-839-6885 x6687 > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l

2 1

Roadmap and deployment highlights - week of March 10th
by Greg Grossmeier 07 Mar '14

07 Mar '14

Welcome to the latest edition of the Wikimedia roadmap and deployments highlights email. Full schedule at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_10th Other than the usual allotment of standing deploy windows for various teams (eg Flow, Parsoid, Search, and WP Zero) there aren't any deployments of special note. This of course doesn't take into account last minute/exceptional things. There is the normal MediaWiki train, as always. Also, the WMF Labs migration continues. For more info, see: http://lists.wikimedia.org/pipermail/labs-l/2014-February/002152.html == Tuesday == MediaWiki upgrades * group1 to 1.23wmf17: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_depl… ** https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf17 == Thursday == MediaWiki upgrades * group2 to 1.23wmf17 (all Wikipedias) * group0 to 1.23wmf18 (test/test2/testwikidata/mediawiki) ** https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf18 (branch/list of changes created on Thursday) As always, questions/comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] [WikimediaMobile] Zurich Hackathon: Creating a map namespace
by Arthur Richards 07 Mar '14

07 Mar '14

Somehow wikitech-l got dropped form the recipient list of this thread; I know some of the OSM folks are subscribed. Anyway, re-added wikitech-l to this thread. On Fri, Mar 7, 2014 at 1:53 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: > Sounds like a good idea. If there is no objections to my potentially crazy > idea I will drop them a note on their mailing list... > On 7 Mar 2014 13:27, "Arthur Richards" <arichards(a)wikimedia.org> wrote: > >> Dunno if any of the OSM-y folks are planning to attend but I bet this >> would be up their alley. At the very least, it would probably be good to >> get their input on a project like this. >> >> >> On Fri, Mar 7, 2014 at 11:44 AM, Jon Robson <jdlrobson(a)gmail.com> wrote: >> >>> Dan awesome! Glad there is some interest - this should be a lot of fun! >>> :-) >>> >>> On Wed, Mar 5, 2014 at 1:20 PM, Quim Gil <qgil(a)wikimedia.org> wrote: >>> > fyi >>> > >>> > >>> > -------- Original Message -------- >>> > Subject: [WikimediaMobile] Zurich Hackathon: Creating a map namespace >>> > Date: Wed, 5 Mar 2014 12:54:52 -0800 >>> > From: Jon Robson <jdlrobson(a)gmail.com> >>> > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, mobile-l >>> > <mobile-l(a)lists.wikimedia.org> >>> > >>> > This may be extremely ambitious, but I'm keen to kick off development >>> > around the creation of a map namespace during the Zurich hackathon. >>> > >>> > The goal would be to setup an editable map namespace that could be >>> > used for a variety of things, one of which would be adding a map view >>> > to the Special:Nearby page provided via the mobile site. The goal is a >>> > proof of concept not necessarily anything production ready (but that >>> > would be great if we could get to that point!) >>> > >>> > Please let me know if you would also be interested on hacking such a >>> > thing - >>> > >>> https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Geo_Namespace >>> > - or if doing so would be a terrible idea (but if you have to go down >>> > that route please provide constructive reasoning on what would be a >>> > less terrible idea) >>> > >>> > Excited to hack on cool things in Zurich! >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Jon Robson >>> * http://jonrobson.me.uk >>> * https://www.facebook.com/jonrobson >>> * @rakugojon >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> Mobile-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >> >> >> >> -- >> Arthur Richards >> Software Engineer, Mobile >> [[User:Awjrichards]] >> IRC: awjr >> +1-415-839-6885 x6687 >> > -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

1 0

Merging near deployment branch cut time
by Jon Robson 07 Mar '14

07 Mar '14

Let's also take this into a new thread. There are a lot of different conversations now going on.... On Fri, Mar 7, 2014 at 9:21 AM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org> wrote: > On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian <cananian(a)wikimedia.org>wrote: > >> I agree. I think a better technical solution would be to halt jenkins' >> auto-merge for the 24 hour period, so that +2'ed changes are not >> automatically merged until after the branch is cut. > > > I don't see how that's any better. Things still aren't getting merged. > > If anything, the "cut using master@{24 hours ago}" is a much better > idea.[1] Although it might be useful to see if Wednesday tends to be a > relatively active bug-fixing day as the community on non-Wikipedia sites > finds issues in the version that was deployed to them on Tuesday, in which > case keeping those from making it into the new cut on Thursday (and so > requiring more backports or waiting an extra week for fixes) might not be > so great. > > > [1]: And yes, 'master@{24 hours ago}' is valid git syntax. > > -- > Brad Jorsch (Anomie) > Software Engineer > Wikimedia Foundation > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

5 5

Memento Extension for MediaWiki: Quick Question About Hooks
by Shawn Jones 07 Mar '14

07 Mar '14

Hi, Thanks last year for the assistance in correcting some programming issues with the Memento Extension. We've been conducting performance testing in the interim and have been addressing issues as they've been discovered. For the most part, we've been pleased with the results, mostly due to feedback from this group. The extension looks for the presence of an 'Accept-Datetime' header in the HTTP request and, if present, constructs a 302 HTTP response redirecting the visitor to the closest, but not over, oldid page to the time they've requested. Currently the extension starts its processing using the ArticleViewHeader hook. If we are going to construct a 302 response because an 'Accept-Datetime' header was detected, then it appears that some of the data loaded never gets used, wasting processing time. Is there an earlier hook in the page rendering process that can provide the name (title) of the page being requested and an OutputPage object so we can look at the request and construct the response? We are avoiding all globals, like $wgOut, to comply with MediaWiki coding standards. Thanks in advance, Shawn M. Jones Graduate Research Assistant Department of Computer Science Old Dominion University

1 0

Language Engineering IRC Office Hour on March 12, 2014 (Wednesday) at 1700 UTC
by Runa Bhattacharjee 07 Mar '14

07 Mar '14

[x-posted] Hello, The Wikimedia Language Engineering team will be hosting the monthly IRC office hour on March 12, 2014 (Wednesday) at 1700 UTC/ 1000 PDT on #wikimedia-office. In this edition, we will be talking about our ongoing projects, like the Content Translation tool[1]. Also, we would like to extend this invitation specially to the students who are looking forward to participate in Google Summer of Code (GSoC) 2014 and Outreach Program for Women (OPW) - Round 8, for the Language Engineering projects[2] under Wikimedia. We will be happy to answer your questions about our work and projects. Please see below for the event details and check for local time at your location. Questions can also be sent to me before the event. See you all at the IRC office hour! Thanks Runa [1] https://www.mediawiki.org/wiki/Content_translation [2] https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Intern… Event Details: ========== # Date: March 12, 2014 # Time: 1700-1800 UTC, 1000-1100 PDT (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T1700) # IRC channel: #wikimedia-office on irc.freenode.net Agenda: ====== 1. Ongoing Projects - Content Translation tool 2. GSoC and OPW - open house for Language Engineering projects 3. Q & A -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

Should MediaWiki CSS prefer non-free fonts?
by Brad Jorsch (Anomie) 07 Mar '14

07 Mar '14

I came across Gerrit change 79948[1] today, which makes "VectorBeta" use a pile of non-free fonts (with one free font thrown in at the end as a sop). Is this really the direction we want to go, considering that in many other areas we prefer to use free software whenever we can? Looking around a bit, I see this has been discussed in some "back corners"[2][3] (no offense intended), but not on this list and I don't see any place where free versus non-free was actually discussed rather than being brought up and then seemingly ignored. In case it helps, I did some searching through mediawiki/core and WMF-deployed extensions for font-family directives containing non-free fonts. The results are at https://www.mediawiki.org/wiki/User:Anomie/font-family (use of non-staff account intentional). [1]: https://gerrit.wikimedia.org/r/#/c/79948 [2]: https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#… [3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394

36 93

Notifying people when integration tests
by Jon Robson 07 Mar '14

07 Mar '14

This looks like a good time to fork this conversation as this is a good problem to fix. How can we notify developers when they break other things in the stack and how? On 7 Mar 2014 05:36, "Bartosz Dziewoński" <matma.rex(a)gmail.com> wrote: > (continued, about the browser testing) > > (tl;dr where are the tests and how do I know they fail?) > > So, we have some slick browser tests. Awesome! But what's not good is > that the tests run off-site, the results are not reported back to > gerrit nor Bugzilla (unless someone manually files a bug, usually > Chris) not IRC nor anywhere else, and are generally non-discoverable > until someone shouts at you for breaking them. (As Tim guessed, I did > not know about any failures until Jon told me.) > > In fact, I still have no idea what exactly the tests encompass (I've > heard about some browser tests for VE because I lurk a lot, never > heard of any for core) or where to find them or how to run them. > Either I'm slow or we have a serious documentation failure here. > > Can something be done about it? Can we have the results reported > somewhere visible – preferably to gerrit, as jenkins already reports > some post-merge checks there? Or maybe we can have automatically filed > bug reports if the build breaks? A bot reporting test status on > #wikimedia-dev? Anything? > > (I understand that the tests take too long to run them in the > pre-merge checks.) > > (Jon proposed reverting problematic changes outright, but to me that > seems like a bit of an overreaction – bugs in tests and false > positives happen, let's not make a huge fuss out of that.) > > (to be continued: about the deployment) > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

MediaWiki unit tests being run via HHVM!
by Antoine Musso 07 Mar '14

07 Mar '14

Hello, I have added a job in Jenkins which runs the Mediawiki core PHPUnit test suite using the Facebook HipHop virtual machine. The job is now being run along other testing jobs. It is slightly slower (4 min 30s) than the other jobs so that would delay the reporting back to Gerrit by roughly a minute. I have made the job to timeout after 8 minutes to avoid unnecessarily blocking changes. hhmv is installed on some labs instance and is using the version in our apt repository (thought not automatically upgraded 'ensure => present'). The job page: https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-hhvm/ It is very experimental, one of the build segfaulted: https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-hhvm/2/ Another one has one failing test: https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-hhvm/3/test… DjVuTest::testPageCount Object of class UnregisteredLocalFile could not be converted to string That one probably need some code to be fixed. Culprit: the install.php and update.php scripts are still using php. Reference: ---------- Bug 62278 "write a jenkins job to use hhvm for mwcore https://bugzilla.wikimedia.org/show_bug.cgi?id=62278 -- Antoine "hashar" Musso

2 2

← Newer
1
...
16
17
18
19
20
21
22
23
24
Older →

Jump to page:

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 March 2014