Re: [Wikitech-l] [Design] Design statement of purpose reviewed

[Arthur Richards]

Thank you Pau, and to all of the folks involved in the process. In addition
to the UX designers, design researchers, UX engineers, and brand folks in
communications, the Team Practices Group and Community Liaisons were
intimately involved. Internal stakeholders and folks from the broader
community played instrumental roles as well.

Defining the statement of purpose was a truly collaborative process. It's
been awesome to see it all unfold and it's great to see such a clear final
product.

Having jointly developed a shared understanding of the purpose of design
within the design group and between the design group and their stakeholders
may seem simple - and it is, as Pau articulated, by design (pun intended) -
but going through a process like this is never easy. In addition to the
increased and shared clarity around what design at the WMF is trying to
achieve at a big-picture level, this document can and will serve as a
useful tool in many different levels of decision making - from day-to-day
team-level and product decisions, to big and challenging strategic
decisions.

Big thanks again to everyone who has been involved!

On Thu, Dec 15, 2016 at 4:09 AM Pau Giner  wrote:

> Hi all,
>
> Some months ago we started to define a statement of purpose for design at
> Wikimedia. We shared our initial iteration and got useful feedback. Based
> on that feedback, we have updated a new version:
> https://www.mediawiki.org/wiki/Design/Statement_of_purpose
>
> Please, feel free to check the updated version, and provide any suggestion
> in the talk page.
>
> If the statement just sounds as a logical, simple, and obvious description
> for the purpose of design here, that was the goal. Putting this in writing
> has been helpful for designers and people working with us to get into the
> same page, and will be useful in the future to achieve the level of support
> for design we envision for those areas where we are not there yet.
>
> Thanks to everyone that has contributed to the process.
>
> --
> Pau Giner
> Senior User Experience Designer
> Wikimedia Foundation
>
> ___
> Design mailing list
> des...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Invitation to review: Design Statement of Purpose

[Arthur Richards]

Hi everyone, a friendly reminder that if you would like to share your
perspective on the draft statement of purpose
<https://www.mediawiki.org/wiki/Design/Statement_of_purpose>, please do so
no later than this coming Sunday, 27 November, 2016.

Big thanks to everyone who has been a part of the discussion so far :)

On Thu, Nov 10, 2016 at 10:40 AM Keegan Peterzell <kpeterz...@wikimedia.org>
wrote:

> Hello all,
>
> Over the past few months the Design team members at the Wikimedia
> Foundation (user experience [UX] designers, design researchers, user
> experience engineers, and communications) have been working with Arthur
> Richards from the Team Practices Group to identify the high-level themes
> that motivate design at the WMF. These themes have been turned into a brief
> statement of purpose, whose intent is to articulate the vision and purpose
> behind design at the WMF. This statement will influence the future
> direction of design work.
>
> At this point the stakeholders are ready for a review of the draft
> statement. The purpose of this review is to gather a common understanding
> of its purpose, and to identify any key themes that may be missing from the
> high-level discussion. On the wiki page for the statement, you'll find
> these themes and what they encompass in the "Background" section. If you
> have an observation, comment, or concern about what is listed there, please
> bring it up on the talk page. If it is relevant to the review and
> understanding of the statement, it will be looked at for future drafts. If
> there are comments about design and the design process in general, we'll
> hold on to those until a time when they can be addressed for the broader
> discussion of design in general.
>
> All that said, here are the links:
> * <https://www.mediawiki.org/wiki/Design/Statement_of_purpose>
> * <https://www.mediawiki.org/wiki/Talk:Design/Statement_of_purpose>
>
> We look forward to seeing you on the wiki.
> --
> Keegan Peterzell
> Technical Collaboration Specialist
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Debian and Ubuntu packages for MediaWiki now available

[Arthur Richards]

Woah! This is rad! Awesome work :D

On Thu, Sep 22, 2016 at 8:51 AM Cyken Zeraux  wrote:

> Its cool to see there's more easy deployment software being made. I have
> been working on a similiar project meant to be like EasyEngine. Due to the
> fact that there are better technologies out there than just apache and
> mod-php. This is a step in the right direction, though. The biggest barrier
> to developers and users having their own wiki's is that to install it
> properly requires a lot of work.
>
> On Thu, Sep 22, 2016 at 10:42 AM, Bryan Davis  wrote:
>
> > On Thu, Sep 22, 2016 at 12:44 AM, Legoktm 
> > wrote:
> > > Hi,
> > >
> > > I'm very excited to announce that Debian and Ubuntu packages for
> > > MediaWiki are now available. These packages will follow the MediaWiki
> > > LTS schedule and currently contain 1.27.1. If you've always wanted to
> > > "sudo apt install mediawiki", then this is for you :)
> > >
> > > For Debian users, you can get the mediawiki package for Jessie from the
> > > official Debian repositories using jessie-backports, and it will be
> > > included in the upcoming Stretch release.
> > >
> > > Ubuntu users will need to enable a PPA for Xenial or Trusty to set up
> > > the package.
> > >
> > > Instructions, links, and help can all be found at
> > > . Please let me
> > > know if you have any questions or feedback.
> > >
> > > Finally, thanks to Luke Faraone, Faidon Liambotis, Moritz Mühlenhoff,
> > > Max Semenik, Chad Horohoe, Antoine Musso, and all of the beta testers
> of
> > > the package for making this a reality.
> >
> > Congratulations Legoktm! This is huge!
> >
> > For those who haven't been following this, Legoktm started working
> > seriously on this project during the Wikimania 2015 hackathon in
> > Mexico City. He has kept the process moving over these many months and
> > worked through lots and lots of blocking issues that would have
> > stopped most people. For me this is just one more example of why
> > Legoktm is awesome and deserving of public praise. :)
> >
> > Bryan
> > --
> > Bryan Davis  Wikimedia Foundation
> > [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> > irc: bd808v:415.839.6885 x6855
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Mobile site is now lazy loading images

[Arthur Richards]

This is so rad, congratulations! I know this has been years in the making -
it's really awesome to see it working :D

On Tue, Aug 23, 2016 at 5:11 PM Adam Baso  wrote:

> Good question - the code tries to fetch the images ahead of them coming
> into the viewport. That can mean upon section expansion, as well.
>
> On Tuesday, August 23, 2016, Justin Ormont 
> wrote:
>
>> This sounds great. Are the images pre-loaded when the user gets close, or
>> once it's scrolled into view?
>>
>> --justin
>>
>> On Tue, Aug 23, 2016 at 3:48 PM, Volker Eckl 
>> wrote:
>>
>>> Amazing work! Enjoying the further speed improvements and the detailed
>>> analysis of Japanese Wikipedia testcase.
>>>
>>> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson 
>>> wrote:
>>>
 FYI after much experimentation, research and testing the mobile site
 has been lazy loading images [1] since Thursday 18th August. This means if
 you do not see an image you will not download it. We have taken care to
 ensure users without JavaScript can still view images and that most users
 will barely notice the difference.

 We are currently crunching the data this change has made and we plan to
 write a blog post to reporting the results.

 In our experiments on Japanese Wikipedia we saw a drop in image bytes
 per page view by 54% On the Japanese Japan article bytes shipped to users
 dropped from 1.443 MB to 142 kB.

 This is pretty huge since bytes equate to money [3] and we expect this
 to be significant on wikis where mobile data is more expensive. In a
 nutshell Wikipedia mobile is cheaper.

 As I said blog post to follow once we have more information, but please
 report any bugs you are seeing with the implementation (we have already
 found a few thanks to our community of editors).

 ~Jon

 [1]
 https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Lazy_loading_images
 [2]
 https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_of_images_on_Japanese_Wikipedia
 [3] https://whatdoesmysitecost.com/



 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


>>>
>>> ___
>>> Mobile-l mailing list
>>> mobil...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Data center switch-over moving ahead next week: please stay available :)

[Arthur Richards]

This is so rad - congratulations indeed to everyone who's been working on
this!

On Thu, Apr 21, 2016 at 8:44 AM, Toby Negrin <tneg...@wikimedia.org> wrote:

> Congrats Mark and everyone else involved. This is a big step for
> reliability and performance of the sites and a difficult technical task to
> say the least.
>
> Well done!
>
> -Toby
>
> On Thu, Apr 21, 2016 at 8:37 AM, Mark Bergsma <m...@wikimedia.org> wrote:
>
>> We've just completed the switch back, and all services are running from
>> our main data center eqiad (Ashburn) again.
>>
>> The process went very smooth this time around. In the past two days
>> leading up to this, we've been able to either fix or work around the most
>> important issues we encountered on Tuesday. This meant that we had no real
>> setbacks or unanticipated delays today, and therefore were able to complete
>> the most time pressing and user-impacting part (during which MediaWiki is
>> read-only) in 20 minutes, down from ~45 minutes two days ago.
>>
>> However, we'll be doing this again in the future, and until then we'll
>> work on improving and further automating this process to get it down to
>> hopefully much lower levels of impact and duration.
>>
>> Please let us know if you see any issues which may be caused by the
>> switch-over(s).
>>
>> Thanks much to everyone involved!
>>
>> Mark
>>
>>
>>
>> On Thu, Apr 21, 2016 at 3:53 PM, Mark Bergsma <m...@wikimedia.org> wrote:
>>
>>> Hi everyone,
>>>
>>> After we've been successfully serving our sites from our backup
>>> data-center codfw (Dallas) for the past two days, we're now starting our
>>> switch back to eqiad (Ashburn) as planned[1].
>>>
>>> We've already moved cache traffic back to eqiad, and within the next
>>> minutes, we'll disable editing by going read-only for approximately 30
>>> minutes - hopefully a bit faster than 2 days ago.
>>>
>>> [1] http://blog.wikimedia.org/2016/04/11/wikimedia-failover-test/
>>>
>>> On Tue, Apr 19, 2016 at 6:00 PM, Mark Bergsma <m...@wikimedia.org>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Today the data center switch-over commenced as planned, and has just
>>>> fully completed successfully. We are now serving our sites from codfw
>>>> (Dallas, Texas) for the next 2 days if all stays well.
>>>>
>>>> We switched the wikis to read-only (editing disabled) at 14:02 UTC, and
>>>> went back read-write at 14:48 UTC - a little longer than planned. While
>>>> edits were possible then, unfortunately at that time Special:Recent Changes
>>>> (and related change feeds) were not yet working due to an unexpected
>>>> configuration problem with our Redis servers until 15:10 UTC, when we found
>>>> and fixed the issue. The site has stayed up and available for readers
>>>> throughout the entire migration.
>>>>
>>>> Overall the procedure was a success with few problems along the way.
>>>> However we've also carefully kept track of any issues and delays we
>>>> encountered for evaluation to improve and speed up the procedure, and
>>>> reducing impact to our users - some of which will already be implemented
>>>> for our switch back on Thursday.
>>>>
>>>> We're still expecting to find (possibly subtle) issues today, and would
>>>> like everyone who notices anything to use the following channels to report
>>>> them:
>>>>
>>>> 1. File a Phabricator issue with project #codfw-rollout
>>>> 2. Report issues on IRC: Freenode channel #wikimedia-tech (if urgent)
>>>> 3. Send an e-mail to the Operations list: o...@lists.wikimedia.org
>>>>
>>>> We're not done yet, but thanks to all who have helped so far. :-)
>>>>
>>>> Mark
>>>>
>>>
>>> --
>>> Mark Bergsma <m...@wikimedia.org>
>>> Lead Operations Architect
>>> Director of Technical Operations
>>> Wikimedia Foundation
>>>
>>
>>
>>
>> --
>> Mark Bergsma <m...@wikimedia.org>
>> Lead Operations Architect
>> Director of Technical Operations
>> Wikimedia Foundation
>>
>> ___
>> Ops mailing list
>> o...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ops
>>
>>
>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] Tool Labs and my new job at WMF

[Arthur Richards]

I for one am psyched to see this news :)

On Fri, Apr 15, 2016 at 10:17 AM, Bryan Davis <bd...@wikimedia.org> wrote:

> I recently transferred from the Reading Infrastructure team to the
> Community Tech team [0]. The move happened because I want to spend
> more of my time working with the developers who build tools and bots
> to help the Wikimedia communities. I've been thinking about needs of
> the Tool Labs developers for a while, and in November I finally wrote
> up a proposal about a job focused on this work [1]. I was ready for a
> lengthy discussion with management to defend my ideas about this need,
> but to my surprise the feedback I got instead was mostly "it's about
> time" and "when can you start?". My draft position proposal is now
> "official" and posted on meta [2]. This project will be my major focus
> on the Community Tech team, but I will also be helping out with code
> review, deployments, and other things that the rest of the team is
> working on.
>
> People watching wikitech, labs-l, and Phabricator may have noticed
> that I have been poking at various things since January like a
> redesign of the wikitech main page [3], a new namespace for tool
> documentation [4], and generally being more active in discussing
> problems and possible solutions. Now that I am working on these issues
> full time I want to start talking about bigger issues. I have drafted
> a "vision" document on meta [5] describing some of the larger issues
> with Tool Labs (and Labs and wikitech) that are making things harder
> than they could be. This vision comes with a straw dog project roadmap
> that I think we could work towards. This is not a set in stone
> timeline, but rather a very high level description of a series of
> projects that I believe would move Tool Labs towards being an easier
> environment for collaborative FLOSS projects to thrive in. I will
> continue to refine these project ideas and create Phabricator tasks to
> track them, but before I dive too deeply into that I would like to
> solicit input on both the problems and the general solution roadmap.
> The project page is on meta rather than wikitech to make it easier for
> existing Wikimedians who aren't wikitech users to participate. The
> talk page is open for comments [6] and I look forward to hearing about
> problems and solutions that I have not yet imagined. I hope that as
> the various sub-projects solidify some of you will join me in getting
> the work done.
>
>
> [0]:
> https://wikimediafoundation.org/w/index.php?title=Template:Staff_and_contractors=105580=105576
> [1]:
> https://www.mediawiki.org/wiki/User:BDavis_%28WMF%29/Projects/Tool_Labs_support
> [2]: https://meta.wikimedia.org/wiki/Community_Tech/Tool_Labs_support
> [3]: https://wikitech.wikimedia.org/wiki/Main_Page
> [4]: https://wikitech.wikimedia.org/wiki/Category:Tool_Labs_tools
> [5]:
> https://meta.wikimedia.org/wiki/Community_Tech/Tool_Labs_support/Tool_Labs_vision
> [6]:
> https://meta.wikimedia.org/wiki/Talk:Community_Tech/Tool_Labs_support/Tool_Labs_vision
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation<bd...@wikimedia.org>
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808        v:415.839.6885 x6855
>
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>



-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] The end of the Roadmap Phabricator project

[Arthur Richards]

+teampractices


On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier g...@wikimedia.org wrote:

 Hello all,

 First, some history and context:

 The #roadmap project[0] in our Phabricator instance was set up by Erik M
 as a trial way of tracking upcoming releases, deployments, and generally
 new things of note, as these previously weren't tracked in one place.
 It has a workboard[1] that is is broken up into:
 * one column for each week for the current month
 * one column for each remaining month in the current quarter
 * then not soon

 The scope of this project covered both things that might break the site
 or are otherwise risky and also things people might expect to be
 notified about. At the time things got released quite often without a
 standard way for people to find that they were coming.

 I helped Erik with maintaining this project because it was also useful
 for our weekly roadmap and deployments update meeting where most WMF
 engineering managers got together for about 15-30 minutes to go over:
 * What, of note, is going out next week?
 * What, of note, is going out in the near term (i.e.: next few weeks)?
 * Anything else we should know about?

 Outcomes of this meeting were:
 * An updated outline of upcoming deployments on the Deployment
   Calendar[2]
 ** This helped inform the work of the WMF RelEng and Ops teams,
especially
 * A time/space for people (especially Erik or others with intimate
   community knowledge/intuition) to object to something going out at
   all, or at the proposed time


 Since this project was set up, Guillaume started the #user-notice and
 #developer-notice projects [4][5], which cover the things to tell
 people about a lot better, are much more general covering incidents and
 planned outages as well as code deployments, and are communicated out
 via volunteer translators to dozens of community notice boards every
 week.


 == Current world / Assessment ==

 We are still using the #roadmap project for a lot of things that don't
 risk deployment/stability disruption, and also updating the Deployments
 Calendar on wikitech. It is my opinion that there is not enough gain
 from maintaining both work products to justify the effort, especially as
 #user-notice and #developer-notice have become so valuable.


 == Proposal ==

 I propose that we discontinue the use of #roadmap.

 Potential gaps created by the deprecating of #roadmap and my proposed
 solutions:

 * Lack of a project that tracks big upcoming software/product releases
 **  The #release[3] project was created for this

 * Lack of a time-scale perspective of upcoming releases/deployments
 ** I believe that the Deployments Calendar[2], while imperfect (wiki
templates), fulfills this

 * Users aren't informed of upcoming changes
 ** the #user-notice[4] project in Phabricator should be used for that


 == Expectations ==

 To successfully do this (deprecate #roadmap) I expect all WMF
 Engineering teams (as the group of developers I have more influence over
 versus the Wikimedia engineering community) to pro-actively communicate
 out their plans, in public, with the appropriate use of the Deployments
 Calendar and the #user-notice Phabricator project. This means engaging
 with the Community Engagement/Liaison team when appropriate.

 In no small way this is me, as Release Manager, showing trust in the
 work of the WMF Engineering teams (which includes the product managers).
 Do good things with it :-)

 Let me know if you have any concerns,

 Greg


 [0] https://phabricator.wikimedia.org/project/profile/1109/
 [1] https://phabricator.wikimedia.org/project/board/1109/
 [2] https://wikitech.wikimedia.org/wiki/Deployments
 [3] https://phabricator.wikimedia.org/project/profile/1333/
 [4] https://phabricator.wikimedia.org/tag/user-notice/
 [5] https://phabricator.wikimedia.org/tag/developer-notice/

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] interesting read: testing@LinkedIn

