Wikitech-l September 2014

wikitech-l@lists.wikimedia.org

129 participants
123 discussions

Jeff Hobson joins the Wikipedia Zero Engineering Team
by Tomasz Finc 15 Sep '14

15 Sep '14

Greetings All, I'm very happy to welcome Jeff Hobson to the Wikimedia Foundation and the Wikipedia Zero Engineering team. He'll be joining Yuri, Adam, and Dan Foy to continue the great work that the Zero team has been working on and focusing on building our carrier portal first. Today will be his first day. Jeff will be working remotely from Blacksburg, VA, but hopes to eventually venture out to the west coast to join us locally. Jeff has been building websites for over 12 of his 22 years and practically weeped tears of joy when HTML5 was first released. Aside from web development, he's dabbled in Parallel Computing, AI, and even some robotics. But the ever-changing nature of web development has kept him coming back and he's excited to join WMF to work with all the challenges mobile brings. In his free time Jeff enjoys skiing, riding roller coasters, speed running, and playing the drums. Please join me in welcoming Jeff --tomasz

1 0

JuryTool
by Oscar Costero 15 Sep '14

15 Sep '14

Hi all, We're having a little problem to manage the jury tool app and I was wondering if someone else besides David Narvaez have the know-how to help us? This problem is not related with WLM, we're working with another contest. Kind Regards, -- Oscar Costero (+58) 0412-9161792 Presidente | Wikimedia Venezuela J-40129321-2 http://wikimedia.org.ve <http://wikimedia.org.ve/index.php/P%C3%A1gina_principal> | @wikimedia_ve <http://twitter.com/wikimedia_ve>

2 1

Re: [Wikitech-l] want to pair program more often?
by Jaime Schatz 15 Sep '14

15 Sep '14

Sumana, this is awesome! o/ In case you're keeping track, I'm at the n00b end of the experience spectrum. :D

1 0

Upstream gerrit fixed: Bug 35534 - Free-form tagging
by Federico Leva (Nemo) 15 Sep '14

15 Sep '14

!!! https://bugzilla.wikimedia.org/show_bug.cgi?id=35534#c19 Nemo

5 5

Re: [Wikitech-l] [Wikitech-ambassadors] Roadmap and deployment highlights - week of Sept 15th
by Greg Grossmeier 15 Sep '14

15 Sep '14

cc'ing wikitech-l for your questions to get answers direct from the source instead of me playing telephone :) <quote name="billinghurst" date="2014-09-16" time="00:53:18 +1000"> > Thanks Greg. There was nothing mentioned in today's Tech news, so I have > just appended some information to enWS. At the WSes we load some big > transcluded pages and I have set a little challenge for users to make some > comparisons. Are you going to be running data comparisons? Is this > something that user (anecdotal) semi-quantitative data is of value? If > yes, to the last point, what sort of direct data comparison might be of > value? > > Regards, Billinghurst > > On Fri, 12 Sep 2014 17:42:14 -0700, Greg Grossmeier <greg(a)wikimedia.org> > wrote: > > <quote name="billinghurst" date="2014-09-13" time="09:38:47 +1000"> > >> > * There will be a method to opt-in to using the new HHVM-powered > >> > backend > >> > for all WMF wikis. It'll be implemented via a BetaFeature to make > it > >> > as easy as possible for people to participate. There should be no > >> > noticeable negative impact and hopefully only positive impacts. > >> > > >> Greg, > >> > >> The last dot point. Is it there against Thursday 18th? Is it to mark it > >> against another point? The HHVM component sits against next month on > the > >> deployment page, so the uncertainty. > > > > To answer all of your questions I'll try to rephrase things in a > > different manner and add some more details. It might be a little too > > detailed at first, I'll try to tl;dr at the end: > > > > HHVM is a virtual machine for PHP which improves the performance of the > > servers by... a lot. We're a little shy of sharing predictions of how > > improved the performance will be, but it'll be worth the effort. > > > > Thus far HHVM has been deployed to the Beta Cluster, which is our > > testing environment based in WMF Labs. It has been running there for > > about a month so far. > > > > Along side that we have a few servers in the production cluster that > > have been migrated to HHVM. These servers are only sent user traffic if > > and only if the user sets a cookie in their browser. > > > > In addition to that there are safe-guards in place where if a request to > > an HHVM server fails, our Varnish layer will take note of that and > > resend requests to a normal (non-HHVM) server. > > > > The confusion you have regarding HHVM being in the "Next Month" section > > is because this work is on-going. There were more bullets in that list > > initially and we will work through them as we get closer to the full > > rollout/completion. > > > > What is happening next week is this: There will be a new Beta Feature > > available to all users that will allow them to opt-in to using the HHVM > > servers by default (the Beta Feature simply sets the cookie I mentioned > > above). That will happen on Thursday after the normal MediaWiki deploy. > > > > If things go well, users who opt-in will have a better experience: pages > > should load faster and edits should save faster, for example. > > > > If things don't go well, users who opt-in shouldn't see anything worse > > than normal (given that safe-guard I mentioned above in the Varnish > > layer). > > > > tl;dr: > > > > HHVM, an improved (faster) php server, is in the process of being tested > > at scale and rolled out. We are still at the beginning stages but we > > feel comfortable enough with the stability we've gained in the Beta > > Cluster to open it up to more users through a Beta Feature. This Beta > > Feature will be available for all users on Thursday afternoon (Pacific > > timezone). Users who opt-in should have a faster wiki experience and in > > the worst case will not see anything different than normal. > > > > I hope that helps. If you have any more questions please don't hesitate > > to reply and cc wikitech-l, where the experts on the matter can answer > > more questions. > > > > Best, > > > > Greg > > _______________________________________________ > Wikitech-ambassadors mailing list > Wikitech-ambassadors(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