[Arthur Richards]

Thanks for sharing this, Brian! x-posting to teampractices

On Fri, Jun 19, 2015 at 6:55 AM, Brian Gerstle bgers...@wikimedia.org
wrote:

 Short case study at LinkedIn [0]
 
 http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality
 
 about how they cut release latencies by 80-90% by reversing the ice cream
 cone of death [1]
 http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png
 :

 There's one particular snippet that strongly resonates with what I've
 experienced at multiple jobs (emphasis mine):

 *Team ownership of quality*



 Quality is the responsibility of the *whole team*. Quality control is most
  efficiently achieved if software quality is considered at *every step in
  the development cycle*. A software quality process will benefit from an
  appropriate distribution of test automation ownership between teams
  cooperating in a software development effort.


 In other words: QA aren't the only ones responsible for tests. I would go a
 step (or several) further and explicitly suggest that testing needs to be
 considered at—or an integral part of—the  design  planning processes.
 Rich Hickey goes even further in his talk about Hammock Driven
 Development
 https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR;
 people start work before fully understanding the problem space).

 Things seem to be trending up at WMF, especially w/ the Web engineers' big
 strides in end-to-end testing.  However, as the article suggests, you need
 to attack the quality problem from both ends—perhaps even emphasizing unit
 tests (shortest feedback, cheapest, least fragile).

 0:

 http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality
 1:
 http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png,
 thanks to Zeljko for introducing me to that fun term, much better than
 upside-down pyramid

 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] interesting read: what makes great PMs

[Arthur Richards]

Another good one Brian - x-posting to teampractices.

On Fri, Jun 19, 2015 at 8:26 AM, Adam Baso ab...@wikimedia.org wrote:

 On Friday, June 19, 2015, Brian Gerstle bgers...@wikimedia.org wrote:
 
 
  ...I think engineers who are sold on the teams'
  mission are capable of making good decisions about what to work on.  Our
  current situation in the Readership vertical is a live experiment on this
  subject.
 

 Indeed. I'm looking forward to the good work our engineers will produce
 under the current federated engineer-led product owner approach. For those
 who don't know, historically the mobile teams subsumed into Reading had 3
 product managers. Presently, there's 1 product manager in the vertical
 recruiting for backfills is in flight), and many common product owner
 responsibilities are federated to an engineer within each discipline.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Read the VisualEditor process review

[Arthur Richards]

x-posting to teampractices list

On Fri, Jun 5, 2015 at 4:56 PM, Neil P. Quinn nqu...@wikimedia.org wrote:

 Hello everybody!

 For the past couple months, Joel Aufrecht and I have been working on a
 project to document and improve the VisualEditor team's processes; we just
 published a draft of our report
 https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on
 mediawiki.org. If you're interested, please read it over and, of course,
 shout at us on the talk page if we wrote anything stupid.

 In addition to the team's significant strengths, we identified three major
 challenges we'd like to work on:

- Consulting stakeholders like Analytics and Design Research often have
trouble engaging with VE’s development.
- The process for early-stage requirements and design decision-making is
informal and incomplete.
- The team has a high reporting load which may no longer be justified.

 Next week, we'll start to expand the report with some proposed solutions
 (suggestions welcome!)

 Have a good weekend!
 —
 Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF,
 product analyst
 Wikimedia Foundation
 +1 (202) 656 3457
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Niharika Kohli

[Arthur Richards]

Welcome Naharika, great to have you aboard :)

On Monday, May 25, 2015, Jonathan Morgan jmor...@wikimedia.org wrote:

 Welcome, Naharika!

 Your grant review application is awesome. I'm glad we get to keep drawing
 on your skills!

 Best,
 Jonathan

 On Mon, May 25, 2015 at 1:20 PM, Bryan Davis bd...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','bd...@wikimedia.org'); wrote:

 Community Tech is glad to welcome Niharika Kohli as a Software Engineer.
 Her first day will be 2015-05-26.

 Here's the great blurb she wrote for me to forward on to the lists:

 Niharika lives in New Delhi, India where she's recently completed her
 undergraduate in IT. She's formerly been an OPW (now Outreachy) intern with
 Wikimedia for Round 7 where she had fun working on the compact language
 selector project with the Language Engineering team. She's also been a
 Google Summer of Code intern where she worked on a whacky Django project in
 a tiny five person organization.
 Niharika's been working as a contractor with the Foundation since
 November on the Wikimania Scholarships and Grants Review applications.
 She's also been having a lot of fun bullying around Wikimedia's GSoC and
 Outreachy interns (one of the perks of being an org-administrator).
 Niharika enjoys cooking Indian food in her spare time. She's also fond of
 travelling, roller coasters, board games, messing around with gadgets and
 other nerdy stuff like solving the Rubik's cube. She's thrilled to be
 working with Wikimedia which is her first real job.


 --
 Bryan Davis  Wikimedia Foundationbd...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','bd...@wikimedia.org');
 [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
 irc: bd808v:415.839.6885 x6855

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 javascript:_e(%7B%7D,'cvml','wmf...@lists.wikimedia.org');
 https://lists.wikimedia.org/mailman/listinfo/wmfall




 --
 Jonathan T. Morgan
 Senior Design Researcher
 Wikimedia Foundation
 User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)



-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Frances Hocutt

[Arthur Richards]

Awesome, I'm very happy to see this news :)
On May 26, 2015 3:43 AM, Tomasz Finc tf...@wikimedia.org wrote:

 Great to have you on board full time

 On Mon, May 25, 2015 at 12:39 PM, Bryan Davis bd...@wikimedia.org wrote:
  I'm excited to announce that Frances Hocutt has been hired as a Software
  Engineer on the Community Tech team starting 2015-05-26.
 
  She has gotten a good start on getting things done by writing a great
  introduction blurb for me to forward on:
 
  Frances is looking forward to starting on a [new team doing cool but
  unspecified stuff]. Frances has been with the WMF for most of the last
 year,
  first as an OPW intern and then as a developer for Community Resources.
  Frances has primarily worked in the MediaWiki API ecosystem: she wrote
 the
  standard for API client libraries, evaluated a number of them, and
 developed
  wiki bots to support this Inspire campaign and the Co-op mentorship
 project
  on English Wikipedia. She also has contributed patches and product
  management to Wikimetrics. Before starting work in F/OSS, Frances worked
 as
  a medicinal chemist, studied organic chemistry and materials science, and
  founded a hackerspace. She moved to the Bay Area in January. She enjoys
  giving talks, mentoring new programmers, and practicing various fiber
 arts.
 
  Frances can be found as fhocutt on IRC, Fhocutt as a volunteer, and
 Fhocutt
  (WMF) officially.
 
 
  --
  Bryan Davis  Wikimedia Foundationbd...@wikimedia.org
  [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
  irc: bd808v:415.839.6885 x6855
 
  ___
  Wmfall mailing list
  wmf...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wmfall
 

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase

[Arthur Richards]

Awesome! That is a truly significant improvement and quite an achievement.
High-fives all around :D

On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote:

 Hello all,


 Earlier this morning, we made some good progress towards a faster
 VisualEditor experience by loading the HTML from
 https://rest.wikimedia.org/, the REST content API that entered beta
 production a bit over a week ago [1]. Preliminary data shows a drop of mean
 client HTML load times by close to 40% from about 1.9 seconds to 1.2
 seconds.


 The reasons for this speed-up are primarily



-

a reduction in HTML size by 30-40%, achieved by storing page metadata
separately in RESTBase [2], and
-

storing (rather than caching) the HTML of all Wikipedia articles, thus
eliminating expensive cache misses.


 So far we have enabled this optimization on all Wikipedias. Other projects
 with VisualEditor support will follow over the next week. There are also a
 lot more optimizations in the pipeline. Eventually, we hope to completely
 eliminate the need to re-load the page for editing by using the same
 Parsoid-generated HTML for regular page views.


 While many people helped to make RESTBase and the content API a reality
 (see the original announcement [1]), I want to specially call out Marko
 Obrovac for doing much of the integration work with MediaWiki and the
 VisualEditor extension.


 I hope that you enjoy the newly faster VisualEditor experience as much as
 we do!


 Sincerely --


 Gabriel Wicke


 Principal Software Engineer, Wikimedia Foundation


 [1]:
 https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html

 [2]: https://www.mediawiki.org/wiki/RESTBase

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Wikimedia REST content API is now available in beta

[Arthur Richards]

Wow! Awesome to see this come to life :D Congratulations on this milestone.

On Tue, Mar 10, 2015 at 3:29 PM, James Forrester jforres...@wikimedia.org
wrote:

 On 10 March 2015 at 15:23, Gabriel Wicke gwi...@wikimedia.org wrote:

  Hello all,
 
  I am happy to announce the beta release of the Wikimedia REST Content API
  at
 
  https://rest.wikimedia.org/
 
  Each domain has its own API documentation, which is auto-generated from
  Swagger API specs. For example, here is the link for the English
 Wikipedia:
 
  https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
 

 ​Congratulations, Services team
 ​, and all those who've helped you get to this point​
 . This is a huge milestone and I'm so happy we've reached it. It'll be
 hugely valuable for Mobile Web, Mobile Apps, VisualEditor and dozens​ of
 other projects. Thank you!


 ​Yours,
 --
 James D. Forrester
 Product Manager, Editing
 Wikimedia Foundation, Inc.

 jforres...@wikimedia.org | @jdforrester
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Announcement: Tyler Cipriani joins Wikimedia as Release Engineer

[Arthur Richards]

Welcome Tyler, great to have you aboard and I'm always happy to welcome
folks in the Mountain Timezone :)



On Mon, Feb 9, 2015 at 4:24 PM, Kristen Lans kl...@wikimedia.org wrote:

 Welcome Tyler! Great to have you on board.

 On Mon, Feb 9, 2015 at 5:35 PM, Emily Blanchard eblanch...@wikimedia.org
 wrote:

 Welcome Tyler!






 Emily Blanchard
 Talent Acquisition Team
 Wikimedia Foundation
 eblanchard@wikimedia. eblanch...@gmail.comorg
 Follow us on Twitter @wikimediaatwork
 http://wikimediafoundation.org/wiki/Home
 Become a Contributor:  https://en.wikipedia.org/wiki/Wikipedia:Teahouse
 Join Us: http://wikimediafoundation.org/wiki/Work_with_us
 Developers Join the Fun: http://www.mediawiki.org/wiki/Communication


 *Imagine a world in which every single human being can freely share inthe
 sum of all knowledge.  Help us make it a reality!*

 On Mon, Feb 9, 2015 at 1:39 PM, Dan Duvall dduv...@wikimedia.org wrote:

 Welcome, Tyler! I'm looking forward to working together.

 On Mon, Feb 9, 2015 at 1:28 PM, Greg Grossmeier g...@wikimedia.org
 wrote:

 Hello all,

 I’m delighted to announce that Tyler Cipriani[0] is joining the
 foundation as a Release Engineer (obviously joining the Release
 Engineering team).

 Tyler lives (and will continue to work remotely from) where you can see
 the Flatirons[1] in Colorado and comes to us from SparkFun[2] where he
 was a web developer and sysadmin.

 Along with the Wikimedia Foundation being a great fit professionally for
 Tyler (I’m biased maybe) he is also “thrilled to be working at an
 organization whose values seemingly so closely align with [his] own.”

 He’ll be at the San Francisco office the week of the 16th and is seeking
 any suggestions as to what he should do with his free afternoon on
 Presidents’ Day.

 Please join me in welcoming Tyler!

 Greg


 [0] https://tylercipriani.com/
 [1] https://en.wikipedia.org/wiki/Flatirons
 [2] https://www.sparkfun.com/

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




 --
 Dan Duvall
 Automation Engineer
 Wikimedia Foundation http://wikimediafoundation.org

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering



 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering



 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Hackathon 2015 in Phabricator

[Arthur Richards]

Thanks for getting this started, Quim. Is this also the appropriate place
and is this the appropriate time to start proposing focus
areas/projects/sessions/etc? Is there already a theme/scope defined for
project ideas (eg I see a column on the workboard entitled 'New forms of
editing hack ideas' - is that the general hackathon theme)?

On Wed, Feb 4, 2015 at 2:59 AM, Quim Gil q...@wikimedia.org wrote:

 Hi, just a note to say that the Phabricator project for the Wikimedia
 Hackathon 2015 (Lyon, 23-25 May) has been created.

 https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/

 You are invited to ask questions, provide feedback, and get involved.

 Important note: even if we are just bootstrapping the project there, the
 volunteers at Wikimedia France have done a ton of work already (i.e. the
 venue and main services are secured).

 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Developer Summit 2015 schedule instructions

[Arthur Richards]

Thanks for getting this out, Quim! Is there a deadline for getting sessions
scheduled?

On Mon, Dec 22, 2014 at 10:15 AM, Quim Gil q...@wikimedia.org wrote:

 A draft version of the MediaWiki Developer Summit 2015 (San Francisco,
 January 26-27) is available at
 https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule

 You will see some slots pre-scheduled for three main topics: Mobile,
 Editing, and Service Oriented Architecture. There are some pre-scheduled
 sessions proposed by the Architecture Committee and the Product team, plus
 the opening and wrap-up sessions.

 There are many slots available, and at this point almost everything is
 flexible and negotiable. To book your session, check

 https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#How_to_schedule_a_session

 As an experiment, we are linking all sessions to a corresponding
 Phabricator task. The goal is to ease documentation and discussion before
 and after the summit, linking each session to related tasks and projects.
 This is also a way to add the preparation of the session to your personal
 and team backlogs.

 Allocate time to prepare your sessions, and encourage discussion and
 collaboration before and after the event. Let's make the most out of this
 unique MediaWiki gathering!

 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] All non-api traffic is now served by HHVM

[Arthur Richards]

Truly fantastic news - awesome work!

On Wed, Dec 3, 2014 at 5:01 PM, Robert Rohde raro...@gmail.com wrote:

 Hey, I just rendered [[Barack Obama]] in about 6 seconds.  I haven't tested
 it for several months, but in the post-Lua era I've generally gotten around
 12-15 seconds.  (Prior to Lua citations, it was 30 seconds.)  I don't know
 is HHVM is the whole story, but that's a fabulous improvement towards the
 usability of our largest pages.

 -Robert Rohde

 On Wed, Dec 3, 2014 at 3:23 PM, Tomasz Finc tf...@wikimedia.org wrote:

  This is fantastic. Great job team and do put up a blog post about this.
 
  --tomasz
 
  On Wed, Dec 3, 2014 at 9:03 AM, Giuseppe Lavagetto
  glavage...@wikimedia.org wrote:
   Hi all,
  
   it's been quite a journey since we started working on HHVM, and last
   week (November 25th) HHVM was finally introduced to all users who
 didn't
   opt-in to the beta feature.
  
   Starting on monday, we started reinstalling all the 150 remaining
   servers that were running Zend's mod_php, upgrading them from Ubuntu
   precise to Ubuntu trusty in the process. It seemed like an enormous
 task
   that would require me weeks to complete, even with the improved
   automation we built lately.
  
   Thanks to the incredible work by Yuvi and Alex, who helped me basically
   around the clock,  today around 16:00 UTC we removed the last of the
   mod_php servers from our application server pool: all the non-API
   traffic is now being served by HHVM.
  
   This new PHP runtime has already halved our backend latency and page
   save times, and it has also reduced significantly the load on our
   cluster (as I write this email, the average cpu load on the application
   servers is around 16%, while it was easily above 50% in the pre-HHVM
  era).
  
   The API traffic is still being partially served by mod_php, but that
   will not be for long!
  
   Cheers,
  
   Giuseppe
   --
   Giuseppe Lavagetto
   Wikimedia Foundation - TechOps Team
  
   ___
   Ops mailing list
   o...@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/ops
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bugzilla-Phabricator migration (almost) completed

[Arthur Richards]

This is phabulous news!

On Mon, Nov 24, 2014 at 10:53 AM, Antoine Musso hashar+...@free.fr wrote:

 Le 24/11/2014 08:41, Quim Gil a écrit :
  We did it. https://phabricator.wikimedia.org now contains all the
 Bugzilla
  reports.

 Hello,

 It is working nicely and the transition has been very smooth for my use
 cases.


 I still don't understand how we ended up starting the migration to
 Phabricator.  I first heard of people willing to move to Phabricator
 back in January while I was in San Francisco.  I am still unsure whether
 there was a real plan or whether those people were sensing my opinion on
 it.

 After a couple beers and hours of discussion about bug and workflows, I
 was pretty much convinced it was a good idea and said so. I was less
 convinced about us migrating in just 2 weeks though :-)

 Whatever cabal is running behind, that is a nice move. Thank you!

 Thank you for anyone that got involved in one way or an other in this
 challenging move.  You all did a very nice and professional works other
 those last months.  I am proud of Wikimedia.


 --
 Antoine hashar Musso


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Marielle Volz joins Wikimedia as Software Developer

[Arthur Richards]

Welcome Marielle :)
On Oct 27, 2014 11:48 AM, Tomasz Finc tf...@wikimedia.org wrote:

 I am pleased to announce Marielle Volz joining the Wikimedia
 Foundation as a Software Engineer for the Editing team.

 Marielle will be working remotely from London, UK. She made her first
 website[1] in 1997 with Adobe PageMill 2.0[2], which according to one
 review at the time, has terrific tables by today's standards for an
 HTML editor, although they're not bad by any standard.[3]. When her
 house finally got the internet in 1999, she first discovered the view
 source button. It wasn't until 5 years later in 2004 that she
 registered her first Wikipedia account, wherein she developed a lovely
 addiction to that damnable website.

 During a brief period of insanity (i.e. all of her undergraduate and
 graduate education) she considered becoming a Scientist, before
 realizing it's actually more fun to sit inside on a computer all day
 editing Wikipedia articles about Science rather than Doing Science and
 actually going outside, which, with the advent of vitamin D
 supplementation, is wholly unnecessary, and perhaps one could even
 say, *inadvisable*.

 Only now, having recently become a member of the 10 year club, has
 finally joined two of her passions: making internet stuff and
 Wikipedia internet stuff to work on VisualEditor, an HTML editor. To
 that end of continuing to edit articles about Science, and also making
 internet stuff, she did the FOSS Outreach Program for Women program
 this Summer[4], and started developing a node.js service Citoid[5] to
 make it easy to insert citations using a URL/DOI/Title in VE/Wikitext.

 She'll be continuing to do that, and maybe other things, but mostly
 that, as a contractor starting last month.

 Please join me in welcoming Marielle to the Wikimedia Foundation.

 --tomasz

 [1]
 http://web.archive.org/web/20030126114223/http://www.tufts.edu/as/engdept/mpwg/exhibits/stow/marielle.html
 [2] https://en.wikipedia.org/wiki/Adobe_PageMill
 [3]
 http://web.archive.org/web/20080620021417/http://www.soc.org.uk/bulletin/pagemil2.htm
 [4] https://www.mediawiki.org/wiki/User:Mvolz/OPW_proposal_round_8
 [5] https://www.mediawiki.org/wiki/Citoid

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Meet-up at WMF: Exploratory Testing for Complex Software, Oct 22 2014

[Arthur Richards]

Just a reminder that this is happening this coming Wednesday, and that we
are planning to record/broadcast the event for remote participants.

On Tue, Sep 23, 2014 at 10:31 AM, Arthur Richards aricha...@wikimedia.org
wrote:

 On Wednesday, October 22, 2014 the Quality Assurance Group and Team
 Practices Group hope you will join us for a meet-up at the WMF entitled
 'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with
 special guest speaker Elisabeth Hendrickson [1]. We will be discussing
 testing in agile iterative software development, and in particular exploratory
 testing https://en.wikipedia.org/wiki/Exploratory_testing [0]. This
 will be a lively and enlightening conversation, aimed at everyone concerned
 about the overall quality of software - even those who do not necessarily
 contribute code.

 *When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there
 is a calendar event on the Engineering calendar)

 *Where*:
 Wikimedia Foundation
 6th Floor, collab space
 149 New Montgomery St.
 San Francisco, CA
 (Accessible for remote participation via Hangouts on Air; link TBA)

 *From the meet-up invite
 http://www.meetup.com/wikimedia-tech/events/207856222/*[2]:
 In modern software development organizations, the days are gone when
 separate, independent Quality Assurance departments test software only
 after it is finished. Iterative development and agile methods mean that
 software is constantly being created, tested, released, marketed, and used
 in short, tight cycles. An important testing approach in such an
 environment is called Exploratory Testing, and the Wikimedia Foundation has
 made significant investments to support Exploratory Testing for its
 software development projects.

 Elisabeth Hendrickson is test obsessed. She was an early adopter and
 vocal proponent of all aspects of agile software testing. She has been
 particularly instrumental in encouraging and defining the practice of
 Exploratory Testing. Elisabeth's 2013 book Explore It!: Reduce Risk and
 Increase Confidence with Exploratory Testing is the standard reference on
 the subject.

 Join us in the Wikimedia Foundation collaboration space to hear Elisabeth
 discuss her experience doing software testing for complex projects, with
 particular examples of Exploratory Testing from her current work as
 Director of Quality Engineering for Cloud Foundry.

 This talk is for everyone involved in the overall quality of software, and
 it will be of particular interest to Project Managers, Product Managers,
 and those working with software development projects who do not necessarily
 contribute code directly to the projects.

 [0] https://en.wikipedia.org/wiki/Exploratory_testing

 [1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She
 wrote her first line of code in 1980, and almost immediately found her
 first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile
 Alliance. She is best known for her Google Tech Talk on Agile Testing as
 well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned
 how to do Agile for real from Pivotal Labs while working as a tester on one
 of their projects. In 2012 she decided it was time to take up permanent
 residence in the Pivotal offices, where she is the Director of Quality
 Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service
 (PaaS).

 [2] http://www.meetup.com/wikimedia-tech/events/207856222/

 --
 Arthur Richards
 Team Practices Manager
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Meet-up at WMF: Exploratory Testing for Complex Software, Oct 22 2014

[Arthur Richards]

On Wednesday, October 22, 2014 the Quality Assurance Group and Team
Practices Group hope you will join us for a meet-up at the WMF entitled
'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with
special guest speaker Elisabeth Hendrickson [1]. We will be discussing
testing in agile iterative software development, and in particular exploratory
testing https://en.wikipedia.org/wiki/Exploratory_testing [0]. This will
be a lively and enlightening conversation, aimed at everyone concerned
about the overall quality of software - even those who do not necessarily
contribute code.

*When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there
is a calendar event on the Engineering calendar)

*Where*:
Wikimedia Foundation
6th Floor, collab space
149 New Montgomery St.
San Francisco, CA
(Accessible for remote participation via Hangouts on Air; link TBA)

*From the meet-up invite
http://www.meetup.com/wikimedia-tech/events/207856222/*[2]:
In modern software development organizations, the days are gone when
separate, independent Quality Assurance departments test software only
after it is finished. Iterative development and agile methods mean that
software is constantly being created, tested, released, marketed, and used
in short, tight cycles. An important testing approach in such an
environment is called Exploratory Testing, and the Wikimedia Foundation has
made significant investments to support Exploratory Testing for its
software development projects.

Elisabeth Hendrickson is test obsessed. She was an early adopter and
vocal proponent of all aspects of agile software testing. She has been
particularly instrumental in encouraging and defining the practice of
Exploratory Testing. Elisabeth's 2013 book Explore It!: Reduce Risk and
Increase Confidence with Exploratory Testing is the standard reference on
the subject.

Join us in the Wikimedia Foundation collaboration space to hear Elisabeth
discuss her experience doing software testing for complex projects, with
particular examples of Exploratory Testing from her current work as
Director of Quality Engineering for Cloud Foundry.

This talk is for everyone involved in the overall quality of software, and
it will be of particular interest to Project Managers, Product Managers,
and those working with software development projects who do not necessarily
contribute code directly to the projects.

[0] https://en.wikipedia.org/wiki/Exploratory_testing

[1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She
wrote her first line of code in 1980, and almost immediately found her
first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile
Alliance. She is best known for her Google Tech Talk on Agile Testing as
well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned
how to do Agile for real from Pivotal Labs while working as a tester on one
of their projects. In 2012 she decided it was time to take up permanent
residence in the Pivotal offices, where she is the Director of Quality
Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service
(PaaS).

[2] http://www.meetup.com/wikimedia-tech/events/207856222/

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia engineering report, July 2014

[Arthur Richards]

=o8jyYfwH
 
- Software Engineer – Services

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oAhYYfwx
 
- Software Engineer – Front-end

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oxgWYfwr
 
- Software Engineer – Maps  Geo

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=ojIlZfw5
 
- Software Engineer – Mobile – iOS

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=ovD8YfwY
 
- QA Tester

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oKIUYfw4
 
- Software Engineer – Full Stack

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=orQ2Yfw1
 
- Lean/Agile Coach

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oVKlZfwJ
 
- Product Manager

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oQf8YfwV
 
- Product Manager – Language Engineering

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=osiMYfwe
 
- Operations Security Engineer

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oT6cYfwT
 
- UX Senior Designer http://grnh.se/veo5n8
- UX Senior Design Researcher http://grnh.se/38vlip
- UX User Research Recruiter http://grnh.se/kg42d7
- Project Coordinator – Engineering

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oUleZfwcs
 
- Mobile Partnerships Regional Manager

 http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qSa9VfwQcs=9UL9Vfwtpage=Job%20Descriptionj=oTviZfwps
 
- Program Evaluation Internship http://grnh.se/2ekx4h

 Announcements

- Arthur Richards is now Team Practices Manager (announcement

 http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2014-July/000956.html
 
).
- Kristen Lans joined the Team Practices Group as Scrum Master (
announcement

 http://lists.wikimedia.org/pipermail/teampractices/2014-July/000437.html
).
- Joel Sahleen joined the Language Engineering team as Software Engineer
(announcement
http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077829.html
 ).

  Technical Operations

 *Dallas data center*
 Throughout July, the cabling work of all racked servers and other equipment
 was nearly completed. We’re still awaiting the installation of the first
 connectivity to the rest of our US network in early August before we can
 begin installation of servers and services.

 *San Francisco data center*
 Due to a necessary upgrade to power  cooling infrastructure in our San
 Francisco data center (which we call *ulsfo*), our racks have been migrated
 to a new floor within the same building on July 9. The move completed in a
 very smooth fashion without user impact, and the site was brought back
 online serving all user traffic again in less than 24 hours.

 *PFS enabled*
 Through the help of volunteer work and research, our staff enabled Perfect
 Forward Secrecy https://en.wikipedia.org/wiki/en:Perfect_Forward_Secrecy
 on
 our SSL infrastructure, significantly increasing the security of encrypted
 user traffic.

 Labs metrics in July:

- Number of projects: 173
- Number of instances: 464
- Amount of RAM in use (in MBs): 1,933,824
- Amount of allocated storage (in GBs): 20,925
- Number of virtual CPUs in use: 949
- Number of users: 3,500

 *Wikimedia Labs*
 We’ve made several minor updates to Wikitech: we added OAuth support, fixed
 a few user interface issues, and purged the obsolete ‘local-*’ terminology
 for service groups. OPW Intern Dinu Sandaru has set forms for structured
 project documentation. This should will help match new volunteers with
 existing projects, and will make communication with project administrators
 more straightforward. Sean Pringle is in the process of updating the Tool
 Labs replica databases to MariaDB version 10.0. This may reduce replag, and
 should improve performance and reliability. We’re setting up new storage
 hardware for the project dumps. This will resolve our ongoing problems with
 full drives and out-of-date dumps.
  Features Engineering
 https://www.mediawiki.org/wiki/Wikimedia_Features_engineering Editor
 retention: Editing tools

 *VisualEditor https://www.mediawiki.org/wiki/VisualEditor*

 In July, the team working on VisualEditor converged the design for mobile
 and desktop, made it possible to see and edit HTML comments, improved
 access to re-using citations, and fixed over 120 bugs and tickets
 
 https://bugzilla.wikimedia.org/buglist.cgi?list_id=333021order=priority%2Cbug_severityproduct=VisualEditorquery_format=advancedresolution=FIXEDtarget_milestone=VE

[Wikitech-l] Announcing #wikimedia-teampractices IRC channel

[Arthur Richards]

Join the Team Practices Group
https://www.mediawiki.org/wiki/Team_Practices_Group in
#wikimedia-teampractices on IRC https://en.wikipedia.org/wiki/Irc (
irc.freenode.net) to chat about software development practices, processes,
theories, and philosophy - as they pertain to Wikimedia engineering and
beyond.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Please welcome Kristen Lans, ScrumMaster