want to pair program more often?
by Sumana Harihareswara 15 Sep '14

15 Sep '14

You should probably pair program more often. Here's why. 1) learning Every single time I've pair programmed with someone, one of us has learned stuff. About our tools, about a new way to look at a problem, about a language feature, or something. Sometimes I've paired explicitly as a teaching or learning technique, sometimes on more equal footing ("I'm the domain expert for the problem but you're better at $framework than I am"), or just to brainstorm or troubleshoot. At least one of us always comes out smarter. 2) the tools are better than ever https://lists.wikimedia.org/pipermail/teampractices/2014-July/thread.html has some resources; don't dismiss pair programming just because you don't live near other programmers. 3) pairing makes better code "Pair Programming" by Laurie Williams (Ch. 17 in _Making Software: What Really Works, and Why We Believe It_, ed. Andy Oram & Greg Wilson, O'Reilly 2011) reviews recent studies and finds that pair programming leads to higher-quality code, and "reduced product risk due to improved knowledge management". Some teams even tried pair programming as a replacement for code review. 4) it's more egalitarian As this list of status play behaviors points out https://web.archive.org/web/20070216200742/http://greenlightwiki.com/improv… , judging someone else's work -- even favorably! -- is a move that raises your status and lowers theirs. This is one reason I have encouraged EVERYONE who writes MediaWiki code to try their hand at code review, so everyone can take turns -- everyone can be a teacher and critic.[0] If you have found that code review feels adversarial or hierarchical, try switching it up by asking to pair with a more experienced programmer, getting your code review while you work together. People who want to pair program more often on Wikimedia-related code: want to use this thread to raise your hand? If people like the idea, we could start doing something like http://www.pairprogramwith.me/ or http://pear.growstuff.org/ to connect people up. Sumana Harihareswara Senior Technical Writer Wikimedia Foundation [0] By the way, this great blog post http://www.wordyard.com/2014/08/10/doing-is-knowing-sweet-jane-and-the-web/ makes a very strong point about how trying out an activity - like writing, music, or coding - gives you more expertise, empathy, and ability to define yourself, and to judge the work of other people who do that activity. I would argue this applies to code review as well.

1 0

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

14 Sep '14

1 0

Sudden growth of unreviewed changesets in Gerrit
by Quim Gil 14 Sep '14

14 Sep '14

Hi, our metrics are reflecting a sudden growth of unreviewed changes in Gerrit. Your attention and interpretations are welcome. http://korma.wmflabs.org/browser/gerrit_review_queue.html Look at the green line in the first graph, "Volume of open changesets". It shows the number of open changesets waiting for a review (WIP and -1 are excluded). In the last months, the number of changesets waiting for review has gone from 311 (June) to 529 (July) and 790 (August). The increase is so high that first I thought the problem was in the metric, but Alvaro has reviewed the raw data and says that the metric is legit. https://bugzilla.wikimedia.org/show_bug.cgi?id=70278 Trying to find an explanation, I went to the MediaWiki Core repository, and there are some inusual curves there as well: http://korma.wmflabs.org/browser/repository.html?repository=gerrit.wikimedi… However, not even these numbers alone would explain the increase. Has there been an unusual activity (or lack of reviews) in Gerrit or are we missing an important detail in the metrics? (pause) In any case, in the past weeks I have been chasing old open reviews and in general I get the impression that developers/maintainers are too busy to review so many contributions. The tricky part is that many (most?) of those contributions come from the same developers/maintainers... Simplifying a lot the picture, it looks as if we can't review code because we are busy writing code that won't be reviewed because we are busy writing code that won't be reviewed because... I'm sure this representation is unfair, but you get the point. In many cases, unreviewed patches rotting mean real resources put into waste -- right? Maybe teams should prioritize the attention to open changesets at the expense of writing new code themselves? It's a real question and I won't pretend to have an answer. Different teams and repositories probably have different answers. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

8 11

Roadmap and deployment highlights - week of Sept 15th
by Greg Grossmeier 14 Sep '14

14 Sep '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_September_15th> A quick list of notable items... == Monday == * Revert Wikidata to a known-good version due to issues that were found on Thursday's deploy * Update CentralNotice to remove dependency on jquery.json ** <https://gerrit.wikimedia.org/r/158103> * Japanese Wikipedia to get Cirrus Search as the primary search experience == Tuesday == * Commons to will get the new CirrusSearch as the primary search engine * MediaWiki deploy ** group1 to 1.24wmf21: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf21> == Wednesday == * Russian Wikipedia to get Cirrus Search as the primary search experience == Thursday == * MediaWiki deploy ** group2 to 1.24wmf21 (all Wikipedias) ** group0 to 1.24wmf22 (test/test2/testwikidata/mediawiki) * There will be a method to opt-in to using the new HHVM-powered backend for all WMF wikis. It'll be implemented via a BetaFeature to make it as easy as possible for people to participate. There should be no noticeable negative impact and hopefully only positive impacts. 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 |

2 2

FOSS Outreach Program for Women round 9
by Quim Gil 12 Sep '14

12 Sep '14

FOSS Outreach Program for Women round 9 will be announced officially today by the GNOME Foundation. Wikimedia will participate again, and our landing page is located at https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9 If you have a project proposal with two mentors and community consensus, then you can add it under "Featured project ideas" here: https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Featur… Transclusion magic will do the rest. On the other hand, if you proposed one of the projects featured in the previous OPW and GSoC round and for some reason you don't want to push it now, please remove it. You can either move it under the Raw section (if you want to bring it back next year) or remove it completely from the page. Questions? Just ask. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

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