[Arthur Richards]

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_team/Mobile_web/Roles_and_responsibilities#Scrummaster
[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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please welcome Kristen Lans, ScrumMaster

[Arthur Richards]

Of course I forwarded this without correcting a terrible typo, for the
record, Kristen's name is Kristen - NOT Kirsten ;)


On Fri, Jul 25, 2014 at 11:10 AM, Arthur Richards aricha...@wikimedia.org
wrote:

 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_team/Mobile_web/Roles_and_responsibilities#Scrummaster
 [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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon

[Arthur Richards]

Awesome


On Wed, May 21, 2014 at 9:55 AM, Bryan Davis bd...@wikimedia.org wrote:

 On Fri, May 16, 2014 at 2:40 PM, Arthur Richards
 aricha...@wikimedia.org wrote:
 
  CentralAuth/Multiwiki:
  Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this,
  and we now have support for multiwiki/CentralAuth in Vagrant! There is
  still some cleanup work being done for the role to remove
 kludge/hacks/etc
  (see https://gerrit.wikimedia.org/r/#/c/132691/).

 The CentralAuth role and the associated puppet config that allows
 creation of multiple wikis as Apache virtual hosts on a single
 MediaWiki-Vagrant virtual machine have been merged! Go forth and
 debug/extend CentralAuth. :)

 I'd love to see additional roles created that use the multwiki::wiki
 Puppet define to add interesting things for testing/debugging like RTL
 wikis or other complex features such as WikiData that use a
 collaboration between multiple wikis in the WMF production cluster.
 If you're interested in working on something like this and get stuck
 with the Puppet code needed or find shortcomings in the setup that
 Chris and I developed I'd be glad to try and help work through the
 issues.

 Bryan
 --
 Bryan Davis  Wikimedia Foundationbd...@wikimedia.org
 [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
 irc: bd808v:415.839.6885 x6855

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon

[Arthur Richards]

Just wanted to send out an update on the progress we made around MW-Vagrant
improvements at the Zürich Hackathon. Our primary goal was to make some key
production services available in MW-Vagrant in order to make local
development/testing easier/more reliable. We made some excellent headway,
focussing on a few key services: SSL, Varnish, CentralAuth/Multiwiki.

SSL:
I spent a majority of my time focussing on this and received a lot of
support/help from Ori. There is now an 'https' role in mw-vagrant which
when enabled, will allow you to access your devwiki on port 4430 (forwarded
to 443 in Vagrant). There is one outstanding patchset which will make it
possible to use $wgSecureLogin in MW-Vagrant:
https://gerrit.wikimedia.org/r/#/c/132799/

Varnish:
This is proving to be much more difficult than anticipated, however some
progress was made and work is ongoing, spearheaded by Andrew Otto. The plan
is to set up varnish VCLs for mw-vagrant similar to what is set up for text
varnishes in production, with a frontend and backend instance running in
vagrant. Andrew is in the midst of refactoring the production varnish
module, to make it usable in Vagrant.

CentralAuth/Multiwiki:
Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this,
and we now have support for multiwiki/CentralAuth in Vagrant! There is
still some cleanup work being done for the role to remove kludge/hacks/etc
(see https://gerrit.wikimedia.org/r/#/c/132691/).

Also of significant note, Matt Flaschen created a mw-vagrant iso which can
be packaged on USB thumb drives, making it possible to set up mw-vagrant
without a network connection. There is still some work to be done here to
create a one-click installer as well as updating documentation. Matt got
this done before the hackathon, and we brought a bunch of USB sticks imaged
with the iso, which was instrumental in getting a bunch of folks new to
mw-vagrant up and running at the hackathon. This was particularly useful
during Bryan Davis's vagrant bootcamp sessions.

I believe Katie Filbert from Wikidata did some mw-vagrant work at the
hackathon as well, although I'm not clear on the current status. Katie, can
you let us know where things were at with what you were working on?

All in all it felt like a very fruitful hack session, and we're closer than
ever to having a ready-to-go developer instance that mimics our production
environment. Big thanks to everyone involved in making our work successful.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MW-Vagrant improvements at the Zürich Hackathon

[Arthur Richards]

PS One thing I forgot to mention - mega thanks to WMF's Office IT for
helping with ordering and imaging the USB sticks!!!


On Fri, May 16, 2014 at 1:40 PM, Arthur Richards aricha...@wikimedia.orgwrote:

 Just wanted to send out an update on the progress we made around
 MW-Vagrant improvements at the Zürich Hackathon. Our primary goal was to
 make some key production services available in MW-Vagrant in order to make
 local development/testing easier/more reliable. We made some excellent
 headway, focussing on a few key services: SSL, Varnish,
 CentralAuth/Multiwiki.

 SSL:
 I spent a majority of my time focussing on this and received a lot of
 support/help from Ori. There is now an 'https' role in mw-vagrant which
 when enabled, will allow you to access your devwiki on port 4430 (forwarded
 to 443 in Vagrant). There is one outstanding patchset which will make it
 possible to use $wgSecureLogin in MW-Vagrant:
 https://gerrit.wikimedia.org/r/#/c/132799/

 Varnish:
 This is proving to be much more difficult than anticipated, however some
 progress was made and work is ongoing, spearheaded by Andrew Otto. The plan
 is to set up varnish VCLs for mw-vagrant similar to what is set up for text
 varnishes in production, with a frontend and backend instance running in
 vagrant. Andrew is in the midst of refactoring the production varnish
 module, to make it usable in Vagrant.

 CentralAuth/Multiwiki:
 Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this,
 and we now have support for multiwiki/CentralAuth in Vagrant! There is
 still some cleanup work being done for the role to remove kludge/hacks/etc
 (see https://gerrit.wikimedia.org/r/#/c/132691/).

 Also of significant note, Matt Flaschen created a mw-vagrant iso which can
 be packaged on USB thumb drives, making it possible to set up mw-vagrant
 without a network connection. There is still some work to be done here to
 create a one-click installer as well as updating documentation. Matt got
 this done before the hackathon, and we brought a bunch of USB sticks imaged
 with the iso, which was instrumental in getting a bunch of folks new to
 mw-vagrant up and running at the hackathon. This was particularly useful
 during Bryan Davis's vagrant bootcamp sessions.

 I believe Katie Filbert from Wikidata did some mw-vagrant work at the
 hackathon as well, although I'm not clear on the current status. Katie, can
 you let us know where things were at with what you were working on?

 All in all it felt like a very fruitful hack session, and we're closer
 than ever to having a ready-to-go developer instance that mimics our
 production environment. Big thanks to everyone involved in making our work
 successful.

 --
 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Bernd Sitzmann as Software Developer to the Mobile App Team

[Arthur Richards]

Welcome - looking forward to working with you :)


On Tue, May 13, 2014 at 7:11 PM, Monte Hurd mh...@wikimedia.org wrote:

 Awesome! Welcome! :)


 On Mon, May 12, 2014 at 4:52 PM, Brion Vibber bvib...@wikimedia.orgwrote:

 Hertzlich willkommen Bernd!

 -- brion
 On May 12, 2014 10:09 AM, Tomasz Finc tf...@wikimedia.org wrote:

 Bernd will be working remotely from Fort Collins, CO, where he has
 lived ever since emigrating from Germany many years ago.

 He joins the Wikimedia Foundation after developing software at HP in
 Germany and the US for many years. He's worked on both front-end and
 back-end components, developing applications for enterprise management
 software as well as consumer software (HP MediaSmart Server, WebOS
 related work, and a couple of Android apps).

 Bernd is very passionate about user experience and Android. He is
 excited to contribute to open source projects. When not developing
 Android apps, he also enjoys learning about some of the latest web
 technologies, currently favoring Meteor.js. Afk he enjoys playing
 volleyball, ultimate frisbee and soccer.

 Bernd will join the Apps team working closely with Yuvi and Dmitry on
 the rebooted native Android Wikipedia app.

 Please Welcome Bernd

 --tomasz

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall


 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall



 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugello updates, rolling out next week

[Arthur Richards]

To accommodate the mobile web team's migration from Mingle to Trello, I've
made some enhancements to Bugello [1] to bring it more in line with the
features we had added to Bingle. New features include:
* Support for prefixing bug cards in Trello with [Bug $bug_num], which
helps with...
* Improved dupe detection
* Adding bug descriptions to Trello card
* Adding bug comments from BZ to new Trello cards
* Posting a link back to BZ to the Trello card

I also did some refactoring and made some minor bug fixes (including one
that I know was plaguing the Flow team).

I will be rolling this out for the mobile web team on Monday. Any other
current users of Bugello should contact me if interested in updating to get
these features - there are some config changes that you'll need to make and
a couple of gotchas to look out for, and I'd be happy to walk you through
it.

Thanks and happy Friday!

[1] http://github.com/wikimedia/bingle - note that Bugello is included with
Bingle
-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: [Wikimedia-l] Wikimedia Hackathon: Info session in one hour!

[Arthur Richards]

For those of us watching the stream, will there be a channel monitored on
IRC for questions etc?


On Thu, Apr 24, 2014 at 9:54 AM, Quim Gil q...@wikimedia.org wrote:

 Just a reminder: this session is about to start.


 -- Forwarded message --
 From: Manuel Schneider manuel.schnei...@wikimedia.ch
 Date: Thu, Apr 24, 2014 at 9:00 AM
 Subject: [Wikimedia-l] Wikimedia Hackathon: Info session in one hour!
 To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org


 Dear all,

 in one hour we will have an info session via Google Hangout on the
 upcoming Wikimedia Hackathon in Zürich. If you want to join just check
 out this event:

 https://plus.google.com/events/cj4okkse0n8ealb7mntrc4458a8

 The video will also be shared on Youtube.

 Below is the mail that has been sent to all folks who have already
 registered for the Hackathon.
 By the way you can still register, we even happen to have very few beds
 in reserve:


 https://docs.google.com/forms/d/1nlrQ7cox36xaNK1u9iKP-thogY5TVrilOGJR79DqQ9A/viewform

  the Wikimedia Foundation has arranged a Google Hangout in order to
  get a quick introduction for the upcoming Wikimedia Hackathon in
  Zürich. We have decided to open this meeting for all participants and
  will discuss how to get to the Youth Hostel, get an outlook on the
  program and answer your questions.
 
  If you are interested and have time you can participate in this
  Hangout later at April 24th 17:00 UTC here:
  * https://plus.google.com/events/cj4okkse0n8ealb7mntrc4458a8
 
  The session will be recorded on Youtube, so everyone else can watch
  it afterwards. If you cannot attend but have questions, please send
  them to me.

 Regards,


 Manuel
 --
 Wikimedia CH - Verein zur Förderung Freien Wissens
 Lausanne, +41 (21) 34066-22 - www.wikimedia.ch

 ___
 Wikimedia-l mailing list
 wikimedi...@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe


 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Dmitry Brant as Software Developer to the Mobile App Team

[Arthur Richards]

Welcome Dmitry! I'm looking forward to working with you :D


On Tue, Apr 22, 2014 at 10:27 AM, Dan Garry dga...@wikimedia.org wrote:

 Welcome, Dmitry!

 Dan


 On Tuesday, 22 April 2014, Tomasz Finc tf...@wikimedia.org wrote:

 I am pleased to announce that Dmitry Brant joins WMF this week as a
 Software Engineer for the Mobile App Team!

 Dmitry will be working remotely from Cleveland, OH, where he has lived
 ever since immigrating from Moscow, Russia many years ago.  He joins
 the Wikimedia Foundation coming from a previous life in speech
 recognition software for use in military robots, UGVs, and medical
 devices, and an even earlier life in software for controlling welding
 equipment and industrial robotic cells.

 Dmitry believes passionately in WMF's mission, and is excited to help
 enhance the Wikipedia user experience on mobile platforms.

 In his spare time he creates software for digital forensics and data
 recovery [1]. In his other spare time, he's an avid guitar player,
 blogger, and mushroom forager.

 Dmitry will work closely with Yuvi to further enhance the user
 experience for the upcoming native Wikipedia app.

 Please welcome Dmitry!

 [1] - http://diskdigger.org

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall



 --
 Dan Garry
 Associate Product Manager for Platform
 Wikimedia Foundation


 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Need help with mw api patch review

[Arthur Richards]

w00t! thanks Timo and everyone else :D


On Thu, Apr 10, 2014 at 1:39 PM, James Forrester
jforres...@wikimedia.orgwrote:

 On 9 April 2014 16:45, Arthur Richards aricha...@wikimedia.org wrote:

  The mobile web team has been trying to get
  https://gerrit.wikimedia.org/r/#/c/116037/ merged for quite some time
 now.
  Particularly since this is a core change, mobile web folks are hesitant
 to
  merge it ourselves. Can someone please help us get this taken care of?
 

 Thanks, Timo!

 J.
 --
 James D. Forrester
 Product Manager, VisualEditor
 Wikimedia Foundation, Inc.

 jforres...@wikimedia.org | @jdforrester
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Need help with mw api patch review

[Arthur Richards]

The mobile web team has been trying to get
https://gerrit.wikimedia.org/r/#/c/116037/ merged for quite some time now.
Particularly since this is a core change, mobile web folks are hesitant to
merge it ourselves. Can someone please help us get this taken care of?

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GeoData now uses Elasticsearch

[Arthur Richards]

Awesome stuff! I'm excited to see the fruits of this everywhere. Nice work
Max et al :)


On Wed, Apr 9, 2014 at 6:04 PM, Max Semenik maxsem.w...@gmail.com wrote:

 Hi, today GeoData spatial searches were switched from Solr to
 Elasticsearch, for now only on testwiki. We're going to test it there
 for a while before proceeding to production wikis. Suggestions where
 to start are welcome - while GD is populated on many projects, it is
 rarely used with a few exceptions:
5825 eswiki
2046 enwiki
 223 zhwiki
 216 svwiki
 155 fawiki
 130 ruwiki
 100 dewiki
  75 itwiki
  61 frwiki
  55 arwiki
  54 jawiki

 I would like to start with one project, however only itwiki and kowiki
 are using Elasticsearch among large Wikipedias.

 And finally, appreciation: this was made possible only thanks to awesome
 help from our search team, Nik Everett and Chad Horohoe. You kick ass
 guys!


 --
 Best regards,
   Max Semenik ([[User:MaxSem]])


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Aaron Schulz - Senior Performance Engineer

[Arthur Richards]

Awesome, congrats Aaron!


On Mon, Apr 7, 2014 at 5:50 PM, Dan Garry dga...@wikimedia.org wrote:

 Congratulations, Aaron!

 Dan


 On 7 April 2014 17:40, Rob Lanphier ro...@wikimedia.org wrote:

  Hi everyone
 
  I'm pleased to announce that Aaron Schulz is taking on a new role in
  Wikimedia Foundation's Platform Team: Senior Performance Engineer.
 
  Aaron works on MediaWiki internals -- components that every
  user-visible feature depends on, but which are rarely user-visible
  themselves. The impact of Aaron's work on the reliability and
  performance of MediaWiki is felt by many, but fully known to few, so
  I'd like to use this occasion to highlight some of this work.
 
  Aaron is the primary author of MediaWiki's file handling backend, job
  queue, its integration with Redis key-value database and the
  OpenStack's Swift distributed filesystem -- just to name a few of the
  more significant (and relatively recent) components.  In addition to
  these things, Aaron has designed a heavily-used set of generic
  mechanisms for enabling concurrent access to shared resources, for
  breaking up big computations into smaller units of work, and for
  distributing those units of work across a cluster of machines that can
  execute it.  Aaron's code plays an important supporting role in most
  (if not all) significant MediaWiki functionality.
 
  Aaron's move to performance recognizes the critical role he has
  already played in this area, and reflects our evolving understanding
  of how important that work is.  We are constantly striving to make the
  experience of using MediaWiki snappy so that editors can do their work
  without waiting on the software to acknowledge their actions. To meet
  these standards, we need to tackle performance in (at least) two
  areas:
 
  1. Using data to provide a picture of how users experience the site,
  identifying where users encounter latency, quantifying how it impacts
  their engagement, and using this information to drive optimizations to
  the code, paying particular attention to client-side network and
  computational load. In making this a focal point, we are heeding Steve
  Souders' Performance Golden Rule: 80-90% of the end-user response
  time is spent on the frontend. Start there. [1] Our goal here is to
  ensure that the visual display of information and the reactivity of
  the user interface exhibit the kind of immediacy that is needed for
  users to focus on and engage with content.
 
  2. Building a well-integrated set of services that, when used in the
  most obvious way, allows it to do as many things as possible, as fast
  as possible, while remaining resilient to changes in site activity.
  The vast majority of visits to our site never reach the backend of our
  stack, but the minority that do involve really critical site
  functions, such as all editor activity. We want the MediaWiki
  ecosystem to have not only the capacity to sustain current levels of
  activity, but to be an enabler of growth by making it possible for
  many more people to contribute in new ways. To meet this challenge, we
  need MediaWiki to be increasingly parallel, and to provide efficient,
  concurrent access to a rich variety of content types and storage
  layers.
 
  This split maps neatly to Ori and Aaron's respective skill-sets and
  experience, which makes for an effective partnership. Having Aaron
  formally move to a performance role both recognizes the work Aaron is
  already doing, and it lays the groundwork for a process for meeting
  performance challenges that leverages their diversity of expertise.
 
  Please join me in thanking Aaron for taking on this role!
 
  Rob
 
  [1] Steve Souders is formerly Head Performance Engineer at Google and
  Chief Performance Yahoo! at Yahoo.  Performance Golden Rule:
 
  http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l




 --
 Dan Garry
 Associate Product Manager for Platform
 Wikimedia Foundation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] beta cluster migrated to eqiad

[Arthur Richards]

en.wikipedia.beta.wmflabs.org and the mobile equivalent are not working.
I've tried just using the given IP addresses, but that results in a message
that says 'Domain not configured'. What is going on?

Is it possible to reach the old betalabs for the time being so we can
continue with testing?


On Mon, Mar 31, 2014 at 7:10 AM, Antoine Musso hashar+...@free.fr wrote:

 Hello,

 I have changed the DNS entries for the beta cluster to point to the
 instances hosted in our EQIAD datacenter.

 It seems most of the functions are working now beside SSL support.

 If you see anything that looks wrong, please fill in bugs in bugzilla
 against Wikimedia Labs  deployment-prep (beta).


 The DNS might take sometime to propagate. The IP addresses are:

 $ dig +short bits.beta.wmflabs.org
 208.80.155.137
 $ dig +short upload.beta.wmflabs.org
 208.80.155.136
 $ dig +short en.wikipedia.beta.wmflabs.org
 208.80.155.135
 $ dig +short en.m.wikipedia.beta.wmflabs.org
 208.80.155.139
 $

 Thanks to everyone that helped reconfigure the beta cluster from scratch!

 --
 Antoine hashar Musso


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] mobile beta labs unreachable

[Arthur Richards]

+wikitech-l/qa

I presume this is a byproduct of the migration. This is urgent.


On Mon, Mar 31, 2014 at 11:25 AM, Ryan Kaldari rkald...@wikimedia.orgwrote:

 http://en.m.wikipedia.beta.wmflabs.org/ has been giving me a 503 all
 morning. I really need to be able to use it since we are deploying a change
 this week that is specifically related to the cluster configuration
 (specifically overriding the licensing messaging to support dual licensing
 for the WMF projects).

 Bug filed:
 https://bugzilla.wikimedia.org/show_bug.cgi?id=63315

 Ryan Kaldari

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] beta cluster migrated to eqiad

[Arthur Richards]

I've attempted hitting the IPs both from the WMF office network as well as
through my mobile device (not on office wifi), with no success.


On Mon, Mar 31, 2014 at 11:52 AM, John phoenixoverr...@gmail.com wrote:

 Works for me

 On Mon, Mar 31, 2014 at 2:47 PM, Arthur Richards aricha...@wikimedia.org
 wrote:

  en.wikipedia.beta.wmflabs.org and the mobile equivalent are not working.
  I've tried just using the given IP addresses, but that results in a
 message
  that says 'Domain not configured'. What is going on?
 
  Is it possible to reach the old betalabs for the time being so we can
  continue with testing?
 
 
  On Mon, Mar 31, 2014 at 7:10 AM, Antoine Musso hashar+...@free.fr
 wrote:
 
   Hello,
  
   I have changed the DNS entries for the beta cluster to point to the
   instances hosted in our EQIAD datacenter.
  
   It seems most of the functions are working now beside SSL support.
  
   If you see anything that looks wrong, please fill in bugs in bugzilla
   against Wikimedia Labs  deployment-prep (beta).
  
  
   The DNS might take sometime to propagate. The IP addresses are:
  
   $ dig +short bits.beta.wmflabs.org
   208.80.155.137
   $ dig +short upload.beta.wmflabs.org
   208.80.155.136
   $ dig +short en.wikipedia.beta.wmflabs.org
   208.80.155.135
   $ dig +short en.m.wikipedia.beta.wmflabs.org
   208.80.155.139
   $
  
   Thanks to everyone that helped reconfigure the beta cluster from
 scratch!
  
   --
   Antoine hashar Musso
  
  
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 
 
 
  --
  Arthur Richards
  Software Engineer, Mobile
  [[User:Awjrichards]]
  IRC: awjr
  +1-415-839-6885 x6687
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mapping our upstream projects

[Arthur Richards]

Dunno if it's still the case, but back when I was working in fundraising we
collaborated a lot and with the CiviCRM community and contributed a bit
back to the project (both in terms of code as well as hosting CiviCRM
meetups). Drupal too, although to a lesser extent. Perhaps someone
currently working in fundraising can confirm if that's still the case.


On Wed, Mar 19, 2014 at 11:06 AM, Marc A. Pelletier m...@uberbox.orgwrote:

 On 03/18/2014 09:08 PM, Faidon Liambotis wrote:
  I'm not sure what embed in our architecture or embed in our
  processes means, could you clarify that?

 Only Quim can clarify what he means, of course, but I read the
 distinction as is used for actually producing output vs. we use it
 for our daily work.

 For instance, apache is part of our architecture, git is part of our
 processes.

 Quim, am I understanding you correctly?

 -- Marc


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] useskin=minerva

[Arthur Richards]

This is really awesome, nice work Jon, Kaldari, and everyone else
involved!!!


On Tue, Mar 11, 2014 at 12:14 PM, Jon Robson jdlrob...@gmail.com wrote:

 You can now apply the mobile skin to the desktop site [1]. Wa?!
 To cut a long story short, to help MobileFrontend and VisualEditor
 integrate nicely with one another, we needed the mobile skin to be
 registered as a valid skin. We've previously avoided this as we didn't
 want to surface this in the Special:Preferences (a side effect of
 doing so). Kaldari however found a way we can supress it there, so
 thus we went and registered it [1].

 I encourage editors to check how their stuff looks in the minerva skin
 on a small window size. This should make mobile optimisation a lot
 easier for you! :)

 [1]
 http://en.wikipedia.beta.wmflabs.org/wiki/Forty-seven_Ronin?useskin=minerva
 [2] https://gerrit.wikimedia.org/r/#/c/118037/

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Zurich Hackathon: Creating a map namespace

[Arthur Richards]

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 jdlrob...@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 aricha...@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 jdlrob...@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 q...@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 jdlrob...@gmail.com
  To: Wikimedia developers wikitech-l@lists.wikimedia.org, mobile-l
  mobil...@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
  mobil...@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
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] captcha idea: proposal for gnome outreach for women 14

[Arthur Richards]

I think this is an intriguing approach - particularly for use cases on
mobile devices. We display captchas as necessary through MobileFrontend
when they are triggered, but the mobile experience is horrible (arguably
the whole captcha experience is horrible regardless of the medium, but
that's another conversation). As long as we need to surface captchas,
something non-text based, especially if it didn't require typing, would be
preferable.


On Fri, Feb 28, 2014 at 10:07 AM, Mansi Gokhale gokhalemans...@gmail.comwrote:

 hello,

 These are some approaches i can think of instead of a text based captcha.

 The image idea where users are asked to spot the odd one out like
 demonstrated or find all the similar images like mentioned in
 herehttps://www.mediawiki.org/wiki/CAPTCHA
 .

 Also a picture with a part chipped in could be shown and chipped pictures
 could be given as options

 like find the missing part from a jigsaw puzzle.

 The image which would be shown is http://imgur.com/uefeb08

 http://imgur.com/KEJqCg3 is the picture which would be the correct option.

 The other options could be rotated versions of this , which would not be so
 easy for the bot to match. (unless it somehow worked some digital
 processing algorithm and matched the color gradients or something like
 that).

 This is a good option for people who do not know english or are illiterate
 and maybe would not understand questions like : is this a bird , plane ,
 superman? after being shown a picture.

 Tell me what you think

 (Sorry to upload those images on imgur. i dont know how to put them on the
 wiki .Hope that is ok)


 have posted this on the CAPTCHA
 pagehttps://www.mediawiki.org/wiki/Talk:CAPTCHAalso
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Need help from Wikimedia github admins to transfer bingle repo

[Arthur Richards]

I'd like to transfer the github repo for Bingle to the organization
(currently it's associated with my personal github account). According to
https://help.github.com/articles/how-to-transfer-a-repository that means
I'll need administrative rights in order to do so. Can someone help me out
with this?

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Need help from Wikimedia github admins to transfer bingle repo

[Arthur Richards]

Brion added me as an admin and I just transferred the bingle repository
from awjrichards/bingle to wikimedia/bingle. I added Dan Andreescu and S
Page as admins in addition to myself.

Theoretically, remotes should automatically redirect to the new repo but
folks may want to update their remotes to be on the safe side:
https://help.github.com/articles/how-to-transfer-a-repository#redirects-and-git-remotes

Please let me know if I still need to (or ought to) create a repo in Gerrit
and futz with puppet replication rules.


On Fri, Feb 21, 2014 at 9:50 AM, Andrew Otto o...@wikimedia.org wrote:

 Hm, someone correct me if I'm wrong, but if you want to have Bingle hosted
 on the wikimedia Github, you should create a repository for it in Gerrit,
 and then add a special replication rule in puppet in role/gerrit.pp to get
 the repository in the Github URL that you want.




 On Feb 21, 2014, at 11:45 AM, Arthur Richards aricha...@wikimedia.org
 wrote:

  I'd like to transfer the github repo for Bingle to the organization
  (currently it's associated with my personal github account). According to
  https://help.github.com/articles/how-to-transfer-a-repository that means
  I'll need administrative rights in order to do so. Can someone help me
 out
  with this?
 
  --
  Arthur Richards
  Software Engineer, Mobile
  [[User:Awjrichards]]
  IRC: awjr
  +1-415-839-6885 x6687
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New Bingle feature - resolved bug reconciliation!

[Arthur Richards]

I refactored a standalone script in bingle I wrote a while back called
bingleResolved and integrated it with bingle proper. bingleResolved will
attempt to reconcile bugs marked as 'resolved' (or some configurable
status) with Mingle. That is, if you have bug cards floating around in some
backlog in Mingle but they get marked as resolved in Bugzilla,
bingleResolved will put them where you ask it to (for instance, into the
'accepted' column of your current iteration). This should help keep Mingle
instances tidier and Mingle bug backlogs better in sync with Bugzilla.

If you pull the latest Bingle (b1ff82f46e9d422d016335667556d2a4b23410d4)
and want to use the resolved feature, make sure to update your bingle.ini
(see changes in bingle.ini.example) and run bingle with -r.

Happy Friday!

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Minor Bingle improvements - users please update your code

[Arthur Richards]

I had some free time today and made some minor improvements to Bingle to
take care of two longstanding, really annoying issues:
https://github.com/awjrichards/bingle/issues/10
https://github.com/awjrichards/bingle/issues/11
(Same issues also reported via BZ:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57830)

The changes should improve the formatting of bug descriptions/comments in
Mingle. Bingle users, please consider git pull'ing for the latest :)

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

Just wanted to give everyone a head's up that Bingle/Bugello are broken
after yesterday's BZ upgrade. At quick glance it appears related to BZ's
move to a shared host - the tools are dying with the exception:

requests.exceptions.SSLError: hostname 'bugzilla.wikimedia.org' doesn't
match either of '*.planet.wikimedia.org', 'planet.wikimedia.org'

I'll be digging into this shortly and will update when I have more info
and/or resolution.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

I can make the tools work by setting SSL verification to False, but this
doesn't seem like the soundest approach.  Looking at the SSL cert info from
https://bugzilla.wikimedia.org looks valid to me - anyone know what might
be causing this?


On Thu, Feb 13, 2014 at 12:41 PM, Arthur Richards
aricha...@wikimedia.orgwrote:

 Just wanted to give everyone a head's up that Bingle/Bugello are broken
 after yesterday's BZ upgrade. At quick glance it appears related to BZ's
 move to a shared host - the tools are dying with the exception:

 requests.exceptions.SSLError: hostname 'bugzilla.wikimedia.org' doesn't
 match either of '*.planet.wikimedia.org', 'planet.wikimedia.org'

 I'll be digging into this shortly and will update when I have more info
 and/or resolution.

 --
 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

Even setting verify=False on requests to https://bugzilla.wikimedia.org is
resulting in some weirdness. I have a hunch it is due to the fact that tool
labs has an extremely outdated version of the Python Requests library,
which has a variety of known SSL negotiation issues. I've filed a bugzilla
ticket to get Requests upgraded on tool labs:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61334


On Thu, Feb 13, 2014 at 12:57 PM, Arthur Richards
aricha...@wikimedia.orgwrote:

 I can make the tools work by setting SSL verification to False, but this
 doesn't seem like the soundest approach.  Looking at the SSL cert info from
 https://bugzilla.wikimedia.org looks valid to me - anyone know what might
 be causing this?


 On Thu, Feb 13, 2014 at 12:41 PM, Arthur Richards aricha...@wikimedia.org
  wrote:

 Just wanted to give everyone a head's up that Bingle/Bugello are broken
 after yesterday's BZ upgrade. At quick glance it appears related to BZ's
 move to a shared host - the tools are dying with the exception:

 requests.exceptions.SSLError: hostname 'bugzilla.wikimedia.org' doesn't
 match either of '*.planet.wikimedia.org', 'planet.wikimedia.org'

 I'll be digging into this shortly and will update when I have more info
 and/or resolution.

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




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

Thanks everyone, Daniel, that makes sense to me.

Some quick sleuthing shows that the requests library has some SSL
negotiation issues resolved in 2.x (tool labs is currently running 1.1.0),
though I'm not quickly finding specifics. I am hoping an upgrade will make
things Just Work but changing the load order of the Apache sites sounds
like a smart thing to do regardless. Do we need an RT ticket for that?


On Thu, Feb 13, 2014 at 2:04 PM, Daniel Zahn dz...@wikimedia.org wrote:

 Either way it's probable not bad to change the order of loading Apache
 sites to make Bugzilla
 the default now. If somebody doesn't get what they want, at least they get
 the Bugtracker
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

That seems to have done it - thanks a ton Daniel!


On Thu, Feb 13, 2014 at 4:46 PM, Daniel Zahn dz...@wikimedia.org wrote:

 On Thu, Feb 13, 2014 at 1:13 PM, Arthur Richards aricha...@wikimedia.org
 wrote:

  things Just Work but changing the load order of the Apache sites sounds
  like a smart thing to do regardless. Do we need an RT ticket for that?
 

 should be fixed by this:

 https://gerrit.wikimedia.org/r/#/c/113265/1

 try again ?

 --
 Daniel Zahn dz...@wikimedia.org
 Operations Engineer
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

Actually, I semi-take that back. I am still getting some exceptions like:
requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

But at least it's not complaining about a domain mismatch anymore.


On Thu, Feb 13, 2014 at 4:51 PM, Arthur Richards aricha...@wikimedia.orgwrote:

 That seems to have done it - thanks a ton Daniel!


 On Thu, Feb 13, 2014 at 4:46 PM, Daniel Zahn dz...@wikimedia.org wrote:

 On Thu, Feb 13, 2014 at 1:13 PM, Arthur Richards aricha...@wikimedia.org
 wrote:

  things Just Work but changing the load order of the Apache sites sounds
  like a smart thing to do regardless. Do we need an RT ticket for that?
 

 should be fixed by this:

 https://gerrit.wikimedia.org/r/#/c/113265/1

 try again ?

 --
 Daniel Zahn dz...@wikimedia.org
 Operations Engineer
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bingle/Bugello broken post-Bugzilla upgrade

[Arthur Richards]

On Thu, Feb 13, 2014 at 4:58 PM, Arthur Richards aricha...@wikimedia.orgwrote:

 Actually, I semi-take that back. I am still getting some exceptions like:
 requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14090086:SSL
 routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed


At first I thought this might be an issue of CA keys not being on tool
labs, but that does not appear to be the case. Run from the same host as
the tool in question:

local-bingle@tools-login:~$ curl -v https://bugzilla.wikimedia.org
* About to connect() to bugzilla.wikimedia.org port 443 (#0)
*   Trying 208.80.154.41... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
*  subject: serialNumber=BhQHbaOWi1kF5o57ZgySvt3TVywIQOGI; OU=GT90855227;
OU=See www.rapidssl.com/resources/cps (c)13; OU=Domain Control Validated -
RapidSSL(R); CN=bugzilla.wikimedia.org
*  start date: 2013-11-03 18:52:33 GMT
*  expire date: 2017-11-05 19:36:25 GMT
*  subjectAltName: bugzilla.wikimedia.org matched
*  issuer: C=US; O=GeoTrust, Inc.; CN=RapidSSL CA
*  SSL certificate verify ok.

The only other thing I can think of is my original theory of an issue with
the out of date Python Requests library. Anybody else have ideas?

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for Zürich Hackathon - getting close to a production-like Vagrant instance

[Arthur Richards]

Argh! Thanks Pavel :)


On Mon, Feb 10, 2014 at 7:46 PM, Pavel Astakhov pastak...@yandex.ru wrote:

 aren't you lost this links? :-)

 1 https://www.mediawiki.org/wiki/MediaWiki-Vagrant
 2 https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014

 11.02.2014 06:13, Arthur Richards пишет:

  A few of us have been discussing how awesome it would be to use
 MediaWiki-Vagrant[1] to create a portable production-like environment.
 This
 would give Mediawiki engineers a common ground from which to develop core
 code and/or extensions, and by coming close to mimicking Wikimedia's
 production environment, would hopefully reduce the amount of friction
 around getting features out to production. Also, this is something that we
 would be able to pre-package this for new engineers - imagine handing a
 new
 MediaWiki engineer a USB stick with an up-to-date MediaWiki-Vagrant
 instance that closely mimics production at say, a future hackathon.

 We started chatting about what it would take to get us there, and
 identified some initial steps that we'd like to tackle at the Zürich
 Hackathon - namely, turning a few puppetized production services into
 roles
 that we could use in MediaWiki-Vagrant.

 We've created a corresponding 'topic' on the Hackathon's topic page[2] to
 describe what we'd like to achieve at the Hackathon. Please review,
 comment, and certainly add yourself as an 'interested person' if this
 catches your fancy and you plan to attend the hackathon.



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Proposal for Zürich Hackathon - getting close to a production-like Vagrant instance

[Arthur Richards]

A few of us have been discussing how awesome it would be to use
MediaWiki-Vagrant[1] to create a portable production-like environment. This
would give Mediawiki engineers a common ground from which to develop core
code and/or extensions, and by coming close to mimicking Wikimedia's
production environment, would hopefully reduce the amount of friction
around getting features out to production. Also, this is something that we
would be able to pre-package this for new engineers - imagine handing a new
MediaWiki engineer a USB stick with an up-to-date MediaWiki-Vagrant
instance that closely mimics production at say, a future hackathon.

We started chatting about what it would take to get us there, and
identified some initial steps that we'd like to tackle at the Zürich
Hackathon - namely, turning a few puppetized production services into roles
that we could use in MediaWiki-Vagrant.

We've created a corresponding 'topic' on the Hackathon's topic page[2] to
describe what we'd like to achieve at the Hackathon. Please review,
comment, and certainly add yourself as an 'interested person' if this
catches your fancy and you plan to attend the hackathon.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Serverside Events not being logged for Echo

[Arthur Richards]

+wikitech
On Jan 29, 2014 12:15 PM, Jon Robson jdlrob...@gmail.com wrote:

 In the creation of this graph [1] - I noticed that for some reason no
 events for Thanks are being recorded to the database anymore.

 I raised a bug [2] but according to another bug [3] events on the
 server side are being logged to a file but no the database itself.

 According to the graph this happened January 9th - any ideas to why?

 [1] http://mobile-reportcard.wmflabs.org/#other-graphs-tab
 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=60550
 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=60555

 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Shahyar Ghobadpour joins Wikimedia Core features team as Software Engineer

[Arthur Richards]

Welcome Shahyar :)


On Mon, Jan 6, 2014 at 12:32 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 Welcome, Shahyar. Thank you for joining us!

 Can you point to a pronunciation of your name? (I'm guessing
 shaa-h-yayer)?

 I look forward to your work on Flow; it's a super important project.
 Thanks!

 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation


 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Request for comments: Localisation format changes

[Arthur Richards]

Cool!

On Thu, Dec 12, 2013 at 10:34 AM, Siebrand Mazeland (WMF) 
smazel...@wikimedia.org wrote:

 We have also proposed to discuss this RfC in the upcoming RfC review
 meeting of 2013-12-18[1]. As far as we know, no time has been set for this
 meeting, yet.


The WMF Engineering calendar shows the RfC review meeting at 2-3pm PST on
2013-12-18.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Redirecting obsolete mobile. and wap. domains

[Arthur Richards]

On Thu, Dec 5, 2013 at 1:23 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote:

 This morning Faidon has deployed a
 patch
 https://gerrit.wikimedia.org/r/#/c/99394/1/templates/varnish/mobile-frontend.inc.vcl.erb
 to
 redirect wap.and mobile. subdomains (see also this
 patch https://gerrit.wikimedia.org/r/#/c/98058 for the apache side
 handling), but later due to some cencerns the change has been reverted.

 Are there any reasons for us to keep the current wap  mobile subdomains
 handling, or everyone is ok with obsoleting them this way?


Do we have any idea how much traffic is hitting the wap. and mobile.
subdomains right now?


-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Arthur Richards]

On Tue, Nov 5, 2013 at 6:57 PM, Erik Moeller e...@wikimedia.org wrote:


 Option D: We come up with some kind of open process for
 designating/confirming folks as architects, according to some
 well-defined criteria (including minimum participation in the RFC
 process, well-defined domain expertise in certain areas, a track
 record of constructive engagement, etc.). Organizations like WMF can
 choose to recognize this role as they see fit (likely according salary
 increases to individuals who demonstrate successful architectural
 leadership), but it’s a technical leadership role that’s awarded by
 Wikimedia’s larger technical community, similar to +2 status.


I think there's room for this to be hybridized with the existing 'Lead %s
Architect' titles/roles, whereby the architects architect and the 'leads'
steward that process. This seems to me like a sensible way forward. Right
now, the architecting/RFC cabal is 'Senior Software Engineers' and others;
but not every Senior Software Engineer may want responsibilities of being
an 'architect' and the technical distinctions for what makes someone a
'Senior Software Engineer' rather than a 'Software Engineer' are not
totally clear.

One thing that we touched on during Tech Days was the notion that titles
are independent of roles - perhaps the 'architect' designation is more of a
role that can be occupied by Sr Software Engineers, people not on staff,
etc, with some clearly defined responsibilities as well as criteria for
occupying the role.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Arthur Richards]

On Tue, Nov 5, 2013 at 7:07 PM, Chad innocentkil...@gmail.com wrote:

 I'm in favor of option (C), mainly because I think that titles are
 pointless and
 lead to hat collecting and hurt feelings.


Titles are useful for a few things:
* Prospects of future employment
* Clarity around who to talk to about what


 I respect Brion, Mark and Tim (and
 many others) as architects because they *are* architects, not because we
 call them such.


We call them such, because they are such - it is a useful designation.


 For RFCs, I've been of the opinion we've made them entirely too formal. I'm
 glad we're trying to move them forward, but I've always thought they should
 be based on community consensus, not convincing an architect.


Generally agreed, although I think this is more of a procedural point and
perhaps orthogonal to roles/titles and what they mean.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Optimizing the deployment train schedule

[Arthur Richards]

On Fri, Oct 18, 2013 at 6:41 PM, MZMcBride z...@mzmcbride.com wrote:

 Though everyone to have commented here so far (myself included) don't
 deploy code or help fix the bugs that arise after (not directly, anyway).
 I'd be most interested to hear from Sam, Arthur, Max, Greg, et al. (the
 people on https://wikitech.wikimedia.org/wiki/Deployments) about how the
 deployments process(es) are working.


Personally, I do not have a strong opinion about this yet. The mobile web
team just got on the deployment train two weeks ago (previously we managed
our own weekly deployments that went out cluster-wide), so it feels too
early for me have a sense of what works well/doesn't as we're still working
out some internal kinks and getting used to the new rhythm. That said,
'option c' seems really sensible to me - it would be nice to have the extra
working day to address issues that cropped up on the testwikis before
pushing changes out to the non-wikipedia wikis.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Product] Bugs on the deployment train

[Arthur Richards]

+teampractices and wikitech-l for more input


On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards
aricha...@wikimedia.orgwrote:

 I generally agree with James'/VE's approach. I'm not sure we can
 reasonably come up with a sound metric (eg 'degredation that affects
 roughly one percent of users') as it may not always be easily measurable. I
 think a gut-check, qualitative assessment should suffice for these kinds of
 issues, and can probably be broken into a few buckets:

 *) critical functionality is BROKEN (eg edits are not being saved, article
 content is not accessible), there is a security concern, or a legal issue -
 this needs to be fixed ASAP, like possibly before the next lightning deploy
 *) semi-critical functionality is broken but doesn't impede basic usage of
 critical site components (imo: reading, editing [in that order]) - (eg the
 watchlist star on an article doesn't accurately indicate if an article is
 being watched) - fixed and backported with earliest possible lightning
 deploy window
 *) annoyances (styling not quite right, obscure javascript errors),
 non-security/legal issues in beta/alpha versions - fixed with next
 deployment train

 This has generally been our approach to date on the mobile web team,
 although I don't think we've ever been explicit about a rubric.


 On Tue, Oct 15, 2013 at 1:53 PM, James Forrester jforres...@wikimedia.org
  wrote:

 Kenan,

 For VE we backport (cherry pick) fixes of major issues ASAP (generally by
 grabbing the next available Lightning Deploy window after we've tested it),
 but for inconveniences (i.e., things not quite as intended but still
 workable, or only affecting a few users) we generally just go for the next
 week's deployment train instead. Otherwise, yeah, they just join the
 backlog.

 J.


  On 15 October 2013 13:49, Kenan Wang kw...@wikimedia.org wrote:

  Hey,

 The mobile team just got onto the deployment train. We're currently
 looking to understand what we do when we find bugs caused by the previous
 release during the deployment train. I proposed a three tiered triage
 system to my team:

 Current train: degradation that affects roughly one percent of users in
 a noticeable way
 Current iteration, next train: degradation that affects less than one
 percent of users in a noticeable way
 Backlog: degradation that affects less than .1 percent of users in a
 noticeable way, or affects users in a cursory way

 But was wondering if there were any other systems that teams had in
 place to deal with this issue.

 Also, if you fix a bug does your team typically deploy during the next
 deployment window available or do you wait to deploy until you have a
 couple of fixes?

 --

 Kenan Wang
 Product Manager, Mobile
 Wikimedia Foundation

 ___
 Wmfproduct mailing list
 wmfprod...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfproduct




 --
 James D. Forrester
 Product Manager, VisualEditor
 Wikimedia Foundation, Inc.

 jforres...@wikimedia.org | @jdforrester




 --
 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Meet Bingle and Bugello

[Arthur Richards]

Ergh no not yet, although during the hackathon at Wikimania, Diederik and I
made some big changes in Bingle to use Bugzilla's jsonrpc api, which opens
a lot of doors for new cool things. I'm planning to write a blog post about
it in the coming weeks - I'll work with Diederik to come up with a
potential roadmap beforehand.


On Thu, Sep 19, 2013 at 7:56 AM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 On 06/20/2013 09:37 AM, Brion Vibber wrote:
  On Jun 20, 2013 9:26 AM, Arthur Richards aricha...@wikimedia.org
 wrote:
 
  On Wed, Jun 19, 2013 at 4:39 PM, Andre Klapper aklap...@wikimedia.org
  wrote:
 
 
  Is there any kind of Roadmap file that lists stuff that you think would
  be great to get fixed next or other random ideas, for potential
 drive-by
  contributors on GitHub?
 
 
  Not yet, but good idea! I'll get something up.
 
  Another thing to put on that list is Yuvi's bot for  GitHub pull requests
  to gerrit. We're starting to use this on the android Commons app, and
 it's
  pretty sweet!
 
  -- brion
 
  --
  Arthur Richards
  Software Engineer, Mobile
  [[User:Awjrichards]]
  IRC: awjr
  +1-415-839-6885 x6687
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 

 Hey Arthur, did you end up putting together a roadmap? :-)

 --
 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] [Analytics] Mobile stats

[Arthur Richards]

That's awesome - thanks Max and Adam; it's great to see the last vestiges
of X-Device finally disappear!


On Tue, Sep 17, 2013 at 1:07 PM, Max Semenik maxsem.w...@gmail.com wrote:

 After looking at Varnish VCL with Adam, we discovered a bug in regex
 resulting in many phones being detected as WAP when they shouldn't be.
 Since the older change[1] simplifying detection had also fixed this bug,
 Brandon Black deployed it and since today the usage share of WAP should
 seriously drop. We will be monitoring the situation and revisit the issue
 of WAP popularity once we have enough data.

 [1] https://gerrit.wikimedia.org/r/83919

 On Tue, Sep 10, 2013 at 4:39 PM, Adam Baso ab...@wikimedia.org wrote:

 Thanks. 7-9% of responses on Wikipedia Zero being WAP is pretty
 substantial.


 On Tue, Sep 10, 2013 at 2:01 PM, Andrew Otto o...@wikimedia.org wrote:

  These
  zero.tsv.log*
  files to which I refer seem to be, basically Varnish log lines that
  correspond to Wikipedia Zero-targeted traffic.
 Yup!  Correct.  zero.tsv.log* files are captured unsampled and based on
 the presence of a zero= tag in the X-Analytics header:


 http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612df8779e9a3bdb69066b2/templates%2Fudp2log%2Ffilters.oxygen.erb#L10

  Do I understand correctly that field as Content-Type?
 Yup again!  The varnishncsa format string that is currently being beamed
 at udp2log is here:


 http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612df8779e9a3bdb69066b2/modules%2Fvarnish%2Ffiles%2Fvarnishncsa.default



 --
 Best regards,
 Max Semenik ([[User:MaxSem]])

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Roadmap updates - Sept 6th, 2013

[Arthur Richards]

On Mon, Sep 16, 2013 at 10:55 AM, Erik Moeller e...@wikimedia.org wrote:

 Like you, I'd argue in favor of scrapping the roadmap as it exists
 today, but I think we should do a better job making the Deployments
 page more informative. For example, now that we're working towards a
 proper beta mode on mobile _and_ desktop, it would IMO be useful to
 summarize which features are currently in beta and planned to enter
 production soon. We still have too many situations where people are
 caught by surprise by a deployment, both internally and externally.


The mobile web team has been trying to summarize what's going out in our
weekly deployments:
https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments

We've found this tremendously useful both from a pre- and post- deployment
perspective. Michelle Grover has been doing some work around automating the
generation of these reports, though I believe it's still a WIP.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Introducing the 'team practices' mailing list

[Arthur Richards]

There is now a new 'teampractices' mailing list to publicly discuss team
practices and processes in Wikimedia organizations (WMF, WMDE, etc), with a
focus on software engineering practices and methods, such as agile
methodologies.

If you are at all interested in discussing such things - including best
practices, looking for support for coping with some obstacle, are
agile-curious you should sign up:
https://lists.wikimedia.org/mailman/listinfo/teampractices

The idea for this list was born during a scrummaster meetup at Wikimania
2013 while trying to figure out ways we can better support one another in
managing our team processes, and was further reinforced at the 'Team
Practices' workshop during Tech Days 2013 as a means to continue
collaboratively shaping best practices amongst our teams.

So, hop on board and help us continue to discover better ways to get stuff
done!


PS I've sent this to the wmf staff list and wikitech-l. If there's anywhere
else you feel this is appropriate to post, of course please do so :)
-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] [Analytics] Mobile stats

[Arthur Richards]

Would adding the accept header to the x-analytics header be worthwhile for
this?
On Sep 5, 2013 4:16 AM, Erik Zachte ezac...@wikimedia.org wrote:

 For a breakdown per country, the higher the sampling rate the better, as
 the data will become reliable even for smaller countries with a not so
 great adoption rate of Wikipedia.

 -Original Message-
 From: analytics-boun...@lists.wikimedia.org [mailto:
 analytics-boun...@lists.wikimedia.org] On Behalf Of Max Semenik
 Sent: Thursday, September 05, 2013 12:28 PM
 To: Diederik van Liere
 Cc: A mailing list for the Analytics Team at WMF and everybody who has an
 interest in Wikipedia and analytics.; mobile-l; Wikimedia developers
 Subject: Re: [Analytics] [WikimediaMobile] Mobile stats

 On 05.09.2013, 4:04 Diederik wrote:

  Heya,
  I would suggest to at least run it for a 7 day period so you capture
  at least the weekly time-trends, increasing the sample size should
  also be recommendable. We can help setup a udp-filter for this purpose
  as long as the data can be extracted from the user-agent string.

 Unfortunately, accept is no less important here.
 So, to enumerate our requirements as a result of this thread:
 * Sampling rate the same as wikistats (1/1000).
 * No less than a week worth of data.
 * User-agent:
 * Accept:
 * Country from GeoIP to determine the share of developing countries.
 * Wiki to determine if some wikis are more dependant on WAP than other
   ones.

 Anything else?

 --
 Best regards,
   Max Semenik ([[User:MaxSem]])


 ___
 Analytics mailing list
 analyt...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/analytics


 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] [Analytics] Mobile stats

[Arthur Richards]

Thanks Max for digging into this :)

I'm no analytics guy, but I am a little concerned about the sample size and
duration of the internal logging that we've done - sampling 1/1 for
only a few days for data about something we generally know usage to already
be low seems to me like it might be difficult to get accurate numbers. Can
someone from the analytics team chime in and let us know if the approach is
sound and if we should trust the data Max has come up with? This has big
implications as it will play role in determining whether or not we continue
supporting WAP devices and providing WAP access to the sites.

Thanks everyone!


On Tue, Sep 3, 2013 at 10:40 AM, Erik Zachte ezac...@wikimedia.org wrote:

 Sadly you need to take squid log based reports with a grain of salt.
 Several incomplete maintenance jobs have taken their toll.

 Each report starts with a long list of unsolved bugs.
 Among those https://bugzilla.wikimedia.org/show_bug.cgi?id=46273

 So yeah better trust your own data.

 Erik


 -Original Message-
 From: analytics-boun...@lists.wikimedia.org [mailto:
 analytics-boun...@lists.wikimedia.org] On Behalf Of Max Semenik
 Sent: Tuesday, September 03, 2013 5:33 PM
 To: analyt...@lists.wikimedia.org; Wikimedia developers; mobile-l
 Subject: [Analytics] Mobile stats

 Hi, I have a few questions regarding mobile stats.

 I need to determine a real percentage of WAP browsers. At first glance,
 [1] looks interesting: ratio of text/html to text/vnd.wap.wml is 92M /
 3987M = 2.3% on m.wikipedia.org. However, this contradicts the stats at
 [2] which have different numbers and a different ratio.

 I did my own research: because during browser detection in Varnish WAPness
 is detected mostly by looking at accept header and because our current
 analytics infrastructure doesn't log it, I quickly whipped up a code that
 recorded user-agent and accept of every 10,000th request for mobile page
 views hitting apaches.

 According to several days worth of data, out of 14917 logged requests
 1445 contained vnd.wap.wml in Accept: headers in any form. That's more
 than what is logged for frontend responses, however it is expected as WAP
 should have worse cache hit rate and thus should hit apaches more often.

 Next, our WAP detection code is very simple: user-agent is checked against
 a few major browser IDs (all of them are HTML-capable and this check is not
 actually needed anymore and will go away soon) and if still not known, we
 consider every device that sends Accept:
 header vnd.wap.wml (but not application/vnd.wap.xhtml+xml), to be
 WAP-only. If we apply these rules, we get only 68 entries that qualify as
 WAP which is 0.05% of all mobile requests.

 The question is, what's wrong: my research or stats.wikimedia.org?

 And if it's indeed just 0.05%, we should probably^W definitely kill WAP
 support on our mobile site as it's virtually unmaintained.

 -
 [1] http://stats.wikimedia.org/wikimedia/squids/SquidReportRequests.htm
 [2] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm



 --
 Best regards,
   Max Semenik ([[User:MaxSem]])


 ___
 Analytics mailing list
 analyt...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/analytics


 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Welcoming Sucheta Ghoshal

[Arthur Richards]

Welcome, Sucheta :)


On Tue, Sep 3, 2013 at 10:45 AM, Pratik Lahoti pr4tiklah...@gmail.comwrote:

 Hearty Congratulations Sucheta! Wish you all the very best! :)


 On Tue, Sep 3, 2013 at 10:29 PM, Alolita Sharma asha...@wikimedia.org
 wrote:

  Hi everyone,
 
  Please join me in welcoming Sucheta Ghoshal as associate software
 engineer
  in the Language Engineering team. Sucheta will be working on
  internationalization and localization features for Wikimedia sites as
 well
  as maintaining other language engineering software using Javascript,
  related libraries as well as Mediawiki.
 
  Sucheta loves to code! She has been contributing to MediaWiki as a
  volunteer developer for more than a year. She has been working on
 Language
  Coverage Matrix visualizations and contributed to EtherEditor as an
 intern
  in the Outreach Program for Women (OPW) earlier this year. She also
  participated in the Open Source Language Summit in Pune in February 2013.
  Sucheta has been an open source contributor since high school and
 actively
  contributed to various open source projects including Fedora and Mozilla.
  She has been an active Wikimedian contributing in Bengali and has
  participated as a member of Wikimedia Kolkata for over 3 years now.
 Sucheta
  also claims to be a bookworm, cine buff and musician in her spare time.
 
  She can be reached on email at sghoshal at wikimedia.org or as ‘sucheta’
  on
  our irc channels including #mediawiki, #wikimedia-dev and
 #mediawiki-i18n.
 
  Welcome Sucheta! I am excited to have you on the language engineering
 team!
 
  -Alolita
 
  --
  Alolita Sharma
  Director of Engineering
  Language Engineering (i18n/L10n)
  Wikimedia Foundation
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l




 --
 Warm Regards,
 *Pratik Lahoti*
 User:BPositive http://en.wikipedia.org/wiki/User:BPositive

 *Speak less, work more*
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Is there a way to let mediawiki support jquery mobile?

[Arthur Richards]

Shawn, to clarify - are you trying to create an Android app for your site
or are you hoping to provide a more mobile-friendly experience for folks
browsing your website on mobile devices?

Folks from the mobile apps team (Yuvi?) can probably give you better
insight if you're trying to create an app. If you'd like to create a
mobile-friendly browsing experience for your users, you might try
installing the MobileFrontend extension to Mediawiki and configuring device
detection to your needs:
http://www.mediawiki.org/wiki/Extension:MobileFrontend


On Tue, Sep 3, 2013 at 8:56 AM, XIAO Qingjun csqjx...@gmail.com wrote:

 Hi, all

 I am trying to add some jquery mobile components to my wiki site, to give
 it a more beautiful look on Android app. The app is the official mediawiki
 mobile client, which can be downloaded from the following link.
 https://github.com/wikimedia/**WikipediaMobilehttps://github.com/wikimedia/WikipediaMobile

 Now, there is no problem for me to include the jquery mobile javascript
 and css to this little phonegap-based project. If the contents grabbed from
 the mediawiki website (by mobilefrontend) contains jquery mobile
 components, they can be shown properly on my android phone.

 However, the wiki site look quite different if it is accessed from a PC.
 All the jquery mobile contents do not load properly. So I added the
 jquery.mobile-1.3.2.min.js to mediawiki common.js, and the
 jquery.mobile-1.3.2.min.css to mediawiki common.css. But the whole site
 looks a mess. All the buttons and links are shown as jquery mobile buttons,
 and cannot be clicked. I wonder whether there is a graceful method to apply
 the jquery.mobile js and css just to the wiki contents (in particular, to
 div#content), without affecting the surrounding parts, like the edit page
 button, save page button, etc.

 Thanks for casting some light onto this issue.

 Best
 Shawn

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Welcoming Kartik Mistry

[Arthur Richards]

Welcome, Kartik :D


On Tue, Sep 3, 2013 at 9:59 AM, Quim Gil q...@wikimedia.org wrote:

 On 09/03/2013 09:52 AM, Alolita Sharma wrote:

 Kartik is well known in India’s open source community for his many
 contributions to Debian. He has been a Debian developer and package
 maintainer since August 2008 and has contributed deeply to
 internationalization and localization of various packages and Debian
 installer for Gujarati. Kartik actively maintains about 45 packages for
 Debian including aspell-gu, fortune-debian-hints, nginx as well as Aakar,
 Rekha and Kalapi fonts for Gujarati. He is a Wikipedian actively
 contributing in Gujarati and English as well as on Commons. He also
 contributes as a MediaWiki localizer through translatewiki.net.


 Respect! Full-time-welcome, Kartik.

 --
 Quim Gil
 Technical Contributor Coordinator @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil


 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OxygenGuide (Wikivoyage offline): Android app seeking new maintainer

[Arthur Richards]

+mobile-l


On Wed, Aug 21, 2013 at 1:15 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 (I'd love a forward to offline-l and mobile-l.)


 https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#OxygenGuide_.28offline_Wikivoyage.29_updated.21

 http://code.google.com/p/oxygenguide

 OxygenGuide is Wikivoyage in the form of simple HTML files. No images.
 Must-have on your smartphone or travel laptop. Whole world in 90MB.

 I created an Android app but haven't much time to maintain/improve it, I
 am looking for a new maintainer, anyone interested? It can be a fun
 project for someone who is starting to learn Android development, so
 don't hesitate :-)

 Some help would also be welcome to enhance the algorithm which
 transforms Wikivoyage wikicode into simple HTML.

 --
 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FOSDEM: main tracks and developer rooms

[Arthur Richards]

We've talked in the past about hosting a Wikimedia dev room or table for
FOSDEM, but never got our acts together to apply. I think we should
*totally* apply for a wiki devroom this year - FOSDEM is one of the best
conferences I've ever been to, and especially given our wiki-representation
in Europe, there are a million reasons why we should have a strong presence
there. Let's do it!


On Wed, Aug 21, 2013 at 1:00 AM, Quim Gil q...@wikimedia.org wrote:

 FOSDEM will take place on 1 and 2 February 2014 in Brussels. Now it's the
 time to apply for DevRooms and main track sessions.

 https://fosdem.org/2014/news/**2013-08-06-call-for-**participation/https://fosdem.org/2014/news/2013-08-06-call-for-participation/

 Key dates:

 15 September
 * deadline for developer room proposals

 1 October
 * deadline for main track proposals
 * accepted developer rooms announced

 I think Wikimedia needs FOSDEM and FOSDEM needs Wikimedia. We could
 mobilize European developers and tech-friendly chapters to work on a
 combined outreach action.

 First things first: proposing a Wiki DevRoom. What do you think? Note that
 it's Wiki, not just Wikimedia or MediaWiki.

 We should also brainstorm what are the best main track session candidates.

 --
 Quim Gil
 Technical Contributor Coordinator @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Session cookie name

[Arthur Richards]

Head's up that this has broken login for mobile - the varnish conf for
mobilefrontend needs to be updated:
https://gerrit.wikimedia.org/r/#/c/79837/


On Mon, Aug 19, 2013 at 9:14 PM, Tim Starling tstarl...@wikimedia.orgwrote:

 Please note that the session cookie name on WMF wikis has changed from
 wiki_session to wikiSession. That is, for example, enwiki_session
 to enwikiSession.

 This was done in response to a security issue -- we had to find some
 way to rapidly cause all session IDs to be regenerated. Changing the
 cookie name was the simplest way to achieve that. More details should
 become available once we are sure that the security issue is fixed.

 -- Tim Starling


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] PHPUnit tests fail from Jenkins but work fine locally

[Arthur Richards]

Mobile web is trying to merge https://gerrit.wikimedia.org/r/#/c/69585/ but
PHPUnit tests are failing when Jenkins executes them.

What's weird is that we've executed PHPUnit tests on our various local
machines - with no failures. We've been scratching our heads trying to
figure out what might be causing the inconsistency.

Anyone have any ideas what might be causing this?

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Fwd: Number crunching: Upload errors on mobile

[Arthur Richards]

Nice work! Resolving the bad filename issue should get us down to a much
more acceptable error rate.


On Fri, Jun 21, 2013 at 3:19 PM, Jon Robson jdlrob...@gmail.com wrote:

 Update on error numbers:

 111 errors since we pushed the fix on Tuesday 2pm to avoid anonymous token
 problems.

 Things are looking much better and come under 3 types of error
 Here is the new breakdown

 1) Errors due to bad filenames / bad filetypes

 Missing filename: Bad filename 67
  This is now the biggest cause of errors. I suggest we log the file names
 users are trying to upload with to identify what is going wrong. A bug is
 open https://bugzilla.wikimedia.org/show_bug.cgi?id=49544

 There are various other errors which are probably not worth our time as
 they suggest vandal edits:

 This file did not pass file verification 4
 Unknown error: titleblacklist-forbidden-edit 5
 Unknown error: titleblacklist-custom-filename 1
 Missing filename: Filename exists 1
 Missing filename: Duplicate archive 1
 Filetype not permitted: MOV 1
  The file type not permitted errors could be solved by checking the image
 in preview mode correctly loaded and whether it has a width that isn't 0.

 2) Errors due to tokens


 Bad token name. 15
  These have all occurred on en.m.wikipedia.org, ru.m.wikipedia.org and
 meta.m.wikimedia.org
  5 of them were on the uploads page
 Investigating with Chris it seems this can happen when a user has logged
 in on mobile, left the page for some time and thus their login has expired.
 Requesting a central auth token without being logged in will cause this
 error. We should explore checking login status before starting the upload
 workflow and redirect the user to the login page.

 Invalid token 5
  We are caching tokens that have since expired. We should explore
 invalidating tokens.

 3) Other errors
 These bugs are all pretty mysterious and it's not clear what causes them

 * The modification you tried to make was aborted by an extension hook 7
 * error: 3
  Note This occurs when an error happens but the error is missing an
 'info' property.
 e.g. the response is:
 { error: {} }

 An internal error occurred 1


 On Sat, Jun 8, 2013 at 3:49 PM, Max Semenik maxsem.w...@gmail.com wrote:
  On 08.06.2013, 21:07 Brian wrote:
 
 
  I suspect that is caused by UploadBlacklist extension, which
  blacklists about 23 files by their sha hash. According to the config
  file, there's a log at udp://$wmfUdp2logDest/upload-blacklist, so
  you can probably check if that guess is right.
 
  $ grep -v 'MISS' upload-blacklist.log
  $
 
  --
  Best regards,
  Max Semenik ([[User:MaxSem]])
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 --
 Jon Robson
 http://jonrobson.me.uk
 @rakugojon

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Videos on mobile

[Arthur Richards]

+wikitech-l

This sounds like something that might be good for the newly forming
multimedia team to work on. As Yuvi pointed out (off the wikitech-l list):

There are also unresolved codec issues with playing videos (no H264
support), so even if we do enable video playback it'll not be
available everywhere, and even in places where it is it is going to be
a biggish battery sink (no hardware decoding support). Would want to
consider that before enabling it fully.

I envision the mobile team helping to support this, but folks who focus on
multimedia-related stuff would probably be the best candidates for digging
into this and figuring out how we can best move forward.


On Thu, Jun 20, 2013 at 6:16 PM, Jon Robson jdlrob...@gmail.com wrote:

 I would like to see videos working on mobile

 Yet there seems to be two issues here.
 1)  Cleaning up MobileFrontend code
 We are stripping the ogg_player by parsing and cleaning up the HTML
 We could probably do this in css/javascript instead.

 2) Making videos work on mobile where supported
 If we were to explore enabling videos on mobile we would have to look
 at the ogg player javascript code associated with it and get it
 working on mobile or create our own code that knows how to read it.
 http://www.mediawiki.org/wiki/Extension:OggHandler

 I'm also concerned about the size of the javascript module and since
 it is not needed by every page I would argue that it should only be
 loaded when the video is clicked (the existing extension may do this
 or not I'm not clear):

 https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FOggHandler/895f74e63fa9cadeba1df63604b0aaeae10f803c/OggPlayer.js


 On Thu, Jun 20, 2013 at 5:35 PM, Max Semenik maxsem.w...@gmail.com
 wrote:
  Hi, when mobile WP was in its childhood, it was decided that we're not
  ready to display videos on our pages, so they were stripped. And
  stripped very crudely, by removing just #ogg_player_1 and
  #ogg_player_2 so that only first two videos on a page were removed.
  What are your opinions - shoudld we continue doing this?
 
 
 
  --
  Best regards,
Max Semenik ([[User:MaxSem]])
 
 
  ___
  Mobile-l mailing list
  mobil...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/mobile-l



 --
 Jon Robson
 http://jonrobson.me.uk
 @rakugojon

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Videos on mobile

[Arthur Richards]

+wikitech-l


On Mon, Jun 24, 2013 at 11:37 AM, Brion Vibber bvib...@wikimedia.orgwrote:

 On Thu, Jun 20, 2013 at 5:35 PM, Max Semenik maxsem.w...@gmail.comwrote:

 Hi, when mobile WP was in its childhood, it was decided that we're not
 ready to display videos on our pages, so they were stripped. And
 stripped very crudely, by removing just #ogg_player_1 and
 #ogg_player_2 so that only first two videos on a page were removed.
 What are your opinions - shoudld we continue doing this?


 So, here's the thing -- we've dropped OggHandler and switched to
 TimedMediaHandler which outputs its markup differently -- the new system is
 not stripped by MobileFrontend!

 Videos used in the wikis today actually output a video element pointing
 by default to a WebM source. These *actually work* in Chrome and Firefox
 on Android... but iOS and other non-Android systems will generally not have
 WebM support and will show a broken video placeholder.

 We're still kinda talking internally about license issues for H.264
 support... whee

 -- brion

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Meet Bingle and Bugello

[Arthur Richards]

On Wed, Jun 19, 2013 at 4:39 PM, Andre Klapper aklap...@wikimedia.orgwrote:


 Is there any kind of Roadmap file that lists stuff that you think would
 be great to get fixed next or other random ideas, for potential drive-by
 contributors on GitHub?


Not yet, but good idea! I'll get something up.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs

[Arthur Richards]

Max Semenick prepared a patchset that would make it possible to keep
Mediawiki:Common.css and friend in sync between enwiki in production, and
enwiki on betalabs, but it needs review and merge:
https://gerrit.wikimedia.org/r/#/c/68309/

One of the big challenges in deploying MobileFrontend changes to production
is the unexpected ways Mediawiki:Common.css and friends will affect our
changes. In general, the mobile web team has been trying to get betalabs to
a state that mimics production closely enough that we can reliably test our
changes there for all the weird things that can happen in the production
environment - before pushing our changes to production. As such, it would
be enormously helpful if we had a way to keep Mediawiki:Common.css and
friends in sync between enwiki in production and enwiki on betalabs.

So, can someone please take a look? It would be enormously helpful for us
to get this in place as soon as possible.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Meet Bingle and Bugello

[Arthur Richards]

I wrote a tool that will import bugs from Bugzilla into either Mingle
and/or Trello (two project management tools used by some teams at the
Wikimedia Foundation). The mobile web team was finding it difficult to keep
track of two separate tools - one for new feature development, the other
for tracking bugs, so Bingle helps bridge the gap and allows us to focus on
one tool. This has had the side effect of keeping visibility of reported
bugs high and has made it easier for us to quickly prioritize incoming bugs
against existing work, and quickly respond to open issues.

You can find the code and some rudimentary usage instructions here:
https://github.com/awjrichards/bingle

I hacked this together rather quickly - expedience was my goal rather than
perfection, so it's not well documented, a little quirky, and there's a lot
of room for improvement. I've been sitting on it for a while, hoping to
make improvements before announcing it, but I have not found the time to
make the changes I would like (eg for it to use the Bugzilla API rather
than Bugzilla atom feeds). So, I invite anyone interested and willing to
fork it, and pitch in and help make it awesome :)

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs

[Arthur Richards]

Thanks everyone who helped get that merged :)


On Tue, Jun 18, 2013 at 11:02 AM, Arthur Richards
aricha...@wikimedia.orgwrote:

 Max Semenick prepared a patchset that would make it possible to keep
 Mediawiki:Common.css and friend in sync between enwiki in production, and
 enwiki on betalabs, but it needs review and merge:
 https://gerrit.wikimedia.org/r/#/c/68309/

 One of the big challenges in deploying MobileFrontend changes to
 production is the unexpected ways Mediawiki:Common.css and friends will
 affect our changes. In general, the mobile web team has been trying to get
 betalabs to a state that mimics production closely enough that we can
 reliably test our changes there for all the weird things that can happen in
 the production environment - before pushing our changes to production. As
 such, it would be enormously helpful if we had a way to keep
 Mediawiki:Common.css and friends in sync between enwiki in production and
 enwiki on betalabs.

 So, can someone please take a look? It would be enormously helpful for us
 to get this in place as soon as possible.

 --
 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ZERO architecture

[Arthur Richards]

I'm excited to see this all moving forward! I think there are potential
boons for regular mobile AND zero experiences in here. Responses inline
below.

On Thu, May 30, 2013 at 10:16 AM, Yuri Astrakhan
yastrak...@wikimedia.orgwrote:

 *== Proposals ==*
 In order to reduce Zero-caused fragmentation, we propose to shrink from one
 bucket per carrier (X-CS) to three general buckets:
 * smart phones bucket -- banner and site modifications are done on the
 client in javascript


For smart devices (more than just phones!), is there any reason you'd need
serve different HTML than what is already being served by MobileFrontend?
Note that there would need to be one bucket for HTML with images, another
for without (as currently is the case for smartphones accessing
MobileFrontend). Are there 'site modifications' that Zero needs to do that
are different from MobileFrontend?


 * feature phones -- HTML only, the banner is inserted by the ESI
 ** for carriers with free images
 ** for carriers without free images


What about including ESI tags for banners for smart devices as well as
feature phones, then either use ESI to insert the banner for both device
types or, alternatively, for smart devices don't let Varnish populate the
ESI chunk and instead use JS to replace the ESI tags with the banner? That
way we can still serve the same HTML for smart phones and feature phones
with images (one less thing for which to vary the cache).

Are there carrier-specific things that would result in different HTML for
devices that do not support JS, or can you get away with providing the same
non-js experience for Zero as MobileFrontend (aside from the
banner, presumably handled by ESI)? If not currently, do you think its
feasible to do that (eg make carrier-variable links get handled via special
pages so we can always rely on the same URIs)? Again, it would be nice if
we could just rely on the same HTML to further reduce cache variance. It
would be cool if MobileFrontend and Zero shared buckets and they were
limited to:

* HTML + images
* HTML - images
* WAP

Out of curiosity, is there WAP support in Zero? I noticed some comments
like '# WAP' in the varnish acls for Zero, so I presume so. Is the Zero WAP
experience different than the MobileFrontend WAP experience?

Since we improved MobileFrontend to no longer vary the cache on X-Device,
I've been surprised to not see a significant increase in our cache hit
ratio (which warrants further investigation but that's another email). Are
there ways we can do a deeper analysis of the state of the varnish cache to
determine just how fragmented it is, why, and how much of a problem it
actually is? I believe I've asked this before and was met with a response
of 'not really' - but maybe things have changed now, or others on this list
have different insight. I think we've mostly approached the issue with a
lot more assumption than informed analysis, and if possible I think it
would be good to change that.



 *=== Varnish logic ===*
 * Parse User-Agent to distinguish between desktop / mobile / feature phone:
 X-Device-Type=desktop|mobile|legacy


What is 'legacy'? Why would you ever set X-Device-Type to 'desktop'? We
already have decent device detection at the Varnish layer for
MobileFrontend, however the devices aren't bucketed quite the way I think
you'll need - but that should be straightforward to add into or along side
the existing device detection.


 ...


 *=== ZERO vs M ===*
 ...
 In  general, we should manipulate image links in M for carriers who don't
  allow them, and always redirect ZERO to M unless M is not whitelisted,  in
 which case convince carrier to change their whitelist.


What do you mean by 'manipulate image links in M'? Do you mean just don't
display images (like currently happens) when images are disabled (X-Images:
No)?

I dont think this should be a big deal especially if we can determine the
value of X-Images for specific carriers at the Varnish level rather than at
the application level - unless you're suggesting that something else needs
to happen with image links.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Need help with a Jenkins PHPUnit build failure

[Arthur Richards]

In trying to submit https://gerrit.wikimedia.org/r/#/c/63907/18, I get a
Jenkins build failure due to PHPUnit failing, due to a Fatal being thrown:
https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-testextensions-master/898/console

The fatal:

PHP Fatal error:  Class 'MFMockRevision' not found in
/srv/ssd/jenkins/workspace/mwext-MobileFrontend-testextensions-master/extensions/MobileFrontend/tests/MobileContextTest.php
on line 500


The thing is, 'MFMockRevision' should be made available by it's file
being included in efExtMobileFrontendUnitTests() (our hook handler for
UnitTestsList.


Unit tests execute fine for me and at least one other person on the
mobile team. I do not want to manually merge that patchset since I
imagine it would cause build failures on subsequent patchset +2's.
Anyone know what might be going on?


-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Need help with a Jenkins PHPUnit build failure

[Arthur Richards]

On Thu, May 23, 2013 at 1:59 PM, Arthur Richards aricha...@wikimedia.orgwrote:

 In trying to submit https://gerrit.wikimedia.org/r/#/c/63907/18, I get a
 Jenkins build failure due to PHPUnit failing, due to a Fatal being thrown:

 https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-testextensions-master/898/console

 The fatal:

 PHP Fatal error:  Class 'MFMockRevision' not found in 
 /srv/ssd/jenkins/workspace/mwext-MobileFrontend-testextensions-master/extensions/MobileFrontend/tests/MobileContextTest.php
  on line 500


 The thing is, 'MFMockRevision' should be made available by it's file being 
 included in efExtMobileFrontendUnitTests() (our hook handler for 
 UnitTestsList.


 Unit tests execute fine for me and at least one other person on the mobile 
 team. I do not want to manually merge that patchset since I imagine it would 
 cause build failures on subsequent patchset +2's. Anyone know what might be 
 going on?


 --
 Arthur Richards
 Software Engineer, Mobile
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687


After some digging it became obvious that adding classes that are not test
cases using 'UnitTestsList' just doesn't work since PHPUnit will only
actually add the files that contain test cases. I instead tried using
$wgAutoloadClasses inside of efExtMobileFrontendUnitTests() to load the
extra helper class, but that didn't seem to work either :( Ultimately, I
rewrote how the tests work and merged the helper class into the same file
containing the test case that relied on it. But for the future, is there a
better way to include arbitrary, non-PHPUnit test case classes in test runs?

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

[Arthur Richards]

This might be something that would be better suited for Echo rather than
talk page notifications.


On Thu, May 9, 2013 at 9:26 AM, Guillaume Paumier gpaum...@wikimedia.orgwrote:

 On Thu, May 9, 2013 at 6:20 PM, Guillaume Paumier
 gpaum...@wikimedia.org wrote:
 
  Perhaps using email subjects starting with Please relay: foo would
  be a first step, but I don't expect it to be enough. I'm open to
  suggestions about how to increase that ratio :)

 Another possibility would be (if we set up that mailing-list-to-wiki
 bot) to test whether people who get the message on their talk page
 relay it more than people who get it via email.

 (My intuition would be yes, because they're already in the wiki
 activity and not in the email one, but perhaps I'm just projecting
 my own personal processes here.)

 --
 Guillaume Paumier

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Purging parts of varnish cache

[Arthur Richards]

Previously we had spoken about implementing partial page caching (ESI) for
Zero so we could remove X-CS variance for article content and use it only
for partner banners. Is this still being pursued?


On Wed, May 8, 2013 at 10:24 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote:

 Hi, when we edit Zero configuration, it would be very beneficial to flush
 any cached pages in varnish that are related to the change.

 For example, if I edit Beeline's banner settings, any objects with the
 header X-CS=250-99 should be purged, hopefully without any additional
 manual interaction. Without this purge, the cache will be stale for the
 next 30 days for the most common articles.

 Now, according to the
 http://giantdorks.org/alain/exploring-methods-to-purge-varnish-cache/,
 varnish has an extensive matching support, and the author provides some
 PHP-based code to perform the cache flushing.  What would we need to
 implement secure, automated partial varnish flushing in production?

 Thanks!
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Purging parts of varnish cache

[Arthur Richards]

On Thu, May 9, 2013 at 12:19 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote:

 ESI for older browsers, and JavaScript otherwise are still on the table,
 but that's orthogonal to the varnish cache purge -- if we use ESI, the
 banner will be cached and will need to be purged. If we use JavaScript, the
 JSON configuration blob will need to be purged. The only difference is the
 actual purging expression.


For sure; I just wanted to make sure. While practically these may be
orthogonal, purging full pages is less desirable than purging html chunks
for banners so approaching the problem with this in mind might make it all
more palatable.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle

[Arthur Richards]

On Mon, May 6, 2013 at 7:43 PM, Erik Moeller e...@wikimedia.org wrote:


 We may want to consider at least putting some such scaffolding for
 beta-prod desktop modes into place before shifting to weekly
 deployments, although if that holds up this change significantly, I'd
 be in favor of making the shift first and then iterating.

 Right now we have lots of individual experimental prefs, some dark
 launch URL parameters (useNew=1 for the account creation forms etc.),
 some changes that are announced widely but then rolled out immediately
 (section edit link change), etc. What would be the disadvantage of
 having a single I'd like the latest and greatest changes once they
 come in preference for our users? The main disadvantage I see is that
 we'd need to temporarily retain two codepaths for significant
 user-facing changes, potentially increasing code complexity a fair
 bit, but perhaps reducing post-launch cost in return. And we'd need to
 consider more carefully if/when to make the beta/prod switch -- not
 necessarily a bad thing. ;-)

 Have there been any negative experiences with this model on the mobile
 sites?


For the most part, this model has been awesome for mobile. It allows us to
iterate on feature ideas quickly, try a lot of different things, and focus
on the things that really work. Getting a partially-polished feature in
front of a group of users who expect to have things not always work 100% is
incredibly valuable - and takes off the pressure of having to get something
totally right. If it turns out the feature idea was a bust, it's generally
no big deal for us (the mobile team or the users) to either can it or tweak
it to make it better. Having an 'alpha' that is essentially a developer
sandobx (little to no productization happens for our alpha) and some of the
best mobile features have grown from here.

We've had occasional issues with beta or alpha features bleeding into a
mode they weren't supposed to - though this is generally quick to fix.
Ultimately, the issues we've had with the approach have been minor.

If this were something adopted by Mediawiki more generally, I would want to
see it carefully built into core. Ori brings up a good point about
increased code complexity, which is a guarantee with this kind of approach
but could certainly be mitigated if the plumbing were well architected.

I think thoughtful development of something like this into core would be
awesome and would allow us to collectively build better, more useful
features, faster.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Caching Problem with Mobile Main Page?

[Arthur Richards]

+wikitech-l

I've confirmed the issue on my end; ?action=purge seems to have no effect
and the 'last modified' notification on the mobile main page looks correct
(though the content itself is out of date and not in sync with the 'last
modified' notification). What's doubly weird to me is the 'Last modified'
HTTP response headers says:

Last-Modified: Tue, 30 Apr 2013 00:17:32 GMT

Which appears to be newer than when the content I'm seeing on the main page
was updated... Anyone from ops have an idea what might be going on?


On Thu, May 2, 2013 at 10:01 PM, Yuvi Panda yuvipa...@gmail.com wrote:

 Encountered
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Issue_with_Main_Page_on_mobile.2C_viz._it_hasn.27t_changed_since_Tuesday

 Some people seem to be having problems with the mobile main page being
 cached too much. Can someone look into it?


 --
 Yuvi Panda T
 http://yuvi.in/blog

 ___
 Mobile-l mailing list
 mobil...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Issue with: en.m.wikipedia.org

[Arthur Richards]

The mobile web team is planning to deploy a fix for Opera Mini-related
issues this coming Tuesday afternoon, which we expect will resolve this
particular issue.


On Fri, May 3, 2013 at 3:33 AM, Andre Klapper aklap...@wikimedia.orgwrote:

 Hi,

 On Fri, 2013-05-03 at 09:39 +, Martin Butler wrote:
  I'm not sure I'm posting this in the right place, but I (and I expect
  lots of others!) can't use en.m.wikipedia.org via Opera Mini.
  This is because the GO button next to the search box has disappeared.

 This is covered in
 https://bugzilla.wikimedia.org/show_bug.cgi?id=47567

 andre
 --
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla REST API?

[Arthur Richards]

Anybody know if we have the REST API for Bugzilla enabled - and if so what
the URL is for it?

I came across some old docs on wikitech.wikimedia.org that suggest we do
[1] - but no indication of the URL for service. I know I can use the
XML-RPC API for Bugzilla, but would rather use REST if it's available. Any
insight is appreciated!

[1] https://wikitech.wikimedia.org/wiki/Bugzilla_REST_API

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bugzilla REST API?

[Arthur Richards]

Mostly got an answer on IRC:

*mutante*

*3:44 *FastCgiServer
/srv/org/wikimedia/bzapi/script/bugzilla_api_fastcgi.pl-processes 3
-idle-timeout 180

*3:44 *Alias /bzapi /srv/org/wikimedia/bzapi/script/bugzilla_api_fastcgi.pl/

*3:44 *that is in the apache site config

*3:46 *root@kaulen:/srv/org/wikimedia/bzapi/script# ls

*3:46 *bugzilla_api_cgi.pl  bugzilla_api_create.pl  bugzilla_api_fastcgi.pl
bugzilla_api_server.pl  bugzilla_api_test.pl

*3:46 *but that's about all i know about it.. and that andre wanted to look
at it

*awjr*

*3:46 *ahha

*3:47 *mutante: any idea what URL points to that?

*mutante*

*3:48 *well it should be  just  /bzapi  per the Alias above, but:

*3:48 *[Fri Apr 26 22:48:16 2013] [error] [client 216.38.130.168] FastCGI:
comm with server /srv/org/wikimedia/bzapi/script/bugzilla_api_fastcgi.pl
aborted: idle timeout (180 sec)

*awjr*

*3:49 *hmm yeah http://bugzilla.wikimedia.org/bzapi appears to be timing
out for me

*mutante*

*3:49 *nod, same here

*3:49 *last paste is from apache error log when i tried

*3:50 *i know this is on Andre's in the future list

*awjr*

*3:50 *yeah ok

*3:50 *looks like im stuck with the xml-rpc api for now

*3:50 *thanks mutante


On Fri, Apr 26, 2013 at 3:32 PM, Arthur Richards aricha...@wikimedia.orgwrote:

 Anybody know if we have the REST API for Bugzilla enabled - and if so what
 the URL is for it?

 I came across some old docs on wikitech.wikimedia.org that suggest we do
 [1] - but no indication of the URL for service. I know I can use the
 XML-RPC API for Bugzilla, but would rather use REST if it's available. Any
 insight is appreciated!

 [1] https://wikitech.wikimedia.org/wiki/Bugzilla_REST_API

 --
 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Rollout plan for removing X-Device variance for mobile page HTML

[Arthur Richards]

The mobile team has been working on some significant performance
improvements. One of the trickier yet hopefully most rewarding improvement
is to remove the need to vary the mobile varnish cache by X-Device header
for regular page HTML. Updated code is already live in production[1],
however until we set $wgMFVaryResources = true, pages in the mobile varnish
cache will still be varied by X-Device header as they have been all along.

We've enabled $wgMFVaryResources on testwiki[2] and have been doing some
sanity checking to ensure major devices are still working correctly. During
our regular weekly MobileFrontend deployment on 16 April, we plan to enable
this on mediawiki.org for further, crowd-sourced testing. More details to
follow. Assuming things go well, we will go ahead and make this change live
everywhere, hopefully during our deployment on 23 April.

We expect this will have a significant increase in the mobile varnish cache
hit ratio.

[1]
https://gerrit.wikimedia.org/r/#/c/55226/
https://gerrit.wikimedia.org/r/#/c/58458/
https://gerrit.wikimedia.org/r/#/c/56774/

[2]
https://gerrit.wikimedia.org/r/58427

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mobile caching improvements are coming

[Arthur Richards]

This approach will require either:

1) Adding device detection to bits for device variance
2) Using mobile varnish to handle load.php requests for resources requested
from .m domains

From conversations with Max and some folks from ops, it sounds like #2 is
the preferred approach, but I am a little nervous about it since mobile
varnish caches will have to handle a significant increase in requests. It
looks like a typical article load results in 6 load.php requests. Also,
we'll need to duplicate some configuration from the bits VCL.  Ops, is this
OK given current architecture?



On Fri, Mar 29, 2013 at 11:18 AM, Max Semenik maxsem.w...@gmail.com wrote:

 On 29.03.2013, 21:47 Yuri wrote:

  Max, do we still plan to detect javascript support for mobile devices, or
  do you want to fold that into isWAP ?

  Non-js-supporting devices need very different handling, as all HTML has
 to
  be pre-built for them on the server.

 ResourceLoader has a small stub module called startup. It checks
 browser compatibility and then loads jQuery and various MediaWiki
 modules (including ResourceLoader core). We just need to imporove the
 checks, as the my original message states:

  * Since now we will be serving ResourceLoader to all devices, we will
  blacklist all the incompatible devices in the startup module to prevent
  them from choking on the loads of JS they can't handle (and even if they
  degrade gracefully, still no need to force them to download tens of
  kilobytes needlessly)[3]

 --
 Best regards,
   Max Semenik ([[User:MaxSem]])


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Alternative domains for Commons

[Arthur Richards]

+ops


On Thu, Mar 21, 2013 at 8:20 AM, Juliusz Gonera jgon...@wikimedia.orgwrote:

 We've been having a hard time making photo uploads work in
 MobileFrontend because of CentralAuth's third party cookies problem (we
 upload them from Wikipedia web site to Commons API). Apart from the
 newest Firefox [1,2], mobile Safari also doesn't accept third party
 cookies unless the domain has been visited and it already has at least
 one cookie set.

 Even though we have probably found a solution for now, it's a very shaky
 and not elegant workaround which might stop working any time (if some
 detail of default browser cookie policy changes again) [3].

 I came up with another idea of how this could be solved. The problem we
 have right now is that Commons is on a completely different domain than
 Wikipedia, so they can't share the login token cookie. However, we could
 set up alternative domains for Commons, such as commons.wikipedia.org,
 and then the cookie could be shared.

 The only issue I see with this solution is that we would have to
 prevent messing up SEO (having multiple URLs pointing to the same
 resource). This, however, could be avoided by redirecting every
 non-API request to the main domain (commons.wikimedia.org) and only
 allowing API requests on alternative domains (which is what we use for
 photo uploads on mobile).

 This obviously doesn't solve the broader problem of CentralAuth's common
 login being broken, but at least would allow easy communication between
 Commons and other projects. In my opinion this is the biggest problem
 right now. Users can probably live without being automatically logged in
 to other projects, but photo uploads on mobile are just broken when we
 can't use Commons API.

 Please let me know what you think. Are there any other possible
 drawbacks of this solution that I missed?

 [1] 
 http://webpolicy.org/2013/02/**22/the-new-firefox-cookie-**policy/http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/
 [2] https://developer.mozilla.org/**en-US/docs/Site_Compatibility_**
 for_Firefox_22https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22
 [3] 
 https://gerrit.wikimedia.org/**r/#/c/54813/https://gerrit.wikimedia.org/r/#/c/54813/

 --
 Juliusz

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RFC] performance standards for new mediawiki features

[Arthur Richards]

Right now, I think many of us profile locally or in VMs, which can be
useful for relative metrics or quickly identifying bottlenecks, but doesn't
really get us the kind of information you're talking about from any sort of
real-world setting, or in any way that would be consistent from engineer to
engineer, or even necessarily from day to day. From network topology to
article counts/sizes/etc and everything in between, there's a lot we can't
really replicate or accurately profile against. Are there plans to put
together and support infrastructure for this? It seems to me that this
proposal is contingent upon a consistent environment accessible by
engineers for performance testing.


On Thu, Mar 21, 2013 at 10:55 PM, Yuri Astrakhan
yastrak...@wikimedia.orgwrote:

 API is fairly complex to meassure and performance target. If a bot requests
 5000 pages in one call, together with all links  categories, it might take
 a very long time (seconds if not tens of seconds). Comparing that to
 another api request that gets an HTML section of a page, which takes a
 fraction of a second (especially when comming from cache) is not very
 useful.


 On Fri, Mar 22, 2013 at 1:32 AM, Peter Gehres li...@pgehres.com wrote:

  From where would you propose measuring these data points?  Obviously
  network latency will have a great impact on some of the metrics and a
  consistent location would help to define the pass/fail of each test. I do
  think another benchmark Ops features would be a set of
  latency-to-datacenter values, but I know that is a much harder taks.
 Thanks
  for putting this together.
 
 
  On Thu, Mar 21, 2013 at 6:40 PM, Asher Feldman afeld...@wikimedia.org
  wrote:
 
   I'd like to push for a codified set of minimum performance standards
 that
   new mediawiki features must meet before they can be deployed to larger
   wikimedia sites such as English Wikipedia, or be considered complete.
  
   These would look like (numbers pulled out of a hat, not actual
   suggestions):
  
   - p999 (long tail) full page request latency of 2000ms
   - p99 page request latency of 800ms
   - p90 page request latency of 150ms
   - p99 banner request latency of 80ms
   - p90 banner request latency of 40ms
   - p99 db query latency of 250ms
   - p90 db query latency of 50ms
   - 1000 write requests/sec (if applicable; writes operations must be
 free
   from concurrency issues)
   - guidelines about degrading gracefully
   - specific limits on total resource consumption across the stack per
   request
   - etc..
  
   Right now, varying amounts of effort are made to highlight potential
   performance bottlenecks in code review, and engineers are encouraged to
   profile and optimize their own code.  But beyond is the site still up
  for
   everyone / are users complaining on the village pump / am I ranting in
   irc, we've offered no guidelines as to what sort of request latency is
   reasonable or acceptable.  If a new feature (like aftv5, or flow) turns
  out
   not to meet perf standards after deployment, that would be a high
  priority
   bug and the feature may be disabled depending on the impact, or if not
   addressed in a reasonable time frame.  Obviously standards like this
  can't
   be applied to certain existing parts of mediawiki, but systems other
 than
   the parser or preprocessor that don't meet new standards should at
 least
  be
   prioritized for improvement.
  
   Thoughts?
  
   Asher
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